Jump to content

Recommended Posts

QUOTE (Antoine Châlons @ Apr 14 2009, 09:29 AM)

That link is the only thing I'd found about it, too. Yes, there are sometimes good reasons to have the ini file around. I generally don't use them, tho, and they are cluttering up my EXE folder.

Thanks for the idea to delete the ini file from the exe. That should work if the ini is recreated on start of the exe, but probably not if it's recreated on exit. I'll take a look at it.

Link to comment

Indeed the file is created as application exits

I can only see some workarounds:

  • Change folder access properties to forbid creation of files
  • Start the application specifying the -pref switch to some inexistent location e.g. myapp.exe -pref \\DEV\NULL (requires a shortcut)
  • Put the line CreateThisFile=FALSE in myapp.ini ;)

Link to comment

QUOTE (jpdrolet @ Apr 14 2009, 12:26 PM)

Indeed the file is created as application exits

I can only see some workarounds:

  • Change folder access properties to forbid creation of files
  • Start the application specifying the -pref switch to some inexistent location e.g. myapp.exe -pref \\DEV\NULL (requires a shortcut)
  • Put the line CreateThisFile=FALSE in myapp.ini ;)

I'm working in the Windows world... is it possible to forbid *creation* of files in a folder?? I know I can make a folder read-only, but that's a different thing, and I need to be able to edit the couple ini's I do use in that folder.

As for your last suggestion, I agree with what Ben said...!

Link to comment

Personally I like having the ini files available. Nearly all of the application I write will use it to store configuration data for the application. It allows customization of the application without the need to rewrite things. Some applications even use multiple ini files. The myapp.ini file usually stores the allowmultipleinstances=true setting and a history list of previous configuration files. The user supplied configuration files contain information specific to a single UUT or test configuration they have saved. I absolutely detest using the registry for settings. Besides, an ini file is more portable across platforms.

Link to comment

Another possibility (convoluted but it should work):

Create a SubVI that does the following:

  • Create a batch file in windows temp folder (reuse the same name every time so you don't end up creating many batch files ) that will wait a bit (1-2s) before deleting your ini file.
  • Execute this batch file using system exe (non blocking).

Note: you should run this SubVI as the last operation you do before exiting your app.

PJM

Link to comment

QUOTE (PJM_labview @ Apr 14 2009, 01:34 PM)

Another possibility (convoluted but it should work):

Create a SubVI that does the following:

  • Create a batch file in windows temp folder (reuse the same name every time so you don't end up creating many batch files ) that will wait a bit (1-2s) before deleting your ini file.
  • Execute this batch file using system exe (non blocking).

Note: you should run this SubVI as the last operation you do before exiting your app.

PJM

Turn that idea inside out.

Sub-VI writes then invoke bat file that runs the app and the after the app is done the next line in the bat file deletes the ini.

On second thought will not work since LV will wait for the bat to complete...???

Ben

Link to comment

QUOTE (PJM_labview @ Apr 14 2009, 01:34 PM)

I like this! I haven't had a reason to use system exe (let alone write a batch file) in years.

QUOTE (neBulus @ Apr 14 2009, 01:45 PM)

Turn that idea inside out.

Sub-VI writes then invoke bat file that runs the app and the after the app is done the next line in the bat file deletes the ini.

Now *you're* making me all ~~ :wacko: ~~ !!

Okay, I get the idea. When I get a chance I'll play around with this a bit and see what works best.

Link to comment

QUOTE (Cat @ Apr 14 2009, 01:14 PM)

You can forbid creation of files in a folder by some or all users in the advanced Access Control Settings:

http://lavag.org/old_files/monthly_04_2009/post-447-1239730795.png' target="_blank">post-447-1239730795.png?width=400

However it is not very convenient if you use/modify some of the ini files.

The second option may be more useful. If the application users start the applications using shortcuts anyway, modify the command line to use a pref file from an inexistent location. The switch -pref \\DEV\NULL was a wink to linux but -pref nofile would also prevent the creation of the file because it is an unusable relative path; nofile is not a special keyword. Of course, the third option was a joke.

Link to comment

QUOTE (jpdrolet @ Apr 14 2009, 01:54 PM)

You can forbid creation of files in a folder by some or all users in the advanced Access Control Settings:

(attachment deleted)

However it is not very convenient if you use/modify some of the ini files.

The second option may be more useful. If the application users start the applications using shortcuts anyway, modify the command line to use a pref file from an inexistent location. The switch -pref \\DEV\NULL was a wink to linux but -pref nofile would also prevent the creation of the file because it is an unusable relative path; nofile is not a special keyword. Of course, the third option was a joke.

Ah-ha! I was looking all over for those permission settings when you first mentioned this. I finally just figured out that I can't access them anyway, since we have to run with simple file sharing enabled. But at least I now know I wasn't imagining things, and I used to be able to set permissions like that.

I got the non-windoze file reference. :) I'll give the -pref switch a try, since I do run the apps from shortcuts.

What? The 3rd option was a joke?!? :o

Link to comment

My thoughts for what their worth...

The default ini file that LabVIEW creates doesn't really cause any harm and it's a fundamental component of deployment and required in many instances. This is why the application builder interface includes a configuration pane for it. I've historically used it as a means of conveying blink rate, blink colors, font selections and postscript printing options. As it's size is so small, I don't really understand why it would be a bother. If you haven't used the file before, you might have a look at NI's knowledgebase as typically what you might do, in an advanced context, is to copy applicable entries out of your LabVIEW.ini file (in the main LabVIEW install directory).

Link to comment

QUOTE (Cat @ Apr 14 2009, 10:17 AM)

Yes, there are sometimes good reasons to have the ini file around. I generally don't use them, tho, and they are cluttering up my EXE folder.

Is it really cluttering up the folder? I mean, it's not often that users should be playing around in there, so I don't think it's existance is too compelling a reason to circumvent it. That said, if there are settings in there that you definately don't want your user screwing with, then that's a different story...

Link to comment

I understand ini files can be very useful. I do actually use them with a few of my tools. I always code an editor for them, because my users aren't usually up to hand-editing anything. And under some circumstances, I move the ini files to a different directory, because of other users who *think* they know how to edit them and decide to go mucking around when they're bored. So all of that adds up to me needing the ini files where I need them when I need them. Having LV write to those same files makes me a tad bit nervous. And having it create an ini when I've got the real one stashed away some place safe is needlessly (and perhaps dangerously) redundant.

For the record, the solution jpdrolet suggested to use the -pref switch seems to be working fine. It's definitely the easiest solution, tho the batch file idea would have been more technically interesting to implement. :)

Thanks for all the ideas!

Link to comment

I understand ini files can be very useful. I do actually use them with a few of my tools. I always code an editor for them, because my users aren't usually up to hand-editing anything. And under some circumstances, I move the ini files to a different directory, because of other users who *think* they know how to edit them and decide to go mucking around when they're bored. So all of that adds up to me needing the ini files where I need them when I need them. Having LV write to those same files makes me a tad bit nervous. And having it create an ini when I've got the real one stashed away some place safe is needlessly (and perhaps dangerously) redundant.

For the record, the solution jpdrolet suggested to use the -pref switch seems to be working fine. It's definitely the easiest solution, tho the batch file idea would have been more technically interesting to implement. :)

Thanks for all the ideas!

Link to comment

QUOTE (Cat @ Apr 15 2009, 02:28 PM)

I understand ini files can be very useful. I do actually use them with a few of my tools. I always code an editor for them, because my users aren't usually up to hand-editing anything. And under some circumstances, I move the ini files to a different directory, because of other users who *think* they know how to edit them and decide to go mucking around when they're bored. So all of that adds up to me needing the ini files where I need them when I need them. Having LV write to those same files makes me a tad bit nervous. And having it create an ini when I've got the real one stashed away some place safe is needlessly (and perhaps dangerously) redundant.

For the record, the solution jpdrolet suggested to use the -pref switch seems to be working fine. It's definitely the easiest solution, tho the batch file idea would have been more technically interesting to implement. :)

Thanks for all the ideas!

If you don't want your user's to edit the files and since you already provide them with a means to edit them have you considered storing them in an encrypted format? This way they could reside in the application directory, you could name it something like myapp.dat, and ensure that no one hand edits the file. You could couple this with the -pref option and you don't have to worry about maintaining a separate "hidden" directory somewhere. There is a decent version of the http://zone.ni.com/devzone/cda/epd/p/id/3473' target="_blank">blowfish encryption algorithm posted on NI's discussion forum.

Link to comment

QUOTE (Mark Yedinak @ Apr 15 2009, 03:44 PM)

If you don't want your user's to edit the files and since you already provide them with a means to edit them have you considered storing them in an encrypted format?

That's a really interesting idea. I'll take a look at it. Thanks!

Link to comment

QUOTE (Cat @ Apr 15 2009, 02:28 PM)

I understand ini files can be very useful. I do actually use them with a few of my tools. I always code an editor for them, because my users aren't usually up to hand-editing anything. And under some circumstances, I move the ini files to a different directory, because of other users who *think* they know how to edit them and decide to go mucking around when they're bored. So all of that adds up to me needing the ini files where I need them when I need them. Having LV write to those same files makes me a tad bit nervous. And having it create an ini when I've got the real one stashed away some place safe is needlessly (and perhaps dangerously) redundant.

For the record, the solution jpdrolet suggested to use the -pref switch seems to be working fine. It's definitely the easiest solution, tho the batch file idea would have been more technically interesting to implement. :)

Well, a LabVIEW exe itself actually never writes to its ini file, except when it is not there, in which case it creates an empty ini file.

The way I do this is by always adding an ini file into the build. This ini file contains a few default settings such as to suppress the secondary task bar button for the hidden root window, specific font settings for the different LabVIEW default fonts and possibly VI server settings.

All the actual configuration settings for my applications are not stored in that ini file but in a seperate ini file either located under Documents and Settings\All Users\Application Data\<app name> for settings that are used for any user on a particular machine (hardware configuration) and under Documents and Settings\<user name>\Local Settings\Application Data\<app name> for settings that are user specific.

Works fine even in environments fairly strictly locked down by IT departements. And for what I know it should even work for Vista, which I luckily had not to deal with yet.

Rolf Kalbermatter

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.