application - current vi path different - config file

[stephan from dublin]

If I want to use config files (ini files) with an application, to store settings between runs of the application,

I would like to name the conifg file the same as the application, just with a different ending:

application.ext with config file application.ini

For this, I am using the 'current vi's path' and work from there.

I realised that the 'current vi's path' of the application is different from the one of the vi itself, even with the original vi being in the same directory as the application.

The application returns the vi in a path that includes the applicatinon as a directory.

e.g.

\programs\application.exe

gives path

\programs\application.exe\original.vi

Thus, it seems that I need a different way of stripping/appending the path for the original vi and for the application, when creating the path for the configuration file.

Is there a way around it?

Is the only way to program a 'smart' stripping tool, that checks if the current path includes an xxx.exe part, and then creates the path for the config file accordingly? (This is what I will do, if there is no simpler solution)

Thanks for any help,

Stephan

[becktho]

Hi Stephan

You don't need a 'smart' stripping tool. Just check in your main vi if it is run by the LV runtime environment or the LV dev. system. Depending on this, either strip the path once or strip it twice.

Thomas

Message Edited by becktho on 12-21-2005 03:12 PM

[Aitortxo]

Hi Stephan:

You got the algorithm to solve your problem. Why not make a SubVI and save it in your own SubVI Library?

If you start with it, you can add another case so that it works when the VI that calls it is in a LLB library file 😉

I did my version for this same case. But there may be there an easy way to do it. I'll wait for replies.

[tst]

Becktho, the problem with stripping once or twice is if you have more nesting (like if you originally had the VI in a llb).

I took OpenG's Get VIs Directory and modified it to get just the file name, not the directory. The rest from there was easy.

[becktho]

That's not a problem. You could use the property App.Dir, which represents the root-dir of the application. So I just check if the app runs in the rte, then I use App.Dir, otherwise I strip the path of the main vi (which is in a llb, so I strip it twice).

[tst]

2 Problems here:

1. You need the file name, not the directory name, so this entire debate is pointless anyway, especially, when you already have an OpenG VI which does this for you.

2. You have to know your VI is inside an LLB in order to strip twice, so you have to add another condition, which will make it more complex.

[becktho]

2 answers back:

1. If I have several ini-files in an app, I need a root path to build the correct paths to the files. During designtime I know the names of the necessary files - LV does not. So how shall I be able to make a link to the correct files? I'm pretty sure you won't tell me, that the OpenG VI will give me all the necessary filenames.

2. Why shall I not know that the vi is in a llb if I develop the vi? Why shall I place code in a VI, which is kind of fixed? There's a main-vi in a main.llb. Nobody there, who changes this structure.

[tst]

Obviously, if you have several files, this is a different matter. However, since Stephan wanted the INI file to be the same name as the EXE\VI, there is only one name in this case, which means we need to get the name of that file.

While you can know the VI is an llb, the point of OpenG is utility VIs - In this case, a VI which will return the directory whether the VI is in a directory, an EXE, a LLB or any other option we can (or can't) think of. ALL I did was to change the VI to avoid the last step so we get the file path instead of the directory path. It's useful as a utility if you have a single INI file. Since an EXE file creates such a file anyway, this should apply to most users.