NI Home > Community > NI Discussion Forums

LabVIEW

Showing results for 
Search instead for 
Do you mean 
Reply
Member
Mariano76
Posts: 77
0 Kudos

Re: Persistent XControl instances

Hi all, very interesting discussion about XControls i'm triying to discover! :smileysurprised:

 

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:smileysad:)

 

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)

 


 




Active Participant
Thoric
Posts: 1,498
0 Kudos

Re: Persistent XControl instances

Sounds like you need the opposite of what I needed :smileyvery-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 and LabVIEW Champion)
Knight of NI
Knight of NI
Ben
Posts: 16,149

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]

 

Ben

 

Ben Rayner
Who is now transitioning to John Galt.. just building Rayner's Ridge
Rayner's Ridge is under construction
Active Participant
Thoric
Posts: 1,498

Re: Persistent XControl instances

Oooh - an XControl discussion :smileyhappy:

 

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 and LabVIEW Champion)
Proven Zealot
mikeporter
Posts: 5,111
0 Kudos

Re: Persistent XControl instances

[ Edited ]

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.

 

Mike...


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."
Member
Mariano76
Posts: 77

Re: Persistent XControl instances

Thank you all for your precious answers :smileyhappy:

 

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.

 

 

Spoiler