Leaderboard

The problem with the public application data folder is that only the user that first ran the program will have access to the configuration files the application created under ProgramData. One might say that the data is not really public...ironically enough. So if a second user logs in and you want that user to be able to see the same application configuration and maybe also do things that will affect it - ProgramData will not work unless you change the access properties of the files in programData. There are plenty of web sites that discuss this dilemma, and it's the reason why I suggested this idea on the idea exchange. This is why we normally use the user's application data folder instead if it's a user-run program, but we use the ProgramData folder if it's a service that always runs under the same user. Mads

After Paul's comment I just had to take a look, and... I guess you did warn us. If you're planning on doing any more Labview development I recommend learning the state machine design pattern. It's a fairly simple pattern that will go a long ways towards making your code more readable and maintainable. Not a chance. Before I made any changes I'd have to understand it, and to be blunt, your code is far too messy to comprehend in a reasonable amount of time. I had to delete your vi from my computer--I was worried it would be a bad influence on my vis. If it were me, I'd probably implement a buffer and write to disk every couple minutes. If you keep the file open continuously then if LV crashes or your app gets into an undefined state you run the risk of losing all your data by not closing the file. You might need to implement a front buffer and a back buffer so you don't lose any data during the disk write operation.