Suggestion: Isolate Jucer components from user code

The Projucer
1

The Jucer (I am referring to the UI component designer here) is really a helpful tool to quickly sketch a user interface and refine it over time. The only issue I have is that I need to be extremely cautious to not loose any of the custom code I am having inside the component. I understand how the square brackets work, but still there is a permanent uncertainty and extra level of required awareness left that adds to the overall stress a lot.

Especially when changing a layout significantly, it is not guaranteed that all of those “custom regions” are retained, as, for instance, button names may change.

The perfect solution would be to isolate the files containing custom code from the Juce-maintained component machinery entirely. That is, the files Jucer works on will never need to be edited by the user. I am relatively new to C++, but from my overall experience, I could think of the following potential solutions:

:idea: (A) Make the custom component inherit from the Juce-generated class.

:idea: (B) Make the Jucer component a separate class, of which an instance is attached to the custom component as a member.

I don’t know how much overhead (B) would imply, concerning message delegation and such. Therefore my current favorite is (A).

What do you think?

Andre

2

Well, I’m not going to change anything in the old jucer, but as I’m developing the new one right now, these are all questions that I’m thinking about.

The nice thing about the way it’s done at the moment is that the jucer can automatically add callback methods to your class, whereas if you were using a derived class, you’d need to manually add all the methods and callbacks to get your events.

3

I went for (A) as a test and it works great. Editing the middle class with the jucer does not affect my custom code in the subclass anymore. One thing I needed to do, though, is make the subclass a friend class of the component, so it can directly access the private UI components (only needed for button comparison in the button click callback for now). That friend class statement nicely fits into one of the square brackets areas.

You are right, callbacks must be maintained manually, but I can live with that. These do not change often anyway. I just need to be 100% sure that editing the graphical layout does not mess with my code. Depending on how complex your plugin display logic is, that code can easily grow very big.