LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
cancel
Showing results for 
Search instead for 
Did you mean: 

XControl volatile state

It would be nice if XControls could maintain arbitrary state information akin to display state but was volatile and so not preserved when the XControl was saved and (importantly) did not set the VI modified flag when it was changed.

 

An XControl's display state is the natural place to store all state information about the XControl that you might want to access via property or method nodes as well as via user activity on the facade.  However, anytime the State Changed ? flag is set in the facade, then container vi is marked as having unsaved changes. This is obviously sensible if the state change is meant to persist - e.g.. control resize, but not if the state change is volatile and can bee discarded after each run.

 

There are various alternative methods that can currently be employed, but they are not satisfactory:

1) Additional shift registers on the facade - are not available within property or methods

2) Storing volatile state data in LV2 style globals - unfortunately the same global is shared between instances of the XControl. This is still the best solution as the Container refnum can be used to generate a per-instance unique identifier to enable the global to manage the state data for all instances of the XControl.

3) Storing volatile state data in a 1 element queue. There are two problems - firstly some daemon process needs to be able to keep the queue reference alive but this adds complexity in making sure the dameon process shuts down cleanly. Secondly, there is still a problem of ensuring separate data storage between instances of the XControl.

4) Storing volatile state with the data. This works where the data type supports attributes I.e.. variants and waveforms but not for the general case.

5) Storing volatile data in a tag of the container refnum. This requires scripting and private methods and only works in the development environment.

 

A better solution would be an additional ability type def that is provided for volatile state, presented as a control/indicator pair for properties and methods and prepare to save, wired through on a shift register for the facade and presented as an indicator to init and as a control to uninit.

--
Gavin Burnell
Condensed Matter Physics Group, University of Leeds, UK
http://www.stoner.leeds.ac.uk/
2 Comments
Member

I think this is a good idea because, when we work with multiple developers or with source code control (for exemple subversion client) there are often conflicts or modifications loss caused by "unsaved changes".

Julien
Example Gatekeeper
Status changed to: Declined

National Instruments will not be implementing this idea. There is no further feature development planned for XControls.

DNatt, LV R&D