Usually this behavior can be observed in the Prototyper if e.g. a slider value is stored in a property of an auto-object. The reason for this behavior is the fact, that an auto-object get automatically created by Embedded Wizard as soon as it get referenced from any Embedded Wizard object. This is e.g. if the slider makes a read or write access to a property of the auto-object.
If no further access happens, the Garbage Collector will destroy the auto-object and release the memory. At the next access it will be crated again with its default values and the last setting is lost.
On the target platform this behavior might be wanted, since all settings get read/written via native C-code from any API or driver modules. In this case the auto-object does not store the data, but the target stores the data.
In the prototype however the data is often stored in the auto-object for simulation purpose. In this case we need to prevent the Garbage Collector from destroying the auto-object. But how can this be achieved?
We know that the auto-object will not be destroyed as long as it is referenced from any other object. Usually the root object is the best object to hold a reference to auto-objects (assuming you start prototyping from the root class).
Therefore we add a variable (e.g.: Audio) with the type of the class of our auto-object (e.g.: SettingsApi::AudioClass) to our application class (e.g.: Application::Application derived from Core::Root). As next we have to assign the auto-object to the value of this variable. This can be done in the inspector, but if you do not want to keep the auto-object permanently loaded in the RAM (even on the target), there is an alternative way:
Implement the Init() method of your application class and assign the reference to the auto-object only for the simulation e.g.:
$if $prototyper
Audio = SettingsApi::Audio;
$endif
