Why are special chars used in Labview filenames supplied by NI? By special chars, I mean ampersands, questions marks, Plus signs, slashes etc. Thats just bad practice in an otherwise good product.

[RM2]

I would like to request that National not use such filenames anymore. Spaces should also be avoided. Just use a format such as MyFileNameWillSuffice.vi.

[asimpleman]

"flo" wrote in message
news:50650000000800000072670000-1031838699000@exchange.ni.com...
> Why are special chars used in Labview filenames supplied by NI? By
> special chars, I mean ampersands, questions marks, Plus signs, slashes
> etc. Thats just bad practice in an otherwise good product.

Why is it bad practice?

>
> I would like to request that National not use such filenames anymore.
> Spaces should also be avoided. Just use a format such as
> MyFileNameWillSuffice.vi.

Now I think you are putting us on. You are kidding, right?

[Greg_McKaskle2]

> Why are special chars used in Labview filenames supplied by NI? By
> special chars, I mean ampersands, questions marks, Plus signs, slashes
> etc. Thats just bad practice in an otherwise good product.
>
> I would like to request that National not use such filenames anymore.
> Spaces should also be avoided. Just use a format such as
> MyFileNameWillSuffice.vi.

If you have specific problems with a VI's name, report it to technical
support. The internal guidelines do advise against the use of certain
characters, and advise that the length be kept under 31 characters.
Sometimes these guidelines are ignored, but they are less strict than
what you would like.

Because the modern OSes and file systems have no problems with filenames
containing spaces and a n
umber of other special characters, we do not
try to keep people from using them.

Greg McKaskle

[Ben]

Hi flo,

I will attempt to address the "why" part of your question.

Those "special characters" are artifact left over as part of LV's history. The special characters where not "special" on the MAC where LV started. Somewhere along the line, LV was ported to Windows where 8 character file names where in place. TO handle this complication, LV used the .LLB scheme where LV had a file system that would operate within either OS.

Otherwise;
I share your view of the special characters. Coming from and old DOS environment, I am quite sensitive to spaces in file specifications.

Summary;
The special characters are only special in a Windows world.

Ben

[RM2]

Actually I was quite serious. This is the first "graphical" programming I have done. Prior to this I used C/C++, Java, VB and Perl. I carry that naming style from those languages. Questions marks used to be (maybe still are) used as wild card characters. I have run into problems on a Solaris machine when there were spaces in the file names. Plus signs slashes (/ or \) are a definite nono. So should !@#$%^&*()|.

All those other languages have defined coding standards which serve to make code more readable and easier to maintain.

[Greg_McKaskle2]

....
> Perl. I carry that naming style from those languages. Questions marks
> used to be (maybe still are) used as wild card characters. I have run
> into problems on a Solaris machine when there were spaces in the file
> names. Plus signs slashes (/ or \) are a definite nono. So should
> !@#$%^&*()|.
>
> All those other languages have defined coding standards which serve to
> make code more readable and easier to maintain.

The LabVIEW coding guidelines warn against using some of those symbols,
but it isn't nearly as limiting as you might want. The reason for this
is that you rarely use VI names on a command line. If you are using
them, then simply "" the path. Feel free to further limit the
characters used in naming your own VIs, but
the names of VIs in vi.lib
and toolkits have already been determined and have in many cases been in
use for five to ten years. They do not cause problems.

Just for the record, LV is also localized into several languages
including Japanese and many of those customers use their native language
and native characters. Again, this doesn't cause problems.

Greg McKaskle