04-19-2012 11:22 AM
Hi all, very interesting discussion about XControls i'm triying to discover!
I want to do exactly what Thoric said in the second post, i must have several instances of the same XControl in a VI, and what i want
is that every XControl loads up with a state stored in an external file, and this state is the last state the user choosed in the last run of executable.
What i really don't understand is if i have to do this in the init ability of XControl or in the calling VI.
My XControl is a Button that when user press it and choose color from a palette, the button itself gain this new color.
So i want that when user close and restart the executable the Buttons must retain the old values that user has choosed in the last run.
What i've done until now is editing INIT ability in this way:
My state is composed by a cluster with 2 elements: a numeric data and a boolean, what i do is
IN THE INIT ABILITY
1) Converting the previous state from variant to data, and setting a numeric to a constant value and boolean to TRUE directly in init.vi (i must find a way to pass this externally i hope)
2)reclustering both elements and converting to variant as input to the init CASE structure
IN THE FACADE ABILITY
3) added an event for the button value change, and declusterd DISPLAY STATE IN to look if the boolean is TRUE (to load default value) or if it is FALSE (to launch subvi that let user choose color)
04-20-2012 06:12 AM
Sounds like you need the opposite of what I needed
You want the XControls to record their state such that they appear exactly the same when the executable is closed and relaunched. In my case, I wanted my XControls to lose any changes, and restore the pre-programmed state when the executable is closed and relaunched.
In your case, you need to save the XControl states outside the executable at close, in a configuration file for example, and load the states from the file when the executable launches.
I would recommend you create a method for your XControl called , for example, "Initialise" with parameters for loading the settings. This could either be the path to the configuration file or the particular settings themselves passed in directly by the owning VI. You would need to make sure this Initialise method is the first thing you call on your XControls.
When your executable closes, call a method on XControl that either gets the XControls to export their settings themselves, or perhaps returns their settings and you export them to a file yourself.
04-20-2012 07:27 AM
[Set thinking out loud mode = true]
So what happens if an app using an XControl that depends on an external file is moved on disk and the file is not?
How is a file read (or any other external dependancy) error handled inside an XControl?
[Set thinking out loud mode = flase]
04-20-2012 08:14 AM
Oooh - an XControl discussion
Not that I condone saving to an external location necessarily, but if that were to be implemented, then the XControl code ought to behave/react in a defined and predictable manner in an event such as file absence. For example, in the above scenario, if the control colours are defined in the file, but the file is missing, the XControl ought to revert to default colours. The file ought to be created and the new values saved upon exit.
That's one possibility, and how I'd prefer it to work.
Alternatively, if the parent VI is responsible for loading the settings and passing them into the XControl, then the XControl doesn't need to worry about missing files, the calling code does. This gives the developer ample opportunity to create error handling code for missing configuration information scenarios. This is especially useful if the developer isn't responsible for the XControl itself, and simply 'inheritied' it.
04-20-2012 08:26 AM - edited 04-20-2012 08:28 AM
The first thing I noticed about your INIT ability code is that you have disabled the previous state input altogether. You convert the variant into a cluster, then set both values in the cluster from constants. Why bother with converting the previous state input at all?
In terms of storing those values, you can store them anywhere you want the only thing is that the read routine has to provide (as Ben pointed out) reasonable defaults for when the data isn't there. Also, you will need to make provisions for identifying separate instances of the control - unless you really want every instance to be set the same.
Are these properties going to be settable at run time? If so you will need to provide a write routine as well, and decide where to put it. Do you want to save changes immediately, or only when the XControl goes out of memory?
What if the file changes while the VIs displaying the XControl are open, should the controls update? If so you will need to provide some sort of background task that checks for changes every so often.
04-26-2012 10:55 AM
Thank you all for your precious answers
The init state i've posted was a try, so the constant values with which i unbundle-bundle previous state were intended as values to be loaded from a config file.
Finally i've found a way to realize what i wanted: creating a write property for my XControl, loading values from a config file and setting them at vi loading.
The important thing i have "discovered" is that when a (write) property node is called on the XControl, display change state is called in facade, and there DATA CHANGED in action structure must be set to TRUE state, otherwise there is no effect.