Showing results for 
Search instead for 
Did you mean: 

Persistent XControl instances

Re: Persistent XControl instances

Hi all, very interesting discussion about XControls i'm triying to discover! Smiley Surprised


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



1) Converting the previous state from variant to data, and setting a numeric to a constant value and boolean to TRUE directly in (i must find a way to pass this externally i hopeSmiley Sad)


2)reclustering both elements and converting to variant as input to the init CASE structure




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)



0 Kudos
Message 11 of 16

Re: Persistent XControl instances

Sounds like you need the opposite of what I needed Smiley Very Happy


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.

Thoric (CLA, CLED, CTD and LabVIEW Champion)

0 Kudos
Message 12 of 16

Re: Persistent XControl instances

[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]




Message 13 of 16

Re: Persistent XControl instances

Oooh - an XControl discussion Smiley Happy


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.



Thoric (CLA, CLED, CTD and LabVIEW Champion)

Message 14 of 16

Re: Persistent XControl instances

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.



Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."
0 Kudos
Message 15 of 16

Re: Persistent XControl instances

Thank you all for your precious answers Smiley Happy


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.



Message 16 of 16