The path problem again...

[MogaRaghu]

It is known that when stripping paths, you should add an additional level of stripping when running the VI as an exe. So I created a small Sub.VI called "CurPathToString " that  does this based in the Application Kind property and  started using it with a Main.VI.  Fine so far.

 The complication started when I moved this Sub.VI into a common library folder. 

Situation 1 : When running the  Main. VI as an exe , there was no problem with the path stripping as I got the path of Main.vi.

Situation 2 : But  when running the Main. VI in design mode, I was surprised to find that CurPathToString.VI returned the path of  the folder where it was located.

So the solution seems to be :

A. Don't create a sub.vi for the selective stripping of path.
B. If you do create , please  locate it in the same  directory  as  the Main.vi if you want it to work OK in design mode also.

While this discovery may not be on par with that of discovery of America, it still was  significant to me as iI learnt it the very hard way !!

Raghunathan

[altenbach]

Can you also attach your "CurPathToString.vi"? What do you do in there? Do you use e.g. "Current VI path" or do you use the "call chain" get the path of the calling VI or the toplevel VI?

Message Edited by altenbach on 02-10-2007 07:31 PM

[altenbach]

OK I saw your diagram comment that the subVI uses "current path". That's not what you want, because it will return wherever the subVI is located.

Here's an alternative:

Get the last element of the call chain, which is the toplevel VI and obtain it's path via a reference call. Try it.

This code fragment should go inside the subVI . Don't forget to also include your extra strip step depending on the environment as before.

Message Edited by altenbach on 02-10-2007 07:47 PM

[MogaRaghu]

Altenbach,

Thanks. The idea given by you solved the problem. That way LV is a treasure chest that has so many functions that it is impossible to find out the use of all of them by your self like the Call chain function which you had iused.

I am enclosing the modified CurPathToString.vi for such of those who can use this functionality.

Raghunathan

[altenbach]

Yes, that's about what I had in mind. 🙂

One suggestions though. You should stay away from the "Path to string" tool and keep the indicator as path. Whenever you convert a path to a string, your string will depend on the current OS. If you have a plain path string, you might be tempted to later add a filename using string concatenation functions instead of "build path". If you every try this VI on a Mac where the filename structure is very different, the VI will probably no longer work as expected. If you exclusively use "build path" and "strip path", your code will be much more universal. Never manupulate paths as strings.

(On a sidenote in case you might be wondering, I did NOT give you that single rating star. There is nothing wrong with your question :))

Message Edited by altenbach on 02-11-2007 06:28 PM

[MogaRaghu]

Dear Altenbach,

Yes I have noted your  concerns on the conversion of paths to strings and will keep it in mind.

And on the Single star rating, I noticed it also. But then after posting in various technical forums for more than 8 years , I have now become immune to such off-beat things happening. 

All the same it was very comforting to note your kind remarks. And when Altenbach says so, the buck stops there !

Regards

Raghunathan

[10Degree]

altenbach and Raghunathan,

Thank you for this discussion.  I have been trying to work through the AppPath issue and this has been very helpful.

-cb