your code has some issues:
your code has some issues:
- It might not work for LabVIEW 2009 code where VIs can be in subpaths of the executable (myexe.exe\source\vi.vi)
- It will create a myconfig.ini
- You don't need to open the application to get it's type
Thanks a lot Ton for your suggestions,
I would surely like to mark your reply as a "Solution no.2" (once again a situation supporting the discussion).
I have installed OpenG libraries and VIPM but didn't yet use any of them so far. And this "Current VIs parent directory" is exactly what I needed, it takes care of things more than I had.
So now the code would be just
instead of the following complete thing
Because actually, the OpenG function does this operation, but with a better algorithm.
And about your 3 points -
1. I still do not have LabVIEW 2009, so didn't know. So thanks for pointing this one out, as it would have created unexpected problems after upgradation.
2. Yes, I do want to create the config file, when the application runs for the first time, and also, whenever it doesn't find that config file in future (someone got mischevious to delete/corrupt that file.
3. You mean like this... ...?
Kudos for everything,
and Thanks a ton to all!
Here is a screen shot of a vi I made to build a base path for all my data and config files.
Thanks for your contribution.
But that App.Dir would give path of the LabVIEW's application directory path. So this will store the data and configuration files in your development environment path (not necessary for the environment, but the path refers to the location that you will have access to when you're with the development work). And in the run time, it stores in the application (.exe) path.
That's similar to the one I posted in the 10th comment above.
And Ton listed the problems with that approach, as well as the more robust solution.
I would suggest you also consider those points (with screenshots in my response above), to make your code more robust. If you want to maintain the Application directory variable's value, then it's fine, but still there is a "warning" against upgradation into LabVIEW 2009.
To get the Application's [EXE] Path, you dont need to use the Strip Path function twice like above.
Just use the Application Directory property available next (down) to the Application Kind property in the same node.
Only for the Devp System case, you need to use the Strip Path function or in some other way (like keeping a global variable in the name of Current Application Path or Current Working Directory that already holds your Project Directory path from the beginning of your top-level VI).
Thanks for the message.
That method, I just used briefly after I got tips, and in the response I have mentined that screenshot as "old method" ("instead of this....")
Now, I am using OpenG's Current VI's Parent Directory function. And that function does similar process internally (not two times stripping, but from application).
I am getting contradictory responses which confuse me a bit.
Do you think using the App. Dir will work in LabVIEW 2009 without problem (like Ton said above)? In that case I would need two times stripping. So just using a function that won't require changes in the code after I upgrade to new system (if I put my source in that source directory someday and "forget" to make changes in the code).
I am opening the configuration file in the beginning of my application, and I just read the configuration parameters, and that's it. So after I "find" the path of the application (my application, not NI's LabVIEW), I just store it in a local variable and in the next case of execution, I use that path and that's it. I do not need it further more (AFAIK, I won't need that in future also).
The nice thing about the OpenG VI is that it doesn't check wheter you are in an application, it just checks which part of the current VI path returns a valid folder path.
For LabVIEW 2009 the number of ' stripping' can be numerous.
yes, I am also implementing the same after your suggestion, because it takes care of the directory structure, internally.
App.Dir property has no problem in my case. It can also be considered as a solution. But I don't know about its behaviour in LV2009.
I think it should work in the same way in LV 2009 also, like it was earlier.
I m not sure of what Ton means exactly...
In LabVIEW 2009, the internal file structure of an Exe has changed and there can be a path inside the executable: