Confused about the Error Ring customization options

[X.]

The Error Ring:

is great to constructing custom error codes.

Documentation here: https://www.ni.com/docs/en-US/bundle/labview-api-ref/page/vi-lib/errorring/error-ring-xnode.html

There are two ways to use it:

- define a Custom Error Code at Edit time

- define a new set of codes in a user-created XXX-errors.txt file using the Tools>>Advanced>>Edit Error Codes...

There appears to be a major difference between the two approaches.

In the first case, you can include string formatting codes and this results in the error code to automagically add input terminals to itself:

The problem is that this is only valid within the current project. Move to another project and there is no error 5003 to be found under the Custom Error Code section.

Documentation here: https://www.ni.com/docs/en-US/bundle/labview/page/defining-a-custom-error-code-from-the-error-ring.h...

In the second case, you DO NOT have the option to include string formatting code (you can put some but nothing is going to happen):

However, since these definitions are saved in a specific XXX-errors.txt (in user.lib/errors), they can be used in any projects.

Documentation here: https://www.ni.com/docs/en-US/bundle/labview-api-ref/page/project/err-edit.html

Why the difference and in particular, why is this cool formatting feature not available in the second approach?

Finally, I don't believe the user.lib/errors folder is the most natural location for such a generic resource. It probably should be in a user folder like the shortcut plugins are so that it can be shared between versions.

[billko]

---

@X. wrote:

The Error Ring:

is great to constructing custom error codes.

Documentation here: https://www.ni.com/docs/en-US/bundle/labview-api-ref/page/vi-lib/errorring/error-ring-xnode.html

There are two ways to use it:

- define a Custom Error Code at Edit time

- define a new set of codes in a user-created XXX-errors.txt file using the Tools>>Advanced>>Edit Error Codes...

There appears to be a major difference between the two approaches.

In the first case, you can include string formatting codes and this results in the error code to automagically add input terminals to itself:

The problem is that this is only valid within the current project. Move to another project and there is no error 5003 to be found under the Custom Error Code section.

Documentation here: https://www.ni.com/docs/en-US/bundle/labview/page/defining-a-custom-error-code-from-the-error-ring.h...

In the second case, you DO NOT have the option to include string formatting code (you can put some but nothing is going to happen):

However, since these definitions are saved in a specific XXX-errors.txt (in user.lib/errors), they can be used in any projects.

Documentation here: https://www.ni.com/docs/en-US/bundle/labview-api-ref/page/project/err-edit.html

Why the difference and in particular, why is this cool formatting feature not available in the second approach?

Finally, I don't believe the user.lib/errors folder is the most natural location for such a generic resource. It probably should be in a user folder like the shortcut plugins are so that it can be shared between versions.

---

The -errors.txt usage becomes even more mind-numbing when you try to use it with TestStand.  Then they have to go in the C:\Program Files (x86)\National Instruments\Shared\Errors\English folder if you want them to be seen by TestStand!  Of course, then there's no easy way to include it with a LabVIEW build.

[X.]

What else do I need to know about errors.txt files and builds?

Does the file need to be explicitely part of the project?

Does it need to be copied somewhere in the destination folder?

[billko]

---

@X. wrote:

What else do I need to know about errors.txt files and builds?

Does the file need to be explicitely part of the project?

Does it need to be copied somewhere in the destination folder?

---

I guess I over-dramatized that part.  You include it explicitly and create a new destination directory in your build.

[X.]

Now you're freaking me out!

First, where is that documented?

Second, what happens if the file is not included (or corrupted, or deleted)?

I found this CAR about error rings, but I don't think I need to worry about this just now: https://www.ni.com/en/support/documentation/bugs/14/labview-2014-and-2014-sp1-known-issues.html#5226... 

[X.]

OK, in fact, according to the docs, I should not worry about the errors.txt file, as it will be copied, provided I check the right checkbox in the Advanced tab in the build specification:

https://www.ni.com/docs/en-US/bundle/labview-api-ref/page/resource/framework/providers/builds/appbui...

Copy error code files—Adds copies of XML-based LabVIEW error code text files from the project\errors and user.lib\errors directories to the run-time engine. 

Note You must manually create an errors folder in the labview\user.lib directory to organize your error code files.

I am just hoping I am reading this right...

[billko]

I guess the info is pretty scattered across LabVIEW and testStand docs, but the one that I had most trouble with was this one:

https://www.ni.com/docs/en-US/bundle/labview/page/distributing-custom-error-codes-in-text-files.html

That talks about adding error codes to executables.  Since the application I was working on was intended primarily to be used in TestStand but was also meant to be built as a standalone executable I had to have my error codes reside in the errors\english folder, but I used a pre-build VI to pull them into the user.lib\errors folder, but if I had found this document earlier, I would've just included it in my build as I had mentioned above.

[X.]

Thanks for that link.

So basically, if I understand correctly, the thing can become an horrible mess, since YOU can create a custom error file called custom-errors.txt and *I* can create a different one named the same way. If we both distribute our app to the same client, the second install will override the first, since the installer "installs [the files] in the Shared\LabVIEW Run-Time\x.x\errors directory, where x.x is the version of LabVIEW".

I can break your app and reciprocally. Well-done NI...

[billko]

---

@X. wrote:

Thanks for that link.

So basically, if I understand correctly, the thing can become an horrible mess, since YOU can create a custom error file called custom-errors.txt and *I* can create a different one named the same way. If we both distribute our app to the same client, the second install will override the first, since the installer "installs [the files] in the Shared\LabVIEW Run-Time\x.x\errors directory, where x.x is the version of LabVIEW".

I can break your app and reciprocally. Well-done NI...

---

That's why I have very explicit names for my error code files.  The whole error code thing feels kind of kludged, though.  I mean, add some errors to your text file and there's no way to update LabVIEW, except to restart.

[X.]

Restarting LV sort of makes sense to me. It's similar to when you update your ini file.

But even then, I noticed that when I corrected a typo in my error codes (using the LV interface for that), when I re-opened the VI where the specific error was selected in the error ring, the text was not updated.

I had to reselect the error for it to update (not as bad as when you modify the text of a typedef enum and VIs using it break because enum constants displaying that specific value are not updated until you force update them).

I will have to experiment and see what happens in an executable when the errors.txt file is removed or modified...

Did anyone try that already?