Confused about the Error Ring customization options

[billko]

---

@X. wrote:

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?

---

My experiences were exactly the same as yours - and I was too scared to try what you suggested.  😉

As far as restarting, I just wish they had an option to re-read the error file.

[bienieck]

---

@X. wrote:

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):

---

Hi, Is there any conclusion regarding this issue? Why I cannot use %s formatters?

[JÞB]

Yeah, its weak.  Remember that the error ring is a special thing that can resize based on format specifiers the developer types.  Similar to format string.  The DX would really hurt your eyeballs if error.txt values had arbitrary format specifier strings.

Next, once a string is selected for the error ring it is a string constant.  It won't look at the error.txt file every time it is loaded into memory (imagine trying to track the dirty dot forcing reserved because "String constant value updated from external file")  <I'm sorry if that thought made you throw up a little>

Distribution of custom errors is a serious concern.  You have to look at when to do so.  Generally, don't unless you are distributing a driver or a toolset.  

Better yet, only allow your project to be used by developers that never write bugs or code errors

[bienieck]

---

@JÞB wrote:

Remember that the error ring is a special thing that can resize based on format specifiers the developer types.

---

Good point. So, it seems to me that the whole thing was not well thought.

It would be better to support %s operators by default and always have one "args" input in the error ring, without resizing capability. The input could be just an array of strings and the error ring would need to replace every %s operator with items from the args array. A more fancy solution would need to have an array of variants. I imagine, more sophisticated operators could be used then.

---

@JÞB wrote:

Distribution of custom errors is a serious concern.  You have to look at when to do so.  Generally, don't unless you are distributing a driver or a toolset.  

---

Providing descriptive error (exception) messages is normal practice. It's unavoidable in software development. If there is any concern it's related to the support NI gives in LabVIEW to handle it.