LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to open a configuration file with a relative path?

Solved!
Go to solution

I want to open a configuration file during the initialization of my application (first "state," u can say) and I am using "Open Config file.vi" and tried to pass the config file's path as "data\myconfig.ini" and the "File exists?" vi didn't give any error (simply, the output was "false") but the Open config File gave an error.

 

If I pass an absolute path "D:\xyz\xyz\myconfig.ini" it works fine. Isn't it allowed to use "relative path" as I remember using it before for other tasks?

 

I actually prefer to have this file in the "data" folder that my application's setup will create in the destination directory while installing the application, because it will be easy when I want to ask the user to open and edit it. Or, I would just put it in "C:\" which exists on all the windows computers, but then it would be too much open.

 

Thanks ahead!

Vaibhav
0 Kudos
Message 1 of 22
(6,981 Views)
Solution
Accepted by topic author Vaibhav
hope this helps:
Harold Timmis
htimmis@fit.edu
Orlando,Fl
*Kudos always welcome:)
Message 2 of 22
(6,980 Views)

Harold is right. Be sure to go through the following KB:

Why Does My Executable Not Work When Using the Current VI's Path Constant?

Adnan Zafar
Certified LabVIEW Architect
Coleman Technologies
Message 3 of 22
(6,968 Views)

Relative paths have sometimes a meaning for command line tools (where a relative path gets appended to the current path, which usually is the executables directory).

 

But for Windows GUI applications that makes not much sense. Windows also maintains a per process current path, but that path gets updated by several Windows APIs, one of them being the File Dialog. So whatever your user has last selected in any file dialog inside your application will from then on be the applciations current path. It should be clear that with such a braindamaged current path implementation it has basically no useful meaning, and LabVIEW consequently does not do path expansion, where relative paths are expanded by prepending them with the applications current path.

Also LabVIEW uses mostly the Windows 32 Bit API, which does provide the current path implementation but does almost not use it in any of its file operations. The use of that feature is mostly reserved for the Windows shell API, which is a higher level API that can as best be described as a collection of various APIs that have been thrown together by whatever some MS developer felt at the moment. You can not by any means call it a designed API at all, and LabVIEW makes almost no use of it, as it needs lower level access, to make its operation similar in its working across all the platforms, LabVIEW can run on.

 

So while you can work with relative paths inside your application (and actually should as much as possible to make your application not depend on a particular location) you should make that path absolute whenever you pass it to a function that actually accesses a file somewhere.

 

Rolf Kalbermatter

Message Edited by rolfk on 09-08-2009 11:31 PM
Rolf Kalbermatter
My Blog
Message 4 of 22
(6,946 Views)

Thanks Harold for the quick response and Adnan for the KB link.

 

But my program still gives an error, this time dofferent code though.

 

In the attached file, I have quickly put the relevant components together and can you please tell me what is wrong?

I didn't use Strip Path vi because I don't need the config file's name back. (or do i need??)

 

Also from you responses it seems to me that the file path should always be absolute (if not hard coded, obtain thru references, but always pass absolute) right?

The running VI simply cannot assume the"current" path, am I right?

 

 

 

Thanks ahead!

Vaibhav
0 Kudos
Message 5 of 22
(6,943 Views)

Rolf,

I see you have already answered my questions about LabVIEW requiring the absolute path. I thought it accepts relative path because in VI Server we give relative path also, as well as it even accepts strings in some functions by polymorphism. But I guess in VI server it accepts since it's a matter of development time and while compiling it would include those files.

 

Yes, I always prefer the relative path and I see that LabVIEW also "likes" it but "needs" absolute. 😉

 

Message Edited by Vaibhav on 09-08-2009 10:45 PM
Vaibhav
0 Kudos
Message 6 of 22
(6,940 Views)

Oops.

 

Sorry, I just misplaced the components.

 

I have it working now. I used "Build path" in the beginning and then "Strip path" was "not needed" because I "assumed" that I need what their names suggest. And even I misunderstood what you showed Harold, because I thought why are you using that file name in the "Strip path" 😄 (because I thought they are used in the same order that they exist in the functions palette).

But after posting I started experimenting and saw that actually it gives "FilePath.vi" as the last component and that's the reason of this new error. Also, I had seen that in the Knowledge Base provided by Adnan, and realized that that last component must be removed. And that's when I needed Strip Path and then your using file name node made sense all of a sudden and I rechecked your (Harold's) diagram again and aah.. that it was.

 

Ok, I have attached the corrected file.

 

Thanks everyone for the help and explanations!

 

 

Vaibhav
0 Kudos
Message 7 of 22
(6,925 Views)

Your VI will not work. It has a race condition due to your unnecessary use of local variables. Why is ConfigFilePath a control?

 

It also does not take into account what has already been mentioned about correctly using the Current VI Path function. The KB article, again, in case you missed it the first time: Why Does My Executable Not Work When Using the Current VI's Path Constant?

Message Edited by smercurio_fc on 09-08-2009 05:10 PM
Message 8 of 22
(6,920 Views)

Hi Smercurio_fc

 

In case if you posted before seeing my last reply, the file works just fine.

I know it's not a good file, but it's working like mentioned here... 😄 (well, not really, just kidding. I know why my code runs. It's not by chance.)

 

 

I apologize for that ugly looking code, because as I mentioned in the message number 5 above -

 

I have quickly put the relevant components together 

 

The file was quickly formed by gathering pieces of codes from the main program file (since I'm still waiting to get my hands on LabVIEW 2009, though I heard it's arrived in the univ, so I couldn't put that snippet). So it contains those ConfigFilePath control/indicator/variables as in the original file.

 

Thanks for the comment and yes, I went through the KB article and that's where I had got better understanding of the situation. 🙂

 

 

Here is a better, cleaned colde. Someone may need it in future for a quick reference. I removed all the unnecessary items.

Vaibhav
0 Kudos
Message 9 of 22
(6,910 Views)
Ok, after reading the KB, perhaps a more robust version would be like this (see attachment).
Vaibhav
0 Kudos
Message 10 of 22
(6,893 Views)