Why all the (false) errors from setBounds(const String&)

#1

If i do something like :


m_output_waveform->setBounds("5,waveform1.bottom+2,parent.width-5,top+75+parent.height*0.1");
 

Juce starts spitting out in debug builds during runtime errors like :

Expression::EvaluationError: Unknown symbol: waveform2

Expression::EvaluationError: Unknown symbol: parent

But these have to be false errors as the bounds expressions work, right? (This happens with all components I use setBounds(const String&) with.) Is there some reason the expressions are considered to have errors? Should the string expression for the component bounds be considered a feature not to be used in production code yet?

#2

TBH the expression-based positioning was a bit of an experiment that I tried a few years ago, but I've changed my mind since then and stopped using it in my own code. (Originally I was planning on using it as part of a new GUI design tool, but decided it was the wrong approach).

I've left the classes in there because people may be using them, but I'm planning on creating new, better ways to do the same thing pretty soon, as I've got a few nice ideas about this.

The reason you get the warnings will just be because when you call setBounds, it has no way of finding the comp called "waveform2". Perhaps you've not yet added your component to the same parent, or not yet set the ID of the other one to "waveform2". You can avoid it by changing the order in which you create things or set the bounds, but TBH I think there are other, more easily debuggable ways to lay out your components.

#3

I think I tried to ensure I've done the setComponentID calls and component creation in an order which should be right, but it is still printing the evaluation errors. (Perhaps I didn't experiment enough with the call orders though...) Also, I get those errors not only during the initial component setBounds calls but also at other instances during runtime.

But anyway, as I suspected, the feature isn't really intended to be used in new code, right? Is there any other solution available currently in Juce to achieve the same results? I would not consider for example overriding the parent component's resized() virtual method and resizing the child components there a nice solution. That annoyingly separates the code for child component creation and handling their resizing into 2 different places. Those IMHO in most cases are things that should happen in the same area in the source code.

#4

I would not consider for example overriding the parent component's resized() virtual method and resizing the child components there a nice solution. That annoyingly separates the code for child component creation and handling their resizing into 2 different places. Those IMHO in most cases are things that should happen in the same area in the source code.

Well, I've tried every kind of approach to this and I really think that one's the best so far. If you have anything other than a trivially simple layout, then it's often impossible to do it at all without having code that runs in resized().

My future plans involve some nice syntax for building a nested set of layout objects, and that could be used either with a fixed layout at construction or dynamically on resized(), so should be able to handle all cases.

#5

I am now experimenting with some C++11 lambdas/std::function based stuff that indeed allows writing the code for the component positioning elsewhere than in the resized() function...It looks like my solution can replace the string based bounds expressions.