Not a Path and path to string to path conversion

[eaolson]

Wiring a Not a Path constant to Path to String and wiring that to String to Path gives a valid path containing the text "<Not a Path>". I found that very unexpected. Is this intentional? If so, is there any string that can be converted to a path data type that is an actual Not a Path? It seems to happen in 7.1, 8.0, and 8.20.

Message Edited by eaolson on 05-17-2007 01:10 PM

[tbob]

Very interesting.  I might add that in the example shown by eaolson, the intermediate string value is "<Not A Path>", same as shown in the path indicator.  This will cause problems.  I would guess that a workaround would be to check for Not A Path before calling the Path To String Function.  In my opinion, the output of Path To String should be an empty string when the input is Not A Path.  Maybe NI can explain why this action was chosen.

[RichBurb]

This problem pertains to the String to Path vi as well. According to the description in the LabVIEW help, it should do the following:

path is the platform-independent representation of the path described by string. If string is not a valid path descriptor on the current platform, the function sets path to <Not a Path>. path is of the same data type structure as string.

However, any string such as "!@#$// (including the quotation mark!) will be returned DUPLICATED but cast as a path rather than returning <Not a Path> as described. This will appear to be a valid path when tested by the "Not A Number/Path/Refnum?" object as noted in the original post in this thread.

[eaolson]

---

@tbob wrote:

In my opinion, the output of Path To String should be an empty string when the input is Not A Path.  Maybe NI can explain why this action was chosen.

---

But even an empty string is a valid path, once converted. On the PC, it's a virtual directory containing all the drive letters.

[JB]

The last two messages of this discussion may share some light...

Message Edité par JB le 05-21-2007 04:55 PM

Message Edité par JB le 05-21-2007 04:56 PM

[Caseyw]

I agree that this behavior is confusing. The important thing to note here is that the Not a Number/PathRefnum function does not perform any syntax checking on the path wired in; instead it simply checks for a "Not a Path" flag, and outputs a boolean T or F based on that condition.

Converting a path to string and then back seems to lose this "Not a Path" information. To address this, I am going to contact our developers and suggest, at a minimum, that the documentation for the Not a Path/Number/Refnum be improved to better explain how exactly the function works. In addition, I would encourage you to submit a product suggestion at ni.com/contact. Your suggestion will go directly to the responsible developer, and we take every one of your suggestions very seriously.

What exactly are you trying to accomplish in your application by converting a path to string and then back again? I would be glad to work with you further to find an alternate method. I am sure that we can work together to get your program up and running.

I hope this helps!

Casey Weltzin

Applications Engineer

National Instruments

[eaolson]

---

@Caseyw wrote:

In addition, I would encourage you to submit a product suggestion at ni.com/contact. Your suggestion will go directly to the responsible developer, and we take every one of your suggestions very seriously.

---

Done.

---

What exactly are you trying to accomplish in your application by converting a path to string and then back again? I would be glad to work with you further to find an alternate method. I am sure that we can work together to get your program up and running.

---

I was trying to do some string maniuplation on a path name (i.e. change c:\foo.txt to c:\foo_01.txt). My first attempt was to convert the entire path to a string, and work on the full string, where this issue came up. It was easy to get around it with a combination of Strip Path and Build Path. If the path input to Build Path is NAP, it returns NAP, regardless of the string input.

[Caseyw]

I am glad that you were able to find a workaround! I have submitted this feedback to our developers, and hopefully we will see this behavior changed in a future version of LabVIEW. Please let me know if you need any additional help with your application!

Casey Weltzin

Applications Engineer

National Instruments