XControl retain range properties

[Michael_78]

Intaris,

Now i'm confused.I said 'allow the xcontrol to save its own state using an ini file'.  You said NONONO.  Now you are saying let the Xcontrol save its own state in an ini file.  Please tell me why my first post was the wrong answer, and how it is different to your last answer.  Maybe, the difference is i was always thinking of the built exe, as most of my applications end up as exe's I always make my software 'exe proof' from the start.

Thanks,

MIchael. 

[Sam_Sharp]

Ok, I think I'm misunderstanding your reply Intaris but let me see if I've got the jyst of it...

1) When in the development environment, your XControl instance's state data is automatically saved/loaded when it is initialised. This data is stored (by LabVIEW) in the Parent VI.

2) When you build the XControl into an executable, you can't modify the Parent VI so the XControl's state is always loaded as when the executable was built. If you want this persistance, you can load/save the data in the Init and Save State to a file or registry key in the runtime engine instead.

It might break encapsulation, but surely programming the Parent VI to set the properties of the XControl is the same methodology for setting properties of all controls (e.g. native controls)? If you had instances of XControls that all read/write their own configuration to a file in built executables (as determined by the XControl developer) this is potentially worse than reading/writing the state of the XControl from the Parent VI (by UI Initialisation).

So in reality...I've gone full circle and realised that you can have an XControl save its state between launches of an executable by having it write its state to an INI file, but you probably shouldn't do it and just set the properties of the XControl in your Parent VI as per all other controls/indicators on the block diagram.

Apologies to the OP as this isn't really an answer to your question, just more of an extension to the discussion!

[Intaris]

---

@Michael_78 wrote:

Intaris,

Now i'm confused.I said 'allow the xcontrol to save its own state using an ini file'.  You said NONONO.  Now you are saying let the Xcontrol save its own state in an ini file.  Please tell me why my first post was the wrong answer, and how it is different to your last answer.  Maybe, the difference is i was always thinking of the built exe, as most of my applications end up as exe's I always make my software 'exe proof' from the start.

Thanks,

MIchael. 

---

The INI file is a given since you can't change the EXE if the code is already built. (with the term "INI file" I refer to any given method of nonvolatile storage you may prefer).  Post Nr. 7 was (IIRC) the first post to actually mention the ability to load and save within an EXE.  The OP makes no mention of post-compile operations.

To Summarise my position:

1. If you want the XControl to restore its state to the same as the last time it was active, I would tend to letting the XControl coordinate this itself (INI file).
2. If you want to gain ACCESS to certain properties in a controlled manner, then program your XControl accordingly with properties or methods.  You can then use this API in whatever way you like.
3. Only if you want to retain settings in the development environment can you do away with the INI file.

Is that any clearer?