I'm trying to use a group of hidden Editable Labels to store some persistent state information for a module I'm building - 'quick recall' slots that store sub-preset level information for the module. Each label is tied to a ToggleButton (in radio group), and the overlay text color of the ToggleButton varies (or should) depending on the contents of the associated label. My goal is to make a group of buttons have persistent but variable behaviors that are saved/restored with the default module state, similar to the behavior of "regular" GUI elements (eg. knobs, buttons, and switches).
I've got the mechanics worked out, but the module initialization sequence is kicking my butt...
Initialize() seems to get called fairly early, GUI elements may not have their final (restored by default) values yet.
SetStateInformation() doesn't seem to get called if no preset is loaded (and therefor never from within VMD).
Notify() seems to be called for each GUI element, but the ordering is indeterminate, and I need multiple elements to be available before I'm "ready to go". Keeping track of them all by hand is a giant pain, as is then trying to distinguish initialization related events from actual user input.
I've found a couple of other posts that touch on this, but nothing directly applicable:
SetStateInformation not firing when no custom info in preset
Debugging issues that happen when presets loaded
At the moment, I'm checking a flag in ProcessSample(), but since in VMD ProcessSample() may start early, even that's unreliable.
Could a notification event (Module_Initialized maybe?) be added to Notify() that was guaranteed to be fired *after* the module has been fully initialized from VM/VMD's viewpoint? Or an additional callback member function ala SetStateInformation that would *always* be called after module initialization?
Maybe I'm missing something and/or overcomplicating things (wouldn't be the first time!

Cheers,
--
Terry McG