Initialization Woes

[seal58]

That seems to be a never ending story. Now I have much trouble and can't find a way to fix it.

I've been fighting against initialization trouble for several days now. I already applied my new module for admission, but then recalled it, because of data save issues.

To save user set values and module state at "Save Preset" I use some hidden knobs, as I did at some other modules. But there the knobs where changed only manually by the user. Now I use hidden knobs that are set by the code only.
Until now I did not try to add any code in Initialize() or other methods in order to save and reload values.

As it is common thaught, I believed in automatic controller state storage by VM system until now. But now when I load a preset with the module, all of it's knobs have got initial values that I defined when I designed the GUI. Then I tryed the use of variations. That works for visible toggle buttons and switches only and also sets initial values.

In order to watch module behavior in real time, I extended module front to 6 inches. This large front serves me as display, where I can watch boolean states, numeric variables values and VoltageKnob values. Now I additionally placed the normally hidden Knobs on the front and let them visible. So I can see, that numeric values change when I move a knob. But when test preset is reloaded, all knobs show their initial values.

Whole function of the module depends on a working data saving and restoring. Meanwhile I'm really down after 6 weeks coding for that fucking module.

Does anybody have a little idea, where I could have made something wrong?
Any hint is very welcome.

Roland

[ChR_is]

i think disabled and/or hidden controls are taken out of of the even system. e.g. you can't set a value on a hidden knob and it won't receive notifications either.

can you explain what hidden means to you? just an invisible skin? SetVisible(false)? SetEnabled(false)?

EDIT: i just checked and hidden controls (SetVisible(false)) do receive notifications and can have their values set.

[terrymcg]

That seems to be a never ending story. Now I have much trouble and can't find a way to fix it.

I've been fighting against initialization trouble for several days now. I already applied my new module for admission, but then recalled it, because of data save issues.

To save user set values and module state at "Save Preset" I use some hidden knobs, as I did at some other modules. But there the knobs where changed only manually by the user. Now I use hidden knobs that are set by the code only.
Until now I did not try to add any code in Initialize() or other methods in order to save and reload values.

In my experience trying to set GUI control values in Initialize() only adds to the pain

Have you tried coding up an explicit property handler for your module? That way you can save/restore values without depending on GUI components (visible or otherwise)?

This is what I've done in several cases, via a PropertyManager class that lives in my .jar/library and a support class that I can boiler plate into each new module. The classes use the Observer pattern, so I add a couple lines of code to the Get/SetStateInformation methods in the framework to invoke an instance of the PropertyManager, and it then calls the worker class in the module whenever VM does preset stuff. Things in the module that that need to be able to save/restore state info pack that information into Java Properties objects using the worker that the PropertyManager then gives to (or gets from) VM. TMachine does this to save/restore the state of its internal shift register (without needing any control hocus-pocus).

While the initial investment wasn't trivial, it's made things much easier for me than depending on controls. A less general solution, specific to the module that's giving you grief, might not be so involved to implement (and could maybe be turned into something more general over time).

Full disclosure, I haven't investigated "Variations" at all, for better or worse.

If it sounds like a possible way out of your bind, I'd be happy provide additional detail on how I've done it.

Cheers,
--
Terry McG

[seal58]

Now I additionally placed the normally hidden Knobs on the front and let them visible.

This did not solve the problem.

To the details:
- Initialize() is not used.
- As "hidden" I ment "SetVisible( false ). I could hide them by placing them behind other controls too.
- My doInit() method reads all controller states and updates variables and GUI. It is called once at the beginning. First I called that method within Notify()-GUI_Update_Timer. Then I moved the call to ProcessSample(). In both cases restored values differed from that at "Save Preset".
- At last try I let all "storage" knobs visible and enabled. That did not make it better.
- My code does not contain any classical save/restore handler. Whole processing is done with GUI_Update_Timer. At the end of processing values will be written to storage knobs.

I still assume that the reason of my restore problem is related to the timing of module loading and initializing. So now I plan to modify my code. Controller read out should be done delayed so that automatic Voltage initializing will be finished surely.

When I've got new results I'll be back.

[UrbanCyborg]

Terry, I'm curious. What do you gain from using Observer, rather than just implementing code directly in GetStateInformation() and SetStateInformation(); after all, those functions only get called on demand, anyway. Another level of indirection and an interface designed the way you want it? Or is there something else? This doesn't seem like a use case I'm familiar with for Observer, although that might just reflect a deficiency in my knowledge, admittedly.

Reid

[terrymcg]

This doesn't seem like a use case I'm familiar with for Observer, although that might just reflect a deficiency in my knowledge, admittedly.

No, it's more likely a reflection if it (Observer) being the one Java design pattern I really know...like Franks Red Hot Sause, I use that sh*t everywhere

I built it all some time ago, and looking back I honestly think "familiarity" did have a fair bit to do with it... I use a number of constructed IO components that put Observer in a more traditional context which came from same period. I might do it differently now (knowing a bit more about Java), but at the time it made it easier for me to understand how to reuse the tech with different modules. It's worked so far, so I haven't mustered the energy to revisit it

And I still use the default property save/restore method for anything that has a visible control. All of this is just for non-GUI connected values that need to be retained.

Cheers,
--
Terry McG

[terrymcg]

- My code does not contain any classical save/restore handler. Whole processing is done with GUI_Update_Timer. At the end of processing values will be written to storage knobs.

I'm interested in how it goes, but I think if you "fight the system", you're just making life harder for yourself... It's gonna win pretty much every time.

It's clear that there is still a fair bit of initialization still going on when VM calls Initialize() in any given module. I recently found (as you have) that the initializing state extends well beyond the end of the Initialize() method and into the first few GUI update timer cycles, so you can't use GUI timer firings as indications of initialization completion. Unless you ignore a few. But the number you need to ignore to reliably establish initialization completion is undefined (and potentially variable).

IMO, you'd be better to bite the bullet and try to make it work via Get/SetStateInformation than to try to "work around" the existing methodology.

Cheers,
--
Terry McG

[UrbanCyborg]

Thanks for the clarification, Terry. Kind of an example of "When all your tools are hammers, all your problems start to look like nails," and the converse, "When all of your problems are nails, you start to use all of your tools like hammers."

One problem with relying on GetStateInformation() and SetStateInformation() is that, depending, Initialize() and its secondary effects may not be done by the time they run. Sadly.

What I've arrived at as a sort of workable modus operandus is to do nothing but initialize a base version of the module in Initialize(), and to only use SetValueNoNotification() in anything that might get called during initialization. The code would look a lot cleaner if I didn't have to do that, but then, it would fail unpredictably, too.

Reid

[seal58]

Hello, here is the report:

Preparation
- I extended my debugging GUI beside regular module front. Now there I could see text logs as at usual output pane, I could select code area, from where I want get log messages, initialization happens step by step only after button clicks and state information.
- "Storage" knobs are visible and enabled. When values are stored to a knob, SetValueNoNotification() was used as before, but now with GUI update TRUE.

Test
1. Until I researched initialization process, I assumed that GUI_Update_Timer would be active with 50 msec interval as default. During test I found, that the timer is not active without starting it.
2. Though I let the code send log messages to both debugging GUI and to VMD output pane, only one of 5 lines appeared on selfmade output area.
3. During test in VMD sometimes regular module functions had issues. These where data inputs with mouse dragging on text labels. Other problems came with "Label_Changed" event in Notify(), though I used boolean conditions. (That's why I urgently need a SetTextNoNotification() method for VoltageLabels) That seems to be result of CPU lasting VMD environment. These functions worked fine in VM.
4. In VMD storage knobs followed input data, in VM the didn't, but got set data.
5. For test in VM I created 4 variations with different function modes and value sets. Then I saved test preset.
6. When I reloaded that preset, regular switches and sliders matched states, that where stored before in variations. Knobs got default initial states only.

So I must step into use of GetStateInformation() and SetStateInformation() what is totally unknown to me yet.

Roland

[honki-bobo]

1. Until I researched initialization process, I assumed that GUI_Update_Timer would be active with 50 msec interval as default. During test I found, that the timer is not active without starting it.

That, and another problem with doing initialization stuff in GUI_Update_Timer is that it doesn't fire when your module is "off-screen". So when you have a larger patch and your module is not shown when the patch opens, then your GUI_Update_Timer won't get triggered. I've learned this the hard way when I was implementing my Stereoscope. The module crashed every time it moved off-screen and I had a hard time debugging it.

So I must step into use of GetStateInformation() and SetStateInformation() what is totally unknown to me yet.

When I started implementing modules I also used invisible knobs to store values, but that somehow didn't feel right to me. So I started playing around with Get/SetStateInformation() and it works as expected. Well, at least how I would expect it. There have been some discussions about Get/SetStateInformation() in the forum, e.g. here. Maybe this gives you an idea on how to utilize it.