Order of creation vs. attachments?

I have a plugin with a number of Component views, and a couple of Button objects that are set up to have attachments to parameters. When I am loading a saved session, while creating those Components and the Buttons’ attachments, the buttonClicked() function is called for those Buttons, which sends their state to my Editor. The Editor, when getting that state change information, sends it to another Component (a keyboard), which is supposed to apply that information in order to modify the keyboard’s behavior. However, the keyboard has not yet been created at that point, so my code does not attempt to call the keyboard’s function for setting that option.

What is the proper way to address interconnected Components that have parameter attachments? Is there a way to change the order of initialization of the Components, by re-arranging them in Projucer or something? Is that even the correct approach to this?

Or do I need to handle this manually via, say, a flag that says I have information that needs applying, and checking that flag in the timer callback to see if there is a new value for either of those switches to apply to the keyboard? That seems kind of hokey, but maybe a better design than relying on creation order?

Or, maybe the most robust method, removing the function to set that flag, and actually querying those parameters from a timer callback to see if the parameter values have changed and applying the behavior change from there?

I’m not sure I understand your case completely, but the construction order of members is fixed by the standard as the order of declaration. Whether relying on it can be considered robust enough is another matter, but it’s possible (I do it quite often). Wouldn’t be possible to create the keyboard before the buttons, so that it can receive the state change?

For connections at the UI level, I tend to do them directly -it doesn’t make sense to me to poll a flag when everything runs on the same thread. Anyway I never get into this issue, because I make all attachments in the Editor’s constructor, when everything is already created.

Well, the problem is that the keyboard is a child component of one component, and the buttons are children of another component. The parent of the keyboard and the parent of the buttons are themselves children of the Editor. My component views are all laid out in Projucer, so the keyboard and buttons are created and managed by their parents, not by the Editor.

I suppose I could provide a getter in those components to the buttons and keyboard, and make the Editor be the Listener for those buttons buttonClicked() calls, and own the attachments there. But that seems convoluted to me.

I’m thinking I’ll just query the parameters’ states in the timer callback, to make sure that the existence of any other views is not even relevant, only the parameters will need to exist.

If the parent of the keyboard is declared before the parent of the buttons in the editor definition, the keyboard will be already created when the buttons’ attachments are created. Still, the part that confuses me is

Wouldn’t this point (getting a state change) come after all has been constructed?

No, because the act of adding the button attachment causes it to call buttonClicked immediately in the button’s parent, but the keyboard’s parent hasn’t been created yet.

Ah ok, you mean loading the current state when attaching. Well, still seems to me that declaring the keyboard’s parent before the buttons’ parent should work then.

Thanks, but I decided to query the parameters from my timer callback. Works great. I just don’t like relying on the order of creation of otherwise unrelated classes. That’s too much interdependency for me.