File Dialog generates error 43 when user cancels the dialog - so what good is the CANCELLED indicator?

[Ben]

---

Edjsch wrote:

Thank you, Olivia, for your input. I understand why the Case structure works, but ONLY if the rest of the code is in the false case (the true case being the Clear Errors vi). Maybe this is what SteveP meant to say.

Furthermore, you didn't address why, after I deleted the Clear Errors vi in the true Case, the error was STILL suppressed!

Also, wiring an indicator to the error out, as you suggested, doesn't suppress the error message, so it isn't a workaround. 

---

Automatic error handling is turned on on your machine. That is an option you can shut off if you do not want to see the error. The dialog comes up anytime there is an error that flows the end of a wire and is in danger of being ignored or lost. When it is wired to to some code or logic that "looks" like it is handling the error, the error will not trigger the error message.

Ben

[Edjsch]

Thanks, Ben. Yes, I have automatic error handling enabled (that is the default). I verified what you said: If I put the rest of the code in the false case and have wired the error out to the Case but have not yet placed the Clear Errors vi, the error is suppressed. So it's NOT the Clear Errors vi that's causing the suppression here!

However, if I just put an empty Case structure with the error out wired to it (and the cancelled output connected to the selector terminal, of course), the error is NOT suppressed! Why doesn't Labview "think" the error is being handled here?

[Ben]

---

Edjsch wrote:

Thanks, Ben. Yes, I have automatic error handling enabled (that is the default). I verified what you said: If I put the rest of the code in the false case and have wired the error out to the Case but have not yet placed the Clear Errors vi, the error is suppressed. So it's NOT the Clear Errors vi that's causing the suppression here!

However, if I just put an empty Case structure with the error out wired to it (and the cancelled output connected to the selector terminal, of course), the error is NOT suppressed! Why doesn't Labview "think" the error is being handled here?

---

Show us a picture.

LV is smart* enough to know if the error cluster is being used for anything. You actually have to USE the error cluster if you want to prevent the pop-up.

*Smart - THe code that turns you diagrams into code is amazing. Example: If you use an invoke node to get the image of an object BUT you do not wire the returne data to anything, LV ID's that code as a "No-OP". Similarly with wires that do nothing. THe wonders of LV extend far beyond that to functionlaity like "THis wire is branching to two functions, one just looks at the dat the other mods it. If it schedule the code such tht the "looker" runs first then the buffer with the data can be re-used by the other function therby save a buffer copy.

Have fun!

Ben

[Edjsch]

I've attached the block diagram screen shots. You see that in the empty true case, the error is doing nothing - it just dead-ends there - but it suppresses the error, even without the Clear Errors vi. If I just wire the error to a totally empty Case structure, even if the Clear Errors vi is wired to the error out of the File Dialog vi, then the error is NOT suppressed. I take your point that LabView is "pretty smart" though.  Please let me know what you think.

[Ben]

TRhaat image ilustrates my point that you can't just wire the erro cluster to the edge of a structure and think you are going to trick LV into thinking the error has been handled. You have to actually HANDLE the error. When wired to the Clear Error VI you are "HANDLING" the error.

Ben

[Edjsch]

Thanks, Ben, but you are missing my point. Notice there is no Clear Errors vi, and the error out IS just wired to the edge of the Case structure and is NOT connected to anything, and it does seem to "trick", as you say, Labview into think that the error is being handled. This is my question: Why does this work?

[altenbach]

---

Edjsch wrote: 
Why does this work?

---

You have automatic error handling enabled, meaning nodes with unwired error output trigger an error popup if an error occurs. Once you wire to the edge of the case, the output of the primitive is no longer unwired. Right?

[Edjsch]

Right, but you said, "you can't just wire the erro cluster to the edge of a structure and think you are going to trick LV into thinking the error has been handled". It DOES trick LV!

As I said, this does not work unless the remaining code is in the false case, so I'm sure that has something to do with it. The fact that the error out is wired to something, even a dead end, and the fact that no other code is to be executed, the vi just stops without generating the error.

(I raised this question partly because in my application I have the file dialog's cancelled output wired to a false case (the true case is empty and that Case is only a very small part of my code), but the error out is not wired, and no error is generated! I still have not figured out why.)

[altenbach]

---

Edjsch wrote:

As I said, this does not work unless the remaining code is in the false case, so I'm sure that has something to do with it.

---

The remaining code will generate an error because the filename is not valid if the dialog is cancelled, so the tdms stuff will throw an error.

[Edjsch]

That's right! The first error is not 43, the error is from the TDMS Write. I didn't notice this. Thanks.

However, "dead ending" the error out to the Case structure DOES suppress the error! I'm sure this is by design. Correct? (If I don't connect the File Dialog's error out, then I do get the Error 43 from the File Dialog vi.)

(I still haven't figured out why my app is not generating a cancel error, even though I have the File Dialog's error out unconnected, but there must be a reason.)