Persistent XControl instances

[Thoric]

Dear collective,

I'm in the process of developing a particular XControl that needs a persistent configuration. In other words, a developer will be able to drop the XControl down onto their front panel and configure it via a series of right-click menu options (or otherwise, such as a pop-up panel), and the XControl instance will store this configuration information. Then, when their code is built into an executable, for example, the XControl will recall and use this configuration to customise its appearance and behaviour.

To ensure this is hidden from the developer, the configuration information cannot be stored externally (such as in a file - which presents risks anyway), but within the XControl itself.

I can think of a couple of implementations (stored as a cluster's default values, XControl tags etc.), but I'm not sure I necessarily have the best implementation for this in mind. Therefore I'd appreciate hearing from the LabVIEW community on any ideas you all may have.

Thanks in advance everyone for your contributions.

[tst]

Since this will be built into an application, you HAVE to save it externally. All the XControl info is part of the caller VI, and since the RTE can't save the VI, that leaves you with saving it externally.

If you're worried about security, you can with anything from placing the file where no one would look (which is probably a good idea anyway) to encrypting the data to using a mechanism where access can be restricted (such as the Windows registry or a database).

Since the code for saving and loading will probably be in the XControl, you should probably have it recognize both its calling VI and its label in that VI so that you have a way to uniquely identify each instance.

[Thoric]

Hi tst,

I may not have been very clear, but the built executable doesn't need to change the configuration, so the RTE doesn't need to save the VI (I'm well aware that the RTE cannot do this).

To summarise:

• In the LV development environment, the LV developer will drop the XControl onto their front panel and configure it there.
• This configuration will have been stored in the XControl
• When the VI is run (in either development environment or as part of a built executable) the configuration information is loaded/extracted from it's place by the XControl and used to configure the appearance and behaviour of the XControl.
• When the VI is built into executable, the configuration should be (and will unavoidably be) unchangeable - a persistent instance.

So, in short, the configuration only needs to be created in the development environment, so I could store it in a hidden control (cluster of settings), or use custom tags attached to the XControl perhaps.

What I'm looking for are other possibilities for storing the configuration details.

[tst]

In that case I would definitely go with tags - they are exactly the mechanism which is designed to hold data associated with a control (with persistence). It's possible that the XCtl itself has something to deal with this (such as the state data), but I'm fairly sure that none of it gets saved.

I don't have a lot of experience with dealing with the VI-XCtl interaction, but since the tags belong to the instance, you will need to have access to the reference of the instance inside the XCtl VIs. I don't remember off hand if that reference is easily accessible.

Also, I don't remember for sure, but it's possible that the tag write methods don't set the docmod on the VI (making it dirty), so it's possible you will have to do that yourself.

[Ben]

Isn't that what the Init and Unit are intended to do?

The resutlst are stored internally to the XControl (or is the owning VI?) and the version number stuff lets you adapt when your data structures change with new versions.

maybe I'm just reading this Q wrong so please forgive if tht is the case.

Trying to help,

Ben

[Thoric]

Hi tst,

Yes, my thoughts are to use tags. I can get the parent VI ref relatively easily, but I do have one conundrum - what if the parent VI contains more than one of the XControls? If I were to search the parent VI programmatically for controls matching the XControl's type, how would I be able to differentiate between them?

Thanks for the tip on dirty dots, that's something I would have overlooked I'm sure!

Ben: I've not used XControls much before, I've only toyed with them, but I do see a "Previous State" control which could be what I'm looking for

But what about the Unit.vi you mentioned? Are you refering to the "Convert State for Save" ability? I need to do some more reading...

[tst]

Random thoughts:

1. The "unit" Ben was referring to is "uninit" - the VI which is called when the XCtl is removed from memory. He may be right that the init VI can be used for this, but I'm still pretty sure you would need to save the data somewhere.
2. The container state cluster seems to hold a reference to the XCtl instance, so that makes it easily accessible.
3. Re. the dirty dot, I was only bringing it up as a possibility. It's quite possible that it works correctly, so you should test it.
4. I haven't actually done something like this with XCtls, so it's possible there is a built in mechanism for this. Reading up on them is definitely a good idea.

[mikeporter]

What you are describing Thoric is the way XControls normally work. The state for each instance is stored in the calling vi - even if the xctl is instantiated multiple times. Remember also that XControls are inherently reentrant.

Mike...

[Thoric]

That's two experts who have said this requirement is native to XControl behaviour, so I decided to create a quick test XControl. And well I'll be damned!

[Ben]

---

@Thoric wrote:

That's two experts who have said this requirement is native to XControl behaviour, so I decided to create a quick test XControl. And well I'll be damned!

---

Don't you love it when you wished LV would do something only to find out it already does?

Its almost as good as your dog bringing you your "slippers and pipe"* without prompting.

Ben

* ("Take me like I am or Leave Me Be" Oklahoma, the musical)