Can a Global vi be 'called' dynamically?

[Ken_Naylor]

I know that a Global.vi is not a vi in the sense that it does not have a block diagram but can one be called/loaded dynamically?

If it can it could be used as a sort of configuration file (a graphical ini file if you like) for an executable built with the application builder.  The Global.vi could then sit outside the exe and be editable (albeit with a development version of LabVIEW) to change initial settings prior to calling the exe.

If installed on a machine without a Development LabVIEW the global.vi would not be editable, making it safer than an ini file as setting could not be changed accidentally.

Any Thoughts

Ken Naylor

[Norbert_B]

Ken,

global variables cannot be loaded dynamically and they cannot be located outside a build executable.

I recommend you to implement some code for managing a configuration file (.cfg or .ini) where you store the settings and pick those up when launching the application.

Norbert

EDIT: Gerd's answer below is more accurate. My remark is correct if you keep that global as a global variable in your code (using the node). If you rewrite that to load and handle it dynamically, you can achieve it, just as Gerd points out. Nevertheless, if you are going down that road, working with more advanced techiques like FGVs or similar data storages is recommended.

[GerdW]

Hi Ken,

yes, you can dynamically open that VI (afterall it's just a VI). You can also get references to all FP elements to read their values.

You cannot use the global variables of that VI in your code as this would automatically embed the VI in the EXE…

Edit:

And yes, I would also recommend Norbert's approach to use "more standard" files for configuration data. When it comes to security you should rather think about encryption…

[Ken_Naylor]

Thanks Norbert

That is what I do currently but the thought came to me in an 'out of the box' moment.  I thought that might be the case but thought I would ask anyway.

Thanks for your prompt reply

Ken 

[tst]

You can actually do what you want, but not in exactly the way you want.

You can load a global VI dynamically, but that won't help you, because the actual reading and writing in the BD are all completely static. Likewise, you can modify values in the global in the EXE, but you can't save the VI, so the values won't persist. You have to save the values somewhere else.

A global VI does actually have a BD (although you can't access it or do anything with it, so it's not relevant) and, more importantly for this, it has a front panel, and you can do anything with it that you can do with a standard FP. You can use a static reference to the VI (from the Application Control palette) and use something like the OpenG R/W panel VIs to load and save the controls. You can put the FP into a subpanel to display it. This should allow you to edit the values in the global and save them to an INI file. I didn't check, but I'm guessing that if you build this into an EXE, you will have to configure the global VI not to strip the FP. This can be configured in the build or by changing a property on the global (like not showing the scrollbars).

All that said, I wouldn't necessarily recommend this for a few reasons. There are the usual arguments against globals (potential race conditions, etc.), which you can decide what you want to do with (you might decide that you trust whoever uses the code), but there's also the problem where you tie the config straight to the UI. That means that your UI has to show the same data type that you save and you can't create protections. This might work for you as well.

[Ken_Naylor]

Thanks for all your replys.

Thinking futher on this (somtimes a dangerous thing) the proposed data stored in my 'dynamically loaded global.vi' are not variables but are constants containing thinks like COM port identifiers Paths to data files and storage areas (which may evolve at the whim of out IT department).  Any changes curently mean a change to global.vi and a rebuild.

True, reading config and ini files at initialsation would do the same thing (and as I said that is what I currently do) I just thought if the above was possible then this might be easier.  Interesting discussion though.

Nice to get replies from a 'Trusted Enthusiast', 'Proven Zelot' and a 'Knight of NI'

I am truly honoured !!

Thanks

Ken

[Hooovahh]

---

@Ken_Naylor wrote:

Nice to get replies from a 'Trusted Enthusiast', 'Proven Zelot' and a 'Knight of NI'

---

Lets round things out and get an opinion of an Active Participant.  And my advice is "what they said".