Project context aware custom errors

[sthomas]

The error ring is a handy tool I've just learned about.  It would be fantastic to be able to create an error ring for a project that can be type defined to easily distribute with applications.  This way all custom error codes for a project may be easily stored with all the project files without having to worry about including a file from the user.lib.  Other ring controls/constants/indicators can be type defined, why can't the error ring?

[JÞB]

You can create you own custom error file (See the LabVIEW Help)  Any build spec will also allow you to add your custom error file to the build. 

I essence, This is a done - done feature! 2012 and later

[sthomas]

Hi Jeff, I agree that you can create the custom error file, however it is sometimes a pain to include the error file with built applications or distributing to other people using the same code. Furthermore, every time a change is made to the custom error file, LabVIEW must be restarted to recognize the new item. My idea is for a control that can be included in a project like any other type-defined control and is included simply in any distribution and will appear project wide consistently like other type-defs. For project A I have my set of error codes in type-def A. Project B has type-def B with its own unique custom errors. Just my idea.

[JÞB]

So let me restate-- What you want is project context custom errors?

If so that COULD be interesting.   Tell me a story about how you would use them and and how they would improve how you use LabVIEW.   You have me "on-the-Fence."  but I don't want to put the story in my words----It is your idea! 

[sthomas]

Yes, that's what I am going for. I am designing and creating automated test systems, much like yourself. I would love to be able to create an error ring type-def stored locally with all my related project files. As I write my application and discover new errors for which a custom error in the error ring would be useful, I simply place my project type-defined error ring on the block diagram, edit the items, and apply changes. Now I can use that custom error anywhere in my project easily just like any other type-defined enum. Furthermore, I can see the custom error codes easily to be able to see what I have already used without the overhead of the custom error file technique. The existing error ring simply allows me to define a custom error code local to a single error ring constant in a single VI and I am unable to reuse that same custom error ring elsewhere without physically copying the error ring I previously created.

[JÞB]

OK Kudos! 

Spoiler

Watch me pull a rabbit out of my hat Rocky!

Spoiler

Jordan,

Spoiler

  Please edit the subject line of this idea to  "Project context aware custom errors"

pending the OP's approval of course!

[JordanG]

sthomas,

I've edited the title of this idea to be "Project context aware custom errors". Please let me know if you have any issues with this.

Jordan

Community Manager

[sthomas]

This is fine for me. Thanks.

[kegghead]

Yes. The custom error codes are an awful solution since they're outside of source code control. Let us define errors with the project, or frankly any mechanism that allow them to ride along with the source code rather than some file that needs to be dropped in a special LabVIEW folder.

[AristosQueue (NI)]

> The custom error codes are an awful solution

> since they're outside of source code control.

How are they outside of SCC? They're independent files. You should be able to check them in and out of SCC just fine, and they are diffable/mergeable.  Making them part of the project file creates issues for deployment and for component reuse in other projects.

Having codes that only load for a given project is a useful suggestion (i.e. if the project lists a given error code text file, then those error code text files get loaded for that project's application instances only). But saving the error codes inside the project would be going too far.

I added my Kudos to the idea overall.

[JÞB]

Stephen,  I believe we are on exactly the same page.  Hence, the sugested re-title to "Context Aware"

The trouble I foresaw was conflicting error codes from multiple third party providers.  Error -5001 from MDT may be reserved for interface XYZ and MDT has a way to control and distribute error codes (A Readme under source control for cusotm errors)

But, that's all they have at the moment.... developers must reserve blocks of error codes for their context so that other developers will reserve a different block of codes.  conflicts need escallation and libraries contracted out to suppliers need error code blocks pre-assigned (Not very easy!) 

Context awareness would be highly desirable,  at least for objects that are aware of the context they are owned by!  SO Error definitions for lvlib and plvlib but not lvproj.  The lvproj that needs a custom error, IMHO, should call the correct library member through the library that contains the error definition.

Are we on the same page?