Xcontrol Edit Time Persistance

[viSci]

Just thought I would post this in case others have wondered how to get each instance of an xControl to preserve edit time settings such as scale ranges, control labels, etc.

I had hoped that it would be as simple as making the changes on each instance then doing a 'make current values default' and saving the top level vi. Alas, it does not

work that way with xControls. However you can stash away all your setting in xControl container Tags. Within any Facade case, grap a Container State Refnum and utilize the Tag.Get

and Set methods to store anything you want within the container instance. All the tag info remains unique for each xControl instance and the aggregate gets saved within the top level vi.

[Aristos Queue]

Just thought I would post this in case others have wondered how to get each instance of an xControl to preserve edit time settings such as scale ranges, control labels, etc.

I had hoped that it would be as simple as making the changes on each instance then doing a 'make current values default' and saving the top level vi. Alas, it does not

work that way with xControls. However you can stash away all your setting in xControl container Tags. Within any Facade case, grap a Container State Refnum and utilize the Tag.Get

and Set methods to store anything you want within the container instance. All the tag info remains unique for each xControl instance and the aggregate gets saved within the top level vi.

Storing this information is what the ContainerState is for. You should put all that info in the ContainerState and then it should just be there without having to muck about with tags.

[viSci]

Well I have the Tag version working but cannot seem to get your method to work. I believe you meant to have me use the Display State cluster instead of the Container State. I added the 'Convert State for Save' ability

but am not sure what I need to do to the Init ability to retrieve the information and get it back to my controls. I have a Display State Change event where I transfer the Dispaly State In to my controls but

the data appears to be empty.

[jgcode]

Well I have the Tag version working but cannot seem to get your method to work. I believe you meant to have me use the Display State cluster instead of the Container State. I added the 'Convert State for Save' ability

but am not sure what I need to do to the Init ability to retrieve the information and get it back to my controls. I have a Display State Change event where I transfer the Dispaly State In to my controls but

the data appears to be empty.

I am sure AQ meant the Display State?

Anyways, here are some quick examples:

You can use the Init Ability to reload the state from disk and set it back into the Display State. You can also use Version Control to handle older States.

You can use the optional Convert State for Save Ability to remove non-persistent data e.g. references, large data sets.

[viSci]

Could you please tell me where in the Init code the saved display data is retrieved from disk? Is that something built into the xControl infrastructure or does the user have to provide that intelligence.

Is there a certain data structure that has to be created within the Display State typedef to make this work. I simply placed my data elements flat into the cluster but it does not seem to automatically save it.

[Ton Plomp]

The variant input in the init ability returns the data saved in the 'Convert data for save'.

You can inspect the actual variant with the Variant Data Probe

Ton

[Norm Kirchner]

I think that this highlights a much deeper problem with regards to the storage and retrevial of properties of a control.

Currently, if you utilize a run-time customizable control such as a graph, there is no built in way of storing these properties. It is necessary to harvest all the properties you want (not flexible or scalable) and then create the necessary homes for them in the Container State.

I belive that it was Ton that had created a tool that would allow you a way to navigate and store and re-store the properties of 'almost' any given control.

Ton, am I remembering correctly?

The reason a tool for this is so needed is because of the diversity and sheer numbers of properties for run-time modifiyable controls.

Sure, you can take it on your own to just find those properties of interest, but undoubtedly your users at some point will wonder why one of their changes were not saved when the others were.

Maybe this warrants a spawned thread....

[jgcode]

Storing this information is what the ContainerState is for. You should put all that info in the ContainerState

Currently, if you utilize a run-time customizable control such as a graph, there is no built in way of storing these properties. It is necessary to harvest all the properties you want (not flexible or scalable) and then create the necessary homes for them in the Container State.

Given that two high level posters have said this....

Am I missing something here? Isn't the State.ctl designed to be use for all your persistent and non-persistent data? Aka the "Display State" not the "Container State" ??

[Norm Kirchner]

Given that two high level posters have said this....

Am I missing something here? Isn't the State.ctl designed to be use for all your persistent and non-persistent data? Aka the "Display State" not the "Container State" ??

HA, the only reason I said Container State was because I couldn't remember it's exact name off the cuff and used what Stephen had said.

Serves me right to make a mistake by referencing a 'TBP'. How silly of me.

*TBP (Text Based Programmer)

But yeah, you should be storing that information in the 'Display State'

[jgcode]

HA, the only reason I said Container State was because I couldn't remember it's exact name off the cuff and used what Stephen had said.

Serves me right to make a mistake by referencing a 'TBP'. How silly of me.

*TBP (Text Based Programmer)

But yeah, you should be storing that information in the 'Display State'

I always like to know how to do things differently/better, but I had to check on this one!

Thanks for clearing that up!

[gb119]

I've been having the opposite problem - trying to work out the best way to store volatile state information for an XControl. If one writes this into display state then you end up with LabVIEW thinking it needs to re-save the parent vi which is a pain. (By volatile state I mean things about the appearance or behaviour of the XControl that need to be kept track off during runtime, but can happily be rest to default values when the program stops - values of sub-controls that form part of the XControl for example).

I think the answer is to use one of the traditional storage mechanisms like a LV2-stlye global(FGV/USR) but then I got to wondering what happens if I have multiple instances of the same XControl - I know XControl's facades run in separate applications instances, but do multiple XControls share the same application instance or do they get one each ?

What do others do about volatile state data ?

[Norm Kirchner]

I've been having the opposite problem - trying to work out the best way to store volatile state information for an XControl. If one writes this into display state then you end up with LabVIEW thinking it needs to re-save the parent vi which is a pain. (By volatile state I mean things about the appearance or behaviour of the XControl that need to be kept track off during runtime, but can happily be rest to default values when the program stops - values of sub-controls that form part of the XControl for example).

I think the answer is to use one of the traditional storage mechanisms like a LV2-stlye global(FGV/USR) but then I got to wondering what happens if I have multiple instances of the same XControl - I know XControl's facades run in separate applications instances, but do multiple XControls share the same application instance or do they get one each ?

What do others do about volatile state data ?

There is nothing about the XControl that says you can't have another shift register on the while loop.

Or another technique is to utilize the 'Close' ability of an XControl to clear state data that you don't want retained.

[gb119]

There is nothing about the XControl that says you can't have another shift register on the while loop.

Or another technique is to utilize the 'Close' ability of an XControl to clear state data that you don't want retained.

The problem with a shift register on the facade is that you can't access the volatile state in a method or property node.

I *think* what I'm seeing is that the 'unsaved changes' flag of my main vi gets set as soon as I modify the display state cluster, so although I can purge it of unwanted data at close, won't LabVIEW still try to save the vi even though there are no 'real' changes. This is mainly an annoyance since it adds extra entries in my revision control system for no good reason.