02-05-2009 05:39 PM - edited 02-05-2009 05:39 PM
I ran across this tonight, and it seems a little weird to me. I have a path that shows as "<Not A Path>" in probes and in the control/indicator, but the NaN/Path/Refnum? function returns false. I suspect it has something to do with how this path was created (I used path to string, some string operations, and then string to path on it), but I would still expect the comparison to return True. Any thoughts or insights? I used Flatten to String to look at the path, and it is clearly different from the Not A Path Constant. I can use File/Directory Info instead, and then check for an error, but this is annoying. The vi is saved in LV8.6.
Chris
02-05-2009 09:52 PM
I have seen similar things before. You can type "<Not A Path>" into a path control, but it's not really <Not A Path>. If I remember right, I think I have seen this as far back as V7. I would call it a bug.
Mike...
02-05-2009 11:05 PM
See that tiny little path symbol (the two offset squares connected by a line) on the left side of the path control? Operate-click on that...you can set it to "Not A Path". This is how you specify that the value in a Path Control is Not a Path. Just typing a string of "<Not A Path>" into the control won't cut it.
-D
P.S. - Same trick works on Path Constants.
P.P.S. - Is this worth a nugget?
02-06-2009 01:06 AM
Yeah.
if you wire the "Path Type" Function to the path you'll see that the string "<Not A Path>" is type=1 (relative path), the real "<Not A Path>" is type = 2 (well, "Not A Path")
02-06-2009 02:20 AM
Chrisger wrote:
"<Not A Path>" is type=1 (relative path), the real "<Not A Path>" is type = 2 (well, "Not A Path")
You can even see this in the both string indicators.
"<Not a Path>" is really invalid on Windows and as far as I know on Linux. So the primitive "String to Path" should create an invalid path (type=2).
Normally you use the system dialogs to create a file but in other use cases you do that indirectly. Think of a test person how enters an alpha numerical article number and you create a folder somewhere based on the article number. A short check is "String to Path" and check for a relative path.
02-06-2009 11:07 AM
Thanks guys. I think the grand solution is to avoid the use of Path to String and String to Path, or to use a little more robust error checking on paths when those functions are used. It seems that an invalid path will always be converted to a relative path using those functions. Would it be unreasonable for the String to Path function to just do a search of the input string for "<Not a Path>" when converting to determine the path type (I guess that could be a valid relative path on some platforms..)? Thanks Darren, I never knew that you could change the path type by using the operate tool on the path control. I can't really think what I'd use that for except maybe troubleshooting, but it is a neat little trick.
I ended up solving my problem by just checking the base path before it was converted to a string instead of after it was converted back to a path. Any path that orginates from a <Not a Path> base path will end up being <Not a Path>. This won't catch the situation where a valid base path is invalidated by my string operations, but that is not an issue in this application.
Chris
02-06-2009 11:42 AM
Yes, I think it's a good idea to avoid the string/path conversions and stick with the path data type when possible. You run the risk of writing platform-dependent code when you start dealing with paths as strings.
If you still need some help coming up with the best way to work with paths, post some more details to the thread and we'll help.
-D
02-06-2009 01:42 PM
02-06-2009 01:58 PM - edited 02-06-2009 01:58 PM
Darren wrote:
P.P.S. - Is this worth a nugget?
Here's an example of the nugget:
02-06-2009 01:59 PM
JoeLabView wrote:
<it's worth a nugget>
Duly noted. It's in the hopper now.
-D