The gist is, that the textButton is positioned relative to groupComponent.
Observed:
The Projucer generated the following resize() code:
void Test::resized()
{
//[UserPreResize] Add your own custom resize code here..
//[/UserPreResize]
groupComponent->setBounds (8, 8, getWidth() - 16, getHeight() - 16);
//[UserResized] Add your own custom resize handling here..
//[/UserResized]
}
the code for positioning the textButton is omitted entirely.
Expected:
the generated resized() function contains code to position the textButton as well. This used to work in earlier versions. Also the Projucer positions the components as one would expect.
I’m on 717cc49382fd8fd97dcfe080c75be60d573d4e5b, macOS
the forum seems to get a post about the editor not doing something correctly once or twice a month. How long would it take to strip it out of ProJucer? a day, maybe? Is that on the todo list by chance @daniel?
Lads, I’m getting that you’re trying to get rid of the GUI editor. But this used to work in the past - so someone broke it along the way. Just try it with 5.2.0.
PS.: I don’t get why anybody would prefer to check-adjust-recompile-rinse-repeat over pseudo-WYSIWYG.
PPS.:
5.2.0 generates:
textButton->setBounds (8 + 16, 8 + 128, 150, 24);
which is indeed not correct as it ignores the fact that the parent might have been dynamically positioned. snap!
in this case the X of the textButton depends on the X of the group which depends on the width of the whole component. And the code that the Projucer of 5.2.0 generates does not take this into account.
There is the JUCE_LIVE_CONSTANT class for editing values while the application is running, which is very useful for getting those fine details just right!
yeah, that’s the only way to develop your GUI’s really. it doesn’t work for ios or android tho, because those are always fullscreen apps, and the LiveConstant appears in its own window
That still requires you to tag all the places you want to adjust beforehand. And when you’re done you need to remove JUCE_LIVE_CONSTANT again because otherwise the list can get a little overwhelming. I do use it for tweaking stuff in paint() though.
Hey Daniel, IMHO this is still a regression to earlier versions (5.2.0) and I’d appreciate if someone could have a look. I have now two projects with borked UI.
This is the commit after which the resized() behaviour is different, and AFAICT it’s fixing an actual bug in the layout code. Perhaps your code just worked before with the broken behaviour and is actually incorrect although I’m not totally clear what your expected behaviour is - can you provide a bit more info and perhaps some screenshots?
That’s cool, I wasn’t aware, that the Projucer actually can generate formulas in the resized() method. I loaded the code you posted, and indeed it is missing the line for resized() for textButton.
However, when I looked in the GUI editor, I realised, that the width and height for your textButton is set to “absolute”. Once you change it to “Subtract from width of parent”, it works again…
I don’t know, why it would behave differently in 5.2.0 though.
Essentially I’d like the generated code to behave the same as the cmd+t preview in the Projucer.
this bit of code appears to decide if a bit of resizing-code goes into the constructor or into resized(). What appears to be missing here is a check if the RelativePositionedRectangle is positioned relative to the ‘parent’ (i.e. root) or relative to some other component.
I think the RelativePositionedRectangle::isPositionAbsolute() returns a true, when it shouldn’t.
It doesn’t take absoluteFromParentTopLeft into account, when the parent itself is relative.