Can a Global vi be 'called' dynamically?

Question

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

Answer 1

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.
Try to take over the world!