LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

No path or empty path can exist?

@billko: This is exactly the VI I'm using, as I showed in the initial post, and I'm using it because it's supposed to check one thing, if the given path to a file or folder exists. But it can happen that you would give it an empty path and it would still return a TRUE and this is illogical.

 

Like I wrote, it may be that an empty path is considered as a valid path, but it's neither an existing file, nor an existing folder. 

0 Kudos
Message 11 of 15
(328 Views)

@MaSta wrote:

 

Like I wrote, it may be that an empty path is considered as a valid path, but it's neither an existing file, nor an existing folder. 


It is in the context of LabVIEW! If you like it or not. And if you find that strange you should check into the Windows shell (basically everything that Windows Explorer shows you). There you have virtual containers in abundance (your "This PC" is a super-super set of the LabVIEW empty path "container").

 

But at the time LabVIEW implemented its path logic you had only the Macintosh Desktop, which is the empty path equivalent of LabVIEW on the Mac, and then Windows File Manager, which was pretty much just a view of all the available disk drives. Both locations certainly exist on a computer, as you can not startup Windows without at least one valid drive being mounted. And on the Mac the Desktop always has been the root of all file systems, until they shoved a Posix filesystem underneath and mapped the entire Macintosh Desktop in very convoluted ways on top of it.

 

Adding the entire Windows Explorer magic later on would have been complete madness. Besides, this part of Windows was for quite some time considered proprietary information, until a judgment forced Microsoft to document it, because of antitrust concerns.

 

Basically you can decide to jump high and low and stamp with your feet about this "unlogical" convention. But it has been there in LabVIEW for the last 30 years and is not going away, no matter what. You are much better off making your own simple version of Check if File or Folder exists, with or without LLB concerns (you most likely want to avoid this special treatment of LLBs) and add the check for an empty path in there. It would have cost you much less time to do than to keep pounding on this issue.

 

It's something NI can't change now even if they wanted to (which they don't really want as it is not wrong but simply a convention that you may not like), as it would cause havoc in thousands of applications that were built in the last 30 years, and quite some of them are still running and getting used and sometimes updated and such a change for sure is not expected by most LabVIEW users who upgrade an application to a new LabVIEW version.

Rolf Kalbermatter
My Blog
Message 12 of 15
(320 Views)

@MaSta wrote:

Like I wrote, it may be that an empty path is considered as a valid path, but it's neither an existing file, nor an existing folder. 


But it is:

 

wiebeCARYA_0-1678452406216.png

wiebeCARYA_0-1678452565517.png

 

 

That's the point.

 

That the "" folder is 'virtual' doesn't make it non-existing.

0 Kudos
Message 13 of 15
(303 Views)

@rolfk wrote:

@Frozen wrote:

@billko wrote:

@MaSta wrote:

OK, but you would want to use the VI to find out if a file or folder exists, and no path given is not an existing folder, no matter how LV interpret an empty path. At least in this case the LED shouldn't light up. I will modify the VI now. 


I don't understand this statement.  Wouldn't you just use billko_0-1678284533503.png ?

 


I think what you want is something like this...

Adjust the last AND input as required.

 

Valide Folder.png


That's pretty much what I would do, except if you look in that Check if File or Folder exists, there already is a File/Directory Info inside and if you do not need the ability to detect files inside LLBs, you might just do this function once. It is not a huge performance killer to call it twice, but he LLB enumeration is and you do not want that function really get called in a tight loop as that for sure can make everything very slow.


Even though  "there already is a File/Directory Info inside"  "Check if File or Folder exists", the result is not exposed at the upper level. Hence the second call so the value can be used.

 

"but the LLB enumeration is [a huge performance killer]" Are you suggesting we re-write the function to exclude LLB enumeration? What did Aputman say about changing build-in LV functions?

But what if you *need* to check for files inside an LLB?... not that I ever use LLB any longer.

---------------------------------------------
Certified LabVIEW Developer (CLD)
There are two ways to tell somebody thanks: Kudos and Marked Solutions
0 Kudos
Message 14 of 15
(283 Views)

I did not suggest to change the build in function. I did suggest to build YOUR own version of it that uses the File/Directory Info function and correctly interprets the information of it, with the fact if it generates an error and the additional check of if the path is empty. Unless you need to detect VI files inside LLBs too, you can leave that part completely away.

 

Basically your suggestion to use AND the File/Directory Info, AND the Check If File or Directory Exists AND if the path is empty, does a lot of duplicate effort. If you already have that File/Directory Info in your VI anyhow, why not use its information directly in the same way as how it is done in the Check if File Or Directory Exists???

 

It's about the same effort to create that VI but seriously more performant.

Rolf Kalbermatter
My Blog
0 Kudos
Message 15 of 15
(277 Views)