Darren's Occasional Nugget 01/30/2014

[0utlaw]

---

@altenbach wrote:

---

@Darren wrote:

Windows

LabVIEW [20xx]\LabVIEW.ini

---

Just a reminder that this is machine-wide, and not per user, making things tricky if there are several regular users.

There are some good ideas ideas to move it to the user hierarchy or even move it to the cloud. 😄

---

Tip: The -pref flag also works with LabVIEW itself.  A single-line batch file or script will allow you to launch the development environment using any ini file you feel like.  Pretty handy for things like alternate VI Server configurations, default search directories, multiple users, etc.

-edit- Looks like that's already been discussed in the Idea Exchange threads you linked- still handy though!

Regards,

[rolfk]

---

@Darin.K wrote:

That API requires the path, and I presume is a wrapper around a CLFN back into LV.  The invoke node I use does not require the path, presumably because LV must know which path it has already used.  It just felt cleaner to me when I wrote my own options window.

---

You mix up this API with the normal config file VIs. These functions are calling directly into LabVIEW to access the LabVIEW configuration settings and most likely are used by the VIU based Options dialog in newer LabVIEW versions.

[EWest]

I know this thread is old, but I found this VI very useful until I encountered one roadblock: This VI does not  work the way I want it to when it is compiled into an executable application.

It returns the file path to the INI file for the EXE, not LabVIEW.exe. I suppose I understand why, but it's annoying nonetheless. The same is true for the VIs in "resource\dialog\lvconfig.llb".

 I'd like to make an application for standardizing the configuration of the Labview development environment. It seems like the only way to do this is to run it from the development environment. Any thoughts on how I can accomplish what I need from a compiled executable? 

[MichaelAivaliotis]

You could try having your executable make a VI Server connection to labview on the available VI Server port. From there you can probably do a few things like run VIs or various methods and properties.

[Darren]

Those VIs are not intended to access the LabVIEW INI file from outside of LabVIEW. To do this, you'll need to take Michael's approach with VI Server, or perhaps discern the installed LabVIEW path from the Windows registry (or whatever comparable technique you'd implement on Mac/Linux) and parse the INI file from there.

[Hooovahh]

Looking for installed versions of LabVIEW using Windows registry?

https://lavag.org/topic/18899-get-all-installed-labview-versions/#entry113674