LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Darren's Weekly Nugget 11/02/2010

There is a handy VI that ships with LabVIEW that will give you platform portability information about a file name:

 

isnamemultiplatform.png

 

Is Name Multiplatform.vi (located in vi.lib\utility\libraryn.llb) will take a filename input as a string, and return information about whether or not that filename is valid on all desktop platforms.  If there was a problem, it will generate an alternative filename, and will also return a string description indicating what was wrong with the filename.  And, if you only want to check if the filename is valid for the desktop operating system you are currently running, you can specify a value of FALSE for "name must work for all platforms".  This VI checks for the following problems:

 

  • Windows filenames with the following characters - \ : / * ? " < > |
  • MacOS filenames with the following character - :
  • Linux filenames with the following character - /
  • Windows filenames ending with the "." character
  • An empty string as a filename
  • The presence of multibyte characters

I have found this VI most useful when working on UIs where users can specify new filenames...I simply pass the user-specified filename through this VI to make sure it is legitimate before attempting any sort of File I/O.

Message 1 of 6
(5,914 Views)

Just got a chance to use this.  Very handy.  Because there is no documentation for the VI, I'll note here that the "original name had conflict" output only applies when "name must work for all platforms" is False.  Otherwise, it just matches the "crossplatform problem" output (which I understand is logical).

 

Also, at least in my libraryn.llb, the default for "name must work for all platforms (T)" is actually False.  If this is the case for you as well, maybe submit a CAR to rename the terminal to "... (F)" instead?

 

Thanks for the timely post.


Certified LabVIEW Architect
TestScript: Free Python/LabVIEW Connector

One global to rule them all,
One double-click to find them,
One interface to bring them all
and in the panel bind them.
Message 2 of 6
(5,850 Views)

 


@LabBEAN wrote:

 

Also, at least in my libraryn.llb, the default for "name must work for all platforms (T)" is actually False.  If this is the case for you as well, maybe submit a CAR to rename the terminal to "... (F)" instead?


 

Good catch, LabBEAN...sorry for the oversight.  I filed CAR# 256661 on this...the control will have the correct label in LabVIEW 2011.

 

-D

0 Kudos
Message 3 of 6
(5,837 Views)

 


@Darren wrote:

 

Good catch, LabBEAN...sorry for the oversight.  I filed CAR# 256661 on this...the control will have the correct label in LabVIEW 2011.


Of course, it would be better for everyone if the default value would appear there automatically, but that would be more likely to happen if more people voted for that.

 

 

P.S. Darren, this post brings up again the issue of using undocumented vi.lib VIs. What guarantee do we have that this VI will be forward compatible? I understand that once a VI is shipped it's not as likely to be changed, because there's also NI code using it, but can we rely on that?

 


___________________
Try to take over the world!
0 Kudos
Message 4 of 6
(5,786 Views)

Nice to know

 

Thanks Darren for the Nugget.

Ohiofudu

CLD

Certified LabVIEW Architect.
Ohiofudu Israel

0 Kudos
Message 5 of 6
(5,743 Views)

 


tst wrote:

 

P.S. Darren, this post brings up again the issue of using undocumented vi.lib VIs. What guarantee do we have that this VI will be forward compatible? I understand that once a VI is shipped it's not as likely to be changed, because there's also NI code using it, but can we rely on that?

 


 

We discussed the issue of non-palette VI changes in this thread (culminating in my post here).  Our working policy in LabVIEW R&D is to not change the interface to shipping VIs.  This is made easier with new families of VIs, as we are placing those in .lvlibs and using public/private scope to indicate which VIs will not change.  As for existing families of VIs (like the libraryn VIs), we have committed to leaving those unchanged.  Please make sure a CAR is filed if you ever discover otherwise. 

 

And in the case of Is Name Multiplatform.vi, you're right...there are at least 12 places in the LabVIEW codebase that use it.  And that's why I love shipping (and publicizing) utility VIs in vi.lib...prior to my refactor of this VI in LabVIEW 2009, most of those 12 places were using their own copies of the same VI.  In my opinion, if there's something this universally useful, there should be one copy of it in one shared location that we all use.

Message 6 of 6
(5,667 Views)