Some examples of saved parameter data from a config file:
Vparam1=0 (floating point data)
Hparam2=1065353216 (bitwise parameter)
Tparam3=hello (text parameter)
TABparam4V=0000D0420000CA420000D8420000D8420000DE42 (array - stored in hex)
When a module is loaded and the parameters are restored from the saved data in the config file, if the parameter type does not match the saved format, the data may not be restored to the parameter event.
This has not been an issue previously when the parameter types were hard coded in the module, but with sdkRecreateParam(), the situation can now occur.
For example, if a user module sets its intended parameter types from Settings using sdkRecreateParam(), when the module is loaded the parameter type may still be of the default type so its saved parameter values may not be restored.
It would be useful to have a way to load the stored parameter value in this situation. Currently the only way is to store the parameter
values in the Chunk which is not ideal.
1. A new command to load a parameter from the config file at any time, e.g. sdkReloadParam()
2. A new command to read a parameter from the config file - e.g. as an sdkGetSavedParamEvt() which could then be copied to the
parameter event in the user module.
3. Change Usine to restore the parameter event as it was when the parameter was saved, even if the parameter type is "wrong".
This could be done only for a certain parameter type (e.g. ptBitwise) or a new parameter type for this purpose
(ptUnknown, ptGeneric or similar). This parameter type could be used as the default type in the user module which would
ensure that the saved parameter event is restored.
Last edited by sm_jamieson (2018-07-13 00:16:38)
complex situation I'm not sure it's possible to find a solution.
option 1/2: the sdkReloadParam or GetSavedEVT is not possible in the general case.
after loading, the wkp file is no longer stored in memory so we should be obliged to reload it entirely.
how to find a single value in a huge wkp file? it could take a while. It's also not so easy because of the hierarchical structure of the file.
For that I'll be obliged to deeply change the internal structure of wkp files and serious potential compatibility issues.
option 3: probably to complex to implement actually and and probably leads compatibly issues.
I think that usr modules should be responsible of their storage. Usine gives a basic storage services but can't cover all possibilities? It's the best way to ensure the module is properly charged.
OK, user modules are responsible for their own storage - that is quite reasonable.
The Chunk works fine.