Darren's Weekly Nugget 11/02/2010

[Darren]

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

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.

[LabBEAN]

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.

[Darren]

---

@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

[tst]

---

@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?

[ohiofudu israel]

Nice to know

Thanks Darren for the Nugget.

Ohiofudu

CLD

[Darren]

---

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.