Where Do I Save Config Files In LabVIEW?
When writing applications that will be used by anyone else you will need a configuration file. In my experience, this is almost universal and the more I make configurable, the more powerful the software becomes and the less small changes I have to make for my customers.
Where do we save config files in LabVIEW? The landscape is more complicated than you would think! In this post, I’m going to summarise what we do on our LabVIEW projects. We are focusing on Windows since RT is simpler (put it in /c/) and I don’t use Mac or Linux with LabVIEW.
Types of Config Data
I’m going to refer to two types of config data:
- Global Data: No matter who logs into the system they should share the same configuration. In my experience, this covers the vast majority of industrial applications.
- User Data: Configurations that should change depending on the user. This might be screen layouts for example.
Files or Registry?
Microsoft is actually quite keen that you put this data in the registry – that is what it is for. There is a Software folder in each top level folder where you should create your own Company/App folder structure and you can store settings as different variable types.
For user data, you can store it under HKEY_CURRENT_USER and for global data, you can store it under HKEY_LOCAL_MACHINE. In many ways it is a pretty nice solution to the problem, however, I’ve avoided it for 3 reasons:
- Files are much easier for users to get, edit or send you. Whilst I don’t want them directly editing the files much it is great that when there is a problem they can send me a file or even a screenshot of the file (when it is readable) so I can understand their setup.
- Files make save as… much easier if the user wants to be able to switch between configurations.
- Files are universal. Although I don’t have much cross-platform code I like that I can create multi purpose configuration libraries that work on Windows or RT. Without this, I would have to have different code for the different platforms.
I am curious though about who is using this. Please leave a comment below and let me know why you like this and if I have anything wrong.
If Files, Where?
OK, so we have decided on files, where should we put them? Helpfully Microsoft has an article on this however 7 years on there are still issues!
User Data
User data is the easiest and where Microsoft’s advice still works. In each user folder, there is a hidden AppData folder. This is designed to hold user-based configuration files and so the user has full read/write access to this. It is just hidden to protect you from “users with initiative” as Fab puts it in this presentation! Within here you should create a folder structure with Company Name\App Name to follow the standard convention.
To get this path use the Get System Directory.vi with the User Application Data input.
Global Data
Global data is where this gets messy. There is an equivalent folder to the user AppData folder for this purpose, but…
In XP all worked well. It was located under All Users\Application Data and all users had write access and software worked.
Then Windows 7 came and two changes occurred:
- The location was changed to C:\ProgramData (A hidden folder)
- Folders had restricted access. The creator/owner has write access but no-one else.
One use case for this is to install fixed configurations at installation time and this works well since everyone has read access. However, if you need to write these after installation you normally do not have access.
The solution to use this? You need to set the permissions as part of a post install step to allow all users to have write access to the relevant folders.
One day, I may sit down and get this set up automatically as a post install step. For now, I have too many concerns about managing failures of this causing extra support. My solution? Use the public documents folder.
I follow the same structure but in Public Documents instead of Public Application Data. So far I’m happy with this decision and I haven’t had any headaches due to this.
I would love to hear your thoughts. What do you do? Am I wrong?
Gregory
August 15, 2017Hi James, thanks for the article! I usually just store the config file(s) next to the project or executable file using the “Application Directory” primitive.
I’d also like to see an article or just some thoughts on what format you use for config files. Usually mine are small, just 10 or 20 parameters to remember from run to run, so I’ll use one of the toolkits for writing clusters to an .ini file.
James McNally
August 15, 2017Hi Gregory,
Thanks for the comment.
File structure is still up in the air for me, look for a future post! Right now I tend to either use JSON for more complex data or ini for simpler applications. I’m planning to investigate SQLite though – especially if I can create an easy viewer for it. Either way I want to standardise so I can hopefully create a somewhat general library and viewer.
The sneak peak of what I don’t use is XML. I find it fails on human and machine readability (often needs big external dependencies to work). I have used the object flattening to XML before but it has broken often enough to be a problem and they are VERY difficult to recover when they do. (I once had to spend 2 hours re-entering configs by reading out of the xml and entering it in the application because I could not find why LabVIEW didnt like it!)
Vik
August 22, 2017Hi James,
If you do not have high expectations for the database viewer, you can use the open source browser for it:
http://sqlitebrowser.org/
We are using it with Teststand style databases, it is good enough for basic checking and editing.
Cheers
martijn smeulers
August 20, 2017Ho Gregory,
We experience some write access rights problems doing this can depend on the user rights, so to be safe with also applications which are going external we use public documents and creating an application folder there containing error logs config and settings files
Brian Powell
August 19, 2017I personally prefer using files (appdata or programdata). It’s more self-contained, and as you point out, you have more freedom to choose your own storage format. If nothing else, it’s easier to delete the files for a clean default configuration reset, vs. having to make sure you delete all the registry bits.