LabVIEW Idea Exchange

There are already several Ideas on the exchange regarding custom error-code files. A subset are listed below:

Project error code files (request to locate error file near lvproj file, or via Project properties)

Error txt file (allow specifying a path when calling General/Simple Error Handler, store the custom file somewhere not in <National Instruments>/{Shared,<lv-version>}/...)

Make custom error code files part of a project (allow project-level error codes, not stored in user.lib)

Error ring without file (request for an error-ring typedef that could be stored in the project's source code collection)

My suggestion here is most like the last - I'd like to suggest a file type like a .ctl (or perhaps via typedef, if technically better/more implementable) that can be added to a project, library or class and contains a list of errors.

Ideally, these errors should be only possible to throw from inside the library, but must of course be visible from outside of the library.

Implementing these at the project level restricts the possibility of use with PPLs, reusable libraries, etc, because the project file is a dev-only construct (as far as I understand), unlike classes and libraries (which are part of what you distribute in whatever form you choose).

The ability to store these files in a library or class also allows the possibility of scoping the error code, such that the handler can more easily identify the source of the error.

LabVIEW already categorizes it's errors into broad sections (LabVIEW, MAX, NI Platform Services) etc and so perhaps these could be used as the scope of the existing, built-in error codes, although I'm not sure if this would require significant work or not... I suspect many things seem easier when you're not the person who will implement the changes!

So this isn't a huge deal, but it would be nice if we could put an array of classes into To More Specific Class to convert all of them to the more specific class. There are handfuls of functions that work well on both arrays and single elements (the Math functions, Close Reference, etc).

Error Out would need to become an array as well. I can't think of anything at the moment that this might break, or any poor patterns it might enable, it would just save a For loop here and there. I made a quick example vim just to illustrate, but it'd be nice if it was part of LabVIEW core.

Traditionally LabVIEW has treated Strings and Unsigned Byte Arrays as being the same. This is nowadays a little unfortunate as all UI systems use some kind of encoding so Strings are not generally interchangeable with Byte Arrays anymore.

In trying to stay for binary data as much as possible with Byte Arrays instead of Strings, since that would be the sensible thing to do, the Unflatten from String (which should rather be called Unflatten from Stream) puts a totally unnecessary wrench into this.

I always had hoped that LabVIEW would change the default binary data stream format to a Byte Array at some point but this while it would be possible, is a fairly pervasive change that would require many backwards compatibility decisions that I unfortunately don't see NI going to spend time on anymore. This change however would be a very small change that has zero backwards compatibility concerns and almost no work to add to the existing LabVIEW software.

This same change has been for instance made to the TCP Write node some versions back already and could be also applied to the VISA Write!