Getting rid of the ini

[Cat]

Is there any way to tell LV not to create its own 'myapp.ini' when one of my executables is run?

Cat

[Antoine Chalons]

QUOTE (Cat @ Apr 14 2009, 02:47 PM)

Is there any way to tell LV not to create its own 'myapp.ini' when one of my executables is run?

Cat

Hi,

You don't always want to do that, this "myapp.ini" contains some of the settings for the application (tcp settings, wether or not myapp.exe is instanciable, and some more I don't know about)

To come back to your question, I don't know if it's possible, you can still place a function inside your exe to delete this file on start/stop.

Maybe there is a "clean" way to do it.. Anyone ?

Edit :

just found http://digital.ni.com/public.nsf/allkb/5467F7D7895835C186256FAF00600A21' target="_blank">this link on NI knowledge base, it gives a bit more information but no solutions

[Cat]

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

You don't always want to do that, this "myapp.ini" contains some of the settings for the application (tcp settings, wether or not myapp.exe is instanciable, and some more I don't know about)

To come back to your question, I don't know if it's possible, you can still place a function inside your exe to delete this file on start/stop.

Maybe there is a "clean" way to do it.. Anyone ?

Edit :

just found http://digital.ni.com/public.nsf/allkb/5467F7D7895835C186256FAF00600A21' target="_blank">this link on NI knowledge base, it gives a bit more information but no solutions

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.

[jpdrolet]

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
  

[Grampa_of_Oliva_n_Eden]

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

• ...
  
• Put the line CreateThisFile=FALSE in myapp.ini
  

Ben

[Cat]

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...!

[Mark Yedinak]

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.

[PJM_labview]

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

[Grampa_of_Oliva_n_Eden]

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

[Cat]

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

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).
  

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 ~~ ~~ !!

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

[jpdrolet]

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

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...!

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">

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.

[asbo]

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

The switch -pref \\DEV\NULL was a wink to linux ...

Since when has linux used UNC paths?

[jpdrolet]

QUOTE (asbo @ Apr 14 2009, 02:02 PM)

Since when has linux used UNC paths?

I didn't dare to put a unix path on a windows command line....

Ironically, using -pref /dev/null the application still creates the ini file.

[Cat]

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?!?

[PJM_labview]

QUOTE (neBulus @ Apr 14 2009, 10:45 AM)

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

Ben

Make sure the "wait until completion" flag is false.

http://lavag.org/old_files/monthly_04_2009/post-121-1239737022.png' target="_blank">

PJM

[bbystrek]

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).

[crelf]

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...

[Cat]

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!

[Cat]

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!

[Mark Yedinak]

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.

[Cat]

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!

[santi122]

Hi,

what about just hide the ini with the CMD vi and attrib myapp.ini +H ???

greetz chris

[Rolf Kalbermatter]

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

[LAVA 1.0 Content]

One additional warning, don't store settings in the LabVIEW temp folder, on my computer this one gets flushed every reboot.

Ton