Application Settings and Options - Active Settings Implementation

[Lewis_G]

An application that I have written must currently be restarted to load its updated configuration (just like LabVIEW.ini).  However,  I want to change this to have Active settings that can be edited and updated at run-time.  Doing some reading lead me to this Managing Application Settings and Options in LabVIEW Applications - Options Dialog Framework (ODF).

Copying directly from this page

" There are quite a few different implementations of an Active Settings component in use in the LabVIEW community today, each offering different advantages and drawbacks, partially based on the personal preference of individual developers. These implementations include:"

• Global variable
  • Individual settings
  • All settings in a cluster
• Functional Global Variable (FGV)
• LVOOP Class
• Shift Register
  • Settings cluster
• Shared Variables

I currently have all of my settings stored in a LVOOP Class.  I'm thinking about having a Settings Dialog which allows users to change individual settings and then when close is clicked, it overwrites the current binary file and pushes the updates to a global variable.  Anywhere the settings are used,  they can read from the global variable and use the accessors of the class to get the settings.

I want to find out more about these implementations before I try and implement one of them.  Does anybody have any advice to offer?

[Chris_Jones_NIUK]

Hi Lewis,

Apologies for the delayed response.

This is a very interesting question and I think you'll get very different responses from different people, as I think this is an area which tends to be quite subjective. Either way, here's my take:

Global Variables:

- Can actually provide quite an elegant solution, as by storing settings in a cluster you can categorize them and make selection of the variable you want to get/set a case of selecting from the global on the block diagram.

- If someone who is quite new to LabVIEW looks at your code and needs to understand it, It's one of the easiest methods to understand.

- Darren Nattinger actually suggests this type of use for Globals: http://labviewartisan.blogspot.co.uk/2010/06/i-like-global-variables.html

FGV:

- I can't see any advantage over Global Variables for this application, although I'm sure there must be something I've missed. I can't see any danger of race conditions when using Globals, as explained in more detail in Darren's post blog linked above.

Shift Register:

- Settings clusters can be commonplace in applications.

- If your application is based on a state machine, this fits in quite nicely as the while loop provides the shift register, and you can unbundle to access settings in cases if required. If a case does not need access to a setting, then you can simply leave the cluster wire 'passing through'

OOP Class: 

- For simply maintaining values, this may be overkill.

- More of a learning curve for those not familiar with OOP.

- May provide some benefits for more complex/higher number of settings - although I can't specifically think of anything at the moment.

Shared Variables:

-If your application isn't running over a network, I can't see any advantage compared to previous methods.

I hope my reply is somewhat useful, but if anyone else has any opinions on this, it would be great to get someone elses take.

[Lewis_G]

I have opted for a "Settings" Class stored in a global variable.  Its nice an easy to write the class to a binary file then.  Thanks Chris