Best place for configuration files

[amaglio]

I am creating an application that gets installed into the the [ProgramFiles] directory. The application writes to a config file every time it closes and the user also has the ability to write a config file at any point in time. After the application is installed no configuration files can be written. I am getting the following error:  "LabVIEW:  File permission error. You do not have the correct permissions for the file."

1. What do I need to do to be able to write config files to the directory where the application is installed?

2. If I wanted to save the files in some users folder, how can I keep track of this path from the development environment, to the exe and then across different OS's?

3. Is there a general convention/location for config files that the application needs to write to?

I know during the build installer phase we can put data in all these different Microsoft folders. But is there a way to get the paths to these folders in my application? (see image below)

 

I am running Windows 7 and LabVIEW 8.5.

Thanks for your help

-Anthony M.

[JÞB]

Great Question!  And you'll get several different answers I'm sure,

My approach is to use the default data directory for configuration files and a path relative to that for production data

of course, I do not use the default and here's a snap of my Options

[amaglio]

But If I were to create an executable using that directory on Windows 7 I would no longer be able to write to it. It works fine in the development environment but as soon as I create an executable it no longer works. I get the permission error issue

[hecmar.arreola]

Yup, Windows Vista and 7 lock down the Program Files folder so that "user level" activity cannot modify the files within.  This is good design, and something you shouldn't try and overcome IMO.  You want users adjusting user space files, and not program or system files with the software they run.

I like how Vista and 7 moved "Documents and Settings" to "Users".  This is how Linux and Mac OS X are, and they are that way for a reason.  Because of this, I use the "Default Data Directory" file constant and make sub-folders from there.  I think in Windows XP the Default Data Directory is usually "C:\Documents and Settings\<user>\My Documents\LabVIEW Data" and in Vista/7 it is usually "C:\Users\<user>\LabVIEW Data".

Also, if you are making an executable with an installer you want it to work on someone's machine no matter what their folder structure is, or even where they decide to "stick it".  Some things to keep in mind:

* Avoid hard-file paths.  C:\ is not a gaurenteed location!  My home Windows 7 install is installed on H:\ and I have no C:\.  If you hard coded to install something on C:\ my computer at home would freak out.

* Use the variable [INSTALLDIR] for registry keys (if you need any).  That way, if the user decides to not install in the "Program Files" location you can still setup registry keys to associate file types and setup icons and what have you.

Good Luck!

-Nic

[shew82]

If you're using LabVIEW 2009+ there is a really useful VI for getting system paths (its in the Paths:Constants palette). There you will be able to get the user's application data folder (I cant remember what its called right now) - on Vista/7 it ends up C:\Users\UserName\AppData\Local\ and XP it ends up at something like C:\Documents and Settings\UserName\Local Settings\Application Data\. From here, the "proper" thing to do (According to Microsoft) is to create a sub folder for your company and another for your application. e.g.:

C:\Users\UserName\AppData\Local\MyCompany\MyProject

Within that folder you should be guaranteed write access for any files you like, and it keeps things nice and separate between users.

I normally implement a subVI to build that path for my app, creating the MyCompany\MyProject folders as needed (in case the current user has not run my app before).

Alternatively, store your settings in the Windows Registry under HKCU\Software\MyCompany\MyProject - again, this location should be guaranteed to have read/write access for your users regardless of account permissions (and again, make sure you attempt to create the location if it doesnt exist)

Shaun

EDIT: The VI I talked about in the first paragraph is called Get System Dir and is visible in Nickerbocker's screenshot, and if you're running an older version of LV, there is a win32 dll call or .net call that can be made to get the same paths.

[amaglio]

Thanks for your response Nic,

I have never mucked with the registry keys before and am very curios about what the benefits would be of  "* Use the variable [INSTALLDIR] for registry keys (if you need any)." I am assuming that this will allow me to install the application to a relative location rather than a hard coded location.... How do I do this? Thanks for your help.

Also, if I were to use the Dflt Data Dir.vi in my application, is there a 1 to 1 corespondance between the path that this VI spits out and one of the paths here?

It would be great to be able to get these paths within my code! Unfortunately I don't have LabVIEW 2009... 

[amaglio]

Thanks for your response shew82,

I like your idea of using the applications data folder, and thanks for letting me know of the "proper way" to store data here. I always like to do things in the proper way and to keep things consistent. 

What does storing my  settings in the Windows Registry under HKCU\Software\MyCompany\MyProject do for me? How do I do this?

Also, I have never made calls to the win32 API but have been looking into it after I read your post. Is the win32 something that is on all versions of windows or is it something that I should include in my installer just in case? Is there a recommended manual that goes over the possible functions available in this API and how to make calls to them? Thanks so much for your help!

-Anthony M.

[shew82]

1. Using the Registry

This is where Microsoft would like people to store their application settings - if you use this, you dont need to worry about where files are on a physical volume and your settings will play nicely for users who use different machines etc. The Windows registry looks a little like a file system in that it is hierachial, so you end up with locations that look a little like paths, except starting off at something like HKCU (which is short for HKEY_CURRENT_USER, a user-speciific space for data). To use the Windows Registry in LabVIEW there are some tools in the connectivity palette and some examples in the LabVIEW help.

2. Win32

win32 is basically how applications can 32 bit versions of windows - in LabVIEW it corresponds to a DLL call using the call library node. It can be a little tricky to setup as all of the documentation is aimed at C / C++ programmers. An alternative to win32 is .NET, this tends to be easier to work with in LabVIEW but is slower and requires that the .NET runtime be installed on whatever computer your app is going to be running on (this is a relatively safe bet on most modern copies of Windows). To find help on win32 or .net, it's genreally a case of googling and looking at results at msdn.microsoft.com.

3. What version of LabVIEW are you using? As I said, in 2009 the Get System Paths VI really is the easiest option. Failling that I might be able to through a .net version your way 🙂

[amaglio]

Yea, I am still running LabVIEW 8.5 over here. That .net code would be very useful!

Is win32 an actuall dll? Or is it a class of dll's? Is it on every windows operating system, so if you call it you don't ever have to worry about whether its going to be there or not?

Thanks for your help.

Anthony M.

[waldemar.hersacher]

Win32 consists of several DLLs. It is not .Net but the original interface in Windows to access operation system functions. It is available on every Windows PC because it implements Windows. The LV VI "File Dialog" is just a wrapper for the Win32 function FileOpenEx Which every program uses to select a file.

Storing user settings in the registry is outdatet. Modern Visual Studio programs store setting in files with .config extention.

Settings may be stored in various places depending of their need.

Settings which apply only to this special PC are stored where the application is installed. These settings are set during setup and won't change afterwards whithout any changes to the PC.

Settings which are common to different Windows users are stored in the All users\Appdata folder. The path to this folder is in the registry under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common AppData. Typical data stored there are test setups or serial numbers of external devices.

Data files which are common to different Windows users are stored in the All users\Data folder. The path to this folder is in the registry under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Documents. Typical data may be test result protocolls.

Settings which are unique to different Windows users are stored in the<username> \Appdata folder. The path to this folder is in the registry under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\AppData. Typical data may be personal number, department number.

Data files which are unique to different Windows users are stored in the <username>\Data folder. The path to this folder is in the registry under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Personal.

It is normal that the user has full acces to the last for paths and read access to the first path.

Use the Example Finder to find the registry VI examples.