How can I change the message for an error and then cancel it

[Slyfer]

Interesting questions.

But still I think the Becktho vi example doesn't solve the problem. Am I wrong?

Check out my new counter-example (saved in LV8.2.1)

Becktho redefines a user-space-interval code (3), what if we need to redefine a system code???

EXAMPLE: I don't like the system error window (see jpg attached), because it's written 2 times, it's too complicated for end user. I want to redefine that text when that error code (Labview internal range of errors) happens.

Thanx

[becktho]

Hi Slyfer

Basically I do not define a error code range - this is just to show different possibilites you have in the case of an error and to make this easy testable. With three different codes you can see different actions - or would you have preferred to find an error code somewhere in between 0 and 999999?

If you want to redefine an system code, you can do what I showed in case 3. For instance you could manipulate the error code - so system code 3 is detected, add 5500 which gives code 5503 which could be defined by you.

To get rid of the LV message box, you could also use a native messagebox. The error vi's give you the message of the error. You can use this text and display in another message type. You could also implement one on your own.

[JB]

Use the VI that I uploaded in this discussion some weeks ago.

Don't forget to disable the automatic error handling of the VI that calls this VI (Ctrl + I >> Catagory = Execution >> Enable automatic error handling) to avoid the error dialog box to be displayed in the development environment.

[tst]

---

@JB wrote:

Don't forget to disable the automatic error handling of the VI that calls this VI

---

No, no, no.

In my opinion, there are two things you can do with an error output:

1. You wire it out and handle the error. It then does not matter whether auto error handling is on or off.
2. You forgot to handle one of the errors. If AEH is off, you will not know about your error. If AEH is on, you will know about your error.

In general, you should never get to #2 - always wire your errors and leave the AEH on just as a safety measure.

Darren, on the other hand, thinks that there are cases where he wouldn't mind ignoring the errors and he trusts himself to always wire the error out terminal.

I don't trust myself, so I look at it as a safety net.

[JB]

Hi tst,

I insert above referenced VI in the error cluster wire and then wire its output to an "error/no error" case to handle the remaining errors. Therefore, I would disable the AEH.

Am I missing something ?

[tst]

---

@JB wrote:

...and then wire its output to an "error/no error" case to handle the remaining errors. Therefore, I would disable the AEH.

---

Why? If you're feeding the error wire coming out of the VI into a case structure, it makes no difference whether the AEH is on or off, so why are you turning it off?

[Slyfer]

Activate/deactivate AEH is OFF topic, the original problem was another so please stay in topic and avoid flames (like many post in the first page).

---

@becktho wrote:

If you want to redefine an system code, you can do what I showed in case 3. For instance you could manipulate the error code - so system code 3 is detected, add 5500 which gives code 5503 which could be defined by you.

@becktho

see my attachment now please. I did what you said and it works on your vi example. I use "general error handler" to clear the error number 3, to set up another error code and display the new error code description (provided by my new array of definitions). But

1. I don't understand why 1 instance of "general error handler" can do 2 things at the same time (clear an error + handle another error)
2. the example doesn't work if you insert 3 in error code AND check error (X), this sounds strange.
3. the example doesn't work in my vi, where the error in cluster is like the previous jpg I attached (see top of this page). It is an error of VISA port (that is COM5 is not present in the system)
   

[JB]

OK, I have just learned something !
Thank you for your comment and my apologies to the original author of the question if he considers that AEH is off topic ! This is not my opinion but...

[becktho]

You're right Slyfer - I did not test the vi with the boolean being true.

Now I modified the vi so that if there is an error the code is extracted and searched for in a list. If the code is in this list of codes to ignore the incoming error is cleared and a new error is generated. The code of this new error is calculated, so that it is an a different range.

[tst]

---

@Slyfer wrote:
Activate/deactivate AEH is OFF topic

---

True.

---

the original problem was another

---

Equally true.

---

avoid flames (like many post in the first page).

---

There was no flaming. The first page had reasonable off topic discussion which is simply how the regulars sometimes communicate. Since the original problem was solved and doesn't create too much noise, I don't see that as a problem. This board gets roughly 200-300 posts every day and this sometimes happens with certain threads.

This is a very well behaved place, and I rarely recall seeing any heated arguments around here. Even when there were, they were usually caused by one side (not a regular) not understanding.

As for the AEH, while it was off topic, it was not a flaming war. It was simply informing. I think this is an important issue and when someone makes a statement like "turn AEH off", I prefer to explain the implications. That's also fine. Not all threads here are required to be exclusively on a single topic.

I suggest you browse the forums regularly (as well the LAVA forums and Info LabVIEW, if you have time). It's a great community and a lot of stuff can be learned from it.