openG Configuration Library, error post build

[nrosenberg]

Hello All! 

First post here, please go easy and I look forward to learning from you all!

I have a vi that is using the open g configuration library to save and load a number of controls.  More precisely, I have 1 cluster of 3 numerics, and 3 separate numerics.  I have all my code working wonderfully before I compile it, but once I compile it I get the following error when I try to load from the file:

Get Queue Status in NI_LVConfig.lvlib:Get File Path.vi->NI_LVConfig.lvlib:Close Config Data.vi

Additionally, while I have the 'Create File if necessary' input wired True, the vi never creates the file.  Again, this all works pre-compiled, but fails in the compiled code. 

I've attached some screenshots of the code in question, please let me know if I can provide further info.

Thanks,

Nate

[drjdpowell]

You are trying to create your ini file adjacent to your vi; in your exe that path is inside your exe, which cannot have files created in it.  You need to have your ini file in a different place.

[Jim Kring]

I think that the error is in the use of "Current VI's Path".  When you strip up one level in development mode (when the Current VI is directly in a folder) then you get the folder where the VI is located. For an EXE, the VI's path will be nested inside some virtual folders inside the EXE file.  Try using the OpenG VI "Get Current VI's Parent Directory.vi" this is a bit smarter in terms of getting the actual OS folder where the VI/Code is located.

 

You can call it like this -- both of these snippets are equivalent.

Edited September 3, 2020 by Jim Kring

[nrosenberg]

@Jim Kring & @drjdpowell Fantastic!  Would've taken me ages to sort that out, thank you very much!

 

[LavaBot]

Why not use the LabVIEW's native Application Directory VI?  This automatically takes into account if you are in development mode or runtime (exe). 

Application Directory VI

Owning Palette: File Constants

Requires: Base Development System

Returns the path to the directory containing the application.

If you call this VI from a stand-alone application, this VI returns the path to the folder containing the stand-alone application.

If you call this VI from the development environment and the VI is loaded in a LabVIEW project file (.lvproj), this VI returns the path to the folder containing the project file. If the project is not saved, this VI returns <Not a Path>.

[Jim Kring]

@LavaBot - I can't speak directly for @nrosenberg, but from my experience, one of the challenges in creating applications is creating code that works in both the development environment (source code) AND in a built applications (exe). So, if Application Directory is used, then the path will point to the LabVIEW installation location when running from source code. So, we don't want to use that node/function when running code in development. Instead, we would probably want to test for whether the code is running in development or the build application and then build our path differently.  However, simply putting our file in the folder next to wherever the VI is running (by using "Get Current VI's Parent Directory.vi") is an OK solution to this problem.  Yet, in most larger applications that I see, a more specific solution is used, as to where files should be placed in development vs deployed environments, since there are often a lot of files and we generally want to organize them all a little bit better (under some base folder of settings), even in source mode (and not have a bunch of important files sitting next to VIs throughout our project source code folder).

[Rolf Kalbermatter]

  On 9/10/2020 at 7:00 PM, LavaBot said:

Why not use the LabVIEW's native Application Directory VI?  This automatically takes into account if you are in development mode or runtime (exe). 

Expand  

Generaly speaking this is fine for configuration or even data files that the installer puts there for reading at runtime. However you should not do that for configuration or data files that your application intends to write to at runtime. If you install your application in the default location (<Program Files>\<your application directory>) you do not have write access to this folder by default since Windows considers it a very bad thing for anyone but installers to write in that location. When an application tries to write there, Windows will redirect it to a user specific shadow copy, so when you then go and check in the folder in explorer you may wonder why you only see the old data from before the write. This is since on reading in File Explorer, Windows will create a view of the folder with the original files in the folder if they exist and showing the shadow copy files version only for those files that didn't exist to begin with. Also the shadow copy is stored in the user specific profile so if you login with a different user your application will suddenly see the old settings.

Your writeable files are supposed to either be in a subdirectory of the current users or the common Documents folder (if a user is supposed to access those files in other ways, such as data files generated by your application), or in a subdirectory inside the current user or common  <AppSettings> directory (for configuration files that you rather do not want your user to tamper with by accident). They are still accessible but kind of invisible in the by default invisible <AppSettings> directory.

The difference between current user and common location needs to be taken into account depending if the data written to the files is meant to be accessible only to the current user or to any user on that computer.