[Scilab-users] global constant definition for module

[Serge Steer]

Le 05/03/2016 00:00, Samuel Gougeon a écrit :
> Le 04/03/2016 23:33, Samuel Gougeon a écrit :
>> Le 02/03/2016 12:24, David Chèze a écrit :
>>> Hi all,
>>>
>>> I would like to define a variable in a user module in such a way that this
>>> constant would be available for all functions (also out of the module) as a
>>> "hidden(you don't need to see it inbrowsvar), protected (should not be
>>> possible to clear it, even with clearglobal )" global variable as soon the
>>> module is loaded: do you have suggestions how to do it within scilab?
>>
>> There is still no actual solution to protect variables against clear.
> .
> Actually, there are one or two solutions :
>
>  1.  Set and store your constants in a TCL session (the main one or a
>     slave), and recall them from it. Data in TCL sessions are not
>     cleared by clear() nor by clearglobal(). This is what i use in
>     drivers published on the fileexchange to set/get "persistent"
>     communication parameters with devices.
>  2. May be the same could be possible with java objects? I have never
>     tried.
>  3. Another solution is to use the userdata field of the default
>     figure. The default figure (gdf()) is not clearable. But then all
>     your graphic windows will embed your constants in their .userdata.
>     So it is preferable not to have MBytes of constantes ;) And to set
>     a struct() in userdata. This is a rather bad hacking.
>
> May be there are other solutions. Let's free your imagination :)
Yes there is at least another one :-; : use the user_data field of an 
unvisible graphic window
fig=figure("visible","off","user_data",struct("A",123,"b","FOO"));

a=fig.user_data.A
Serge
>
> Samuel
>
>
>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20160305/b6e108f0/attachment.htm>