XControl retain range properties

[Richard_Ha]

Hi Guys

I've just created an XControl for an object. It has the object as it's data and in the facade VI there is a gauge indicator.

The gauge indicator shows the value of the data, and the background changes colour depending on alarm and warning limits within the object.

It's all working great, I drop it on the FP and can adjust the scale. However, as soon as I close the FP that contains the XControl on it, the scale resets. Is there anyway I can set each instance of an XControl to retain it's scale information?

[mikeporter]

Yes, you have to save the scale information as part of the control's state data.

Mike...

[BowenM]

---

@Richard_Ha wrote:

Hi Guys

I've just created an XControl for an object. It has the object as it's data and in the facade VI there is a gauge indicator.

---

I tried doing something exactly like that for a fairly large project a few months back. It caused far more problems than it solved, and I ultimately trashed the idea. It worked great at first, until I wanted to allow the class to interact with the XControl properties.  The XControl used some class properties.  Once I loaded the control into memory, it instantly put it in to runtime mode.  (Controls calls class, class calls control, control thinks it is loaded into a VI's memory and goes in to run time). 

So, some unsolicited advice:  Be very careful about where you use any XControl references or properties inside your class 🙂

[Richard_Ha]

So I grab the gauge min and max values from the gauge property node and save them in to the display state cluster?

How does I make this "load" back to the control when the VI reopens?

Is this display state unique for each isntace of the control? If I want some of the same XControl with a 0-10 scale and some with a 0-100 scale?

[mikeporter]

Check the documention for the INIT ability.

Mike...

[Michael_78]

Hi,

I would use a config file, or registry key to hold the state information.  this thread shows how to get the label text from within the xcontrol.  Use this to identify each instance of the control, then you can have each xcontrol load and save its own state information.

[mikeporter]

This is also required if you are going to have information persistent between executions in a standalone executable. The first thing to learn is how the loading and saving of state information works.

Mike...

[Intaris]

---

@Michael_78 wrote:

Hi,

I would use a config file, or registry key to hold the state information.  this thread shows how to get the label text from within the xcontrol.  Use this to identify each instance of the control, then you can have each xcontrol load and save its own state information.

---

No no no. This is how to NOT do it.

The XControl has an explicit ability to load and save settings which should persist.  It should be completely transparent to anyone using the XControl.  Having to programatically do this is really to be STRONGLY discouraged as it essentially has NO benefit and a LOT of drawbacks.

[Sam_Sharp]

Intaris - does this still happen in a built executable?

My understanding (from here: http://www.vi-tech.nl/public/files/downloads/LVUG2009_XControls.pdf) is that the persistant state information is stored in the Parent VI - of course a built executable can't modify itself to save the state so it must load the state as when the executable was built and won't stay persistant each time you run the executable unless it stores the state information somewhere else when running in the run-time engine.

I don't think this is the case for same reason that changing scales on graphs in an executable isn't persistant between launches of the executable. If you change a control property while an application is running in the development environment it will be persistant between runs and the changes to the properties can be saved with the VI. If you change a control property in an executable, it won't be maintained next time you launch it.

[Intaris]

The XControl should always store its own information (most likely updating on the fly as settings are changed) in order to then re-load the next time the XControl is instantiated (Which for changes in compiled code requires some kind of INI file).  This should still be done in the INIT method of the XControl and not by the parent VI.

Offloading this work to the parent VI completely breaks the encapsulation of the XControl.