Initialization Woes

[UrbanCyborg]

Now, supposedly, all control values are saved with a patch and restored when the patch is initialized again. In general, that's what I've seen. But I'm chasing a minor bug that appears due to a violation of that behavior. None of the controls in the module I'm working on right now are restored during the duration of the Initialize() routine. The ones causing the trouble are editable text fields. I set their visibility based on reading their values during initialization. That's failing in an interesting way. I have a routine that manually updates them at other places in the code, and that works fine after the first imbroglio, but a call to the same routine in Initialize() doesn't work correctly, apparently for the same reason. I hate to manually store and recall the values, when VM is supposed to do it automatically. It almost feels like the initialization order for this one module is different than for all the other modules I've written. I know there are no guarantees on initialization order, annoyingly, but this is really oddball. It fails the same way in VM as in VMD. Anyone got any ideas?

Reid

[UrbanCyborg]

Follow-up. It appears I do have another module that has what appears to be the same problem, except in that one, it's an array of toggle buttons that isn't getting properly restored. Oh, and using GetStateInformation() and SetStateInformation() to save and restore the state of the problem controls doesn't work, either.

Reid

[ColinP]

Hi Reid,

I've mostly used editable text labels in a passive way - where they simply hold some user entered text to label stuff but I presume they operate in the same fashion as things like knobs, toggle buttons and switches.

CA's documentation is somewhat vague but AFAIK how persistence in VM works is that Initialize() is called with all controls in their default state and then AFTER Initialize() is finished VM works through all the components restoring their GUI state and sending change events to Notify() with the restoration info so that you can do whatever is needed for your custom initialization using exactly the same event handlers you use for normal input.

If you think about it this has to be how it works otherwise you might need to write lots of redundant code and call it from inside Initialize(). Also VM can't safely send change events to your handlers BEFORE Initialize() has finished because many of the objects in your system might not even have been created yet.

The way I think of it is that VM loads your module up in fresh default state and then kind of replays all the most recent changes that the user made in previous sessions.

Get/Set state operations are done separately as they don't correspond to component states (at least from VM's POV).

I hope this is helpful and I've not misunderstood the issue.

[UrbanCyborg]

Thanks for the reply, Colin. No, I think you've hit it on the head. Looks like I'm going to have to find a way to offload a chunk of my state initialization to the control handlers. And I probably need to revisit all my other modules and make sure I'm not tripping over something there.

Something is still problematic, though. In the module with the array of toggles, the toggles should end up being reset to last state by the system, and they're not. That module is structurally much simpler than the one where I first noticed it, and I'm not trying to do fancy initialization there. He said in a half-crazed mumble....

Reid

[ColinP]

I use toggle buttons quite a bit and although there are some issues to be wary of, in simple scenarios they behave themselves and do restrore to previous state without any special handling.

So it sounds like you may have some code interfereing with what VM is trying to do. For instance you might be setting button state from inside SetStateInformation() when there's no need to.

In general Initialize() should just be used to build your object model, event handlers should be used to handle all changes to component state and Get/Set StateInformation() should handle anything that doesn't automatically persist.

BTW one can use invisible components to hitch a ride on VM's persistence mechanism - so for instance if you want to make a double persist you can have a tiny knob somewhere on the panel and then make it invisible in Initialize() so that users don't know about it and can't change it via the GUI. But from VM's perspective it's just a regular knob and its state will be saved and restored automatically. You can then use Get/SetValue() to access ithe double programmatically (or an event handler to trigger on restore if you don't want to poll - although polling seems to have minimum overhead anyway). Obviously not very practical in large scale applications but a useful shortcut in some modules.

[terrymcg]

In general Initialize() should just be used to build your object model, event handlers should be used to handle all changes to component state and Get/Set StateInformation() should handle anything that doesn't automatically persist.

This is excellent advice!

I eventually realized that trying to set control values inside Initialize() almost always causes unexpected issues, so gave up and left it all to Notify()... It gets called more often than one might think during module startup, so there's no real point fighting it.

Cheers,
--
Terry McG

[Captain]

BTW one can use invisible components to hitch a ride on VM's persistence mechanism - so for instance if you want to make a double persist you can have a tiny knob somewhere on the panel and then make it invisible in Initialize() so that users don't know about it and can't change it via the GUI.

To take this a step further, you can also create a hidden knob dynamically in the code, so it doesn't need to be there to clutter the interface at any point. The persistence still works!

[UrbanCyborg]

Thanks for the advice. I'm aware of using hidden controls to save bits of state. That's not really my problem. The heart of the problem is that there's no way to really know when initialization is truly over, and my button notification handlers can, in turn, modify the state of buttons. If I could just tell the handlers to not handle during initialization, all would be well, but that doesn't really work, either, because initialization-induced button changes can occur after any test that tries to pinpoint the end-of-initialization. The best I've found so far is to set a variable in Initialize() and unset it at the top of ProcessSample(), as Roland suggested, but that still occurs before all the chained toggle changes occur.

The suggestion to use Preset_Loading_Finish to be sure of initialization being done fails, as well, because any system-induced button changes during preset loading will still chain until after that. Besides that, Preset_Loading_Finish is still problematic, because it gets called twice during initialization, for no reason I can fathom.

I know the response is going to be that I shouldn't be changing buttons in the button notifications, but if I don't, how do I achieve state-aware buttons? The specific situation is an array of toggles that are subject to a button that alternates between setting them all on and setting them all off, and a button that toggles a solo mode for the array on and off, and which itself is toggled off by the All/None button. So you see, the logic required is a bit twisty (he cried, rending his breast in horror at the irrationality of systemic Nemesis).

Reid

[Captain]

The heart of the problem is that there's no way to really know when initialization is truly over, and my button notification handlers can, in turn, modify the state of buttons. If I could just tell the handlers to not handle during initialization, all would be well, but that doesn't really work, either, because initialization-induced button changes can occur after any test that tries to pinpoint the end-of-initialization.

Now that you mention it, I remember fighting with this very same issue. It's been a while, and I just recently got back into VM programming, so I don't really remember if I came up with any real solution to this (and why exactly I needed to know when the init phase is fully done, and what module I was even coding...). I'll report back if I can find my old code and learn anything new from there.

[UrbanCyborg]

Roger that, Captain, Oh, My Captain.