Here is an update to main topic.
Now (after 10 weeks of research) I assume that I found the reason why variable restoring failed when my module was reloaded.
As I mentioned before, a module seems to be loaded twice each time. At first time initial values will be stored with GetStateInformation() and restored with SetStateInformation(). At second time VM restores switches, sliders and knobs to their states at a previous session. These settings provide event messages in Notify() even when the module GUI is not visible yet. At that time not every variable or control has got it's final value or state.
Though I tried to prevent code from execution when distinct control events occured, it did not work all time because not all used boolean switches were restored correctly yet.
At least I created an init interval by counting samples in ProcessSample(). Notify() became divided into two blocks:
Code: Select all
Notify()
{
if ( !init )
switch( notification ) // all events, that need to use restored variable values and control states
{
case ...
...
break;
}
switch( notifikation ) // all events, that will work alltime
{
case GUI_UpdateTimer:
{
...
}
break;
case Named_Timer:
{
...
}
break;
}
}
After an init interval of 48000 samples duration (= one second) the code worked as it should. (Mostly, but that'll be another story.)
Some time ago I sent a feature request to CA support for a VoltageLabel.SetValueNotification() method. Now I recommended the use of SetValueNotification() instead of SetValue() when VM restores GUI controls state. That might fix variable initialization issues. I wonder what CA team will think about that.
Roland