Where should support files (with read/write access) be placed on the target PC?

[Dave_F1]

I am building a LabVIEW application that will be distributed to multiple PCs. I have a configuration file that I need to read and write to. I need a file location that I can reach on the vast majority of computers running Windows XP and VISTA. VISTA appears to restrict the ability of an application to create and write files in the program files folder. Where is the best location to store this file? Any suggestions will be greatly appreciated. Thank you, Dave F

[Guruthilak]

normally the suport files are kept in the same location where the exe gets stored (afetr you install your application) usually in a folder called support files. Now its up to you whether to expose the contents of the support files to others.

Also usually some of the support files (in case of ini or any other such files which are required bu the application to startup) will be looked by the application for its startup and they will get auto generated if does not exists.

If you have a problem of user tampering with the files then you can place it anywhere on the target PC. its up to the programmer....

[Robbob]

Depending on how complex your ini file is going to be and how often you plan on writing/reading to it, you can always make your own windows registry keys as well. See 'Create Registry Key.vi.' When you build your installer, you can also create the registry key. Some people dont like these though as it may be a pain to clean up the registry entries once the application is done. It does, however, prevent the user from deleting an ini file if they arent sure what it is.

[waldemar.hersacher · Accepted solution]

Microsoft recommends exact locations an registry keys where to store information for different purposes.

These are the rules we use in the company and they will work on VISTA and Windows 7 too.

Do not click on the links. Thsi is an exerpt from our online help and I din't got a method to convert them to plain text without rewriting them.

LabVIEW and the Windows registry store the information where all those folders are located within the file system.

Path	Usage
Application folder	When running as a standalone application this location can be retrieved with the LabVIEW function Default Directory. When running in the development environment the module will retrieve the location of the project file using property nodes. For this purpose the project must define a symbol named Development_Mode.
Temporary folder	This location can be retrieved with the LabVIEW function Temporary Directory.
Group application folder	This location can be retrieved from the registry under the key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common AppData.
Group data folder	This location can be retrieved from the registry under the key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Documents.
Personal application folder	This location can be retrieved from the registry under the key: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\AppData.
Personal data folder	This location can be retrieved from the registry under the key: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Personal.

For all these folders excluding Application folder subpaths are are added. The subpaths will be retrieved from the application configuration file located in the Application folder and named get_paths_for_app.config. This file is an XML or Config Data file dependend on a 1symbol set in the project containing two elements Vendor and Application. These both elements will be added as subpaths.

The only thing I haven't solved yet is the path to the project file.

Message Edited by waldemar.hersacher on 11-23-2009 10:25 PM

[waldemar.hersacher]

Finding the project folder has been solved here. The mentioned symbol Development_Mode is not neccessary.

[craigc]

If you dont want people messing with Ini files etc you could always save them as a binary file / encrypt them with a simple password.  You can then give the file a different extension which you can handle in a small application / editor (written in LabVIEW) for your ini file from then on in.

🙂

Craig