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

[BillMe]

In Labview 8.2, Advanced File Functions provide an "express" File Dialog VI. If the user pushes the "Cancel" button during the dialog, the File Dialog VI returns an Error 43. This is NOT an error. This means adding kludgey code to look for "error" 43 so the error can be trashed. What's the point of having a "Cancelled?" boolean on the output of this VI if an error is being generated anyway? The error cluster should be reserved for off-nominal conditions. A user cancelling a File Dialog is perfectly valid and I would expect to be able to use the "Cancelled" indicator to tell me that.

Message Edited by Bill@NGC on 10-21-2006 03:55 AM

[smercurio_fc]

Yeah, that makes no sense to me either. You may want to provide a suggestion here.

[JLS]

Hello,

I of course see the same behavior you do.  I agree that the functionality should change.  I didn't find documentation of the issue being a "problem," but a product suggestion, as suggested and linked above, is a great idea - it's one of the only ways customers have access directly to R&D!

Best Regards,

JLS

Message Edited by JLS on 10-23-2006 01:56 PM

[BillMe]

Suggestion submitted. There are other VI's I've run across that generate "non-errors" on their error cluster outputs as well, like the TCP READ. These always wreak havoc with my error handling, since our environment doesn't allow fault tolerant code, any "real" error is fatal.

I'll input those to the suggestion box as well.

[JLS]

Great - this is great feedback, and it should be taken seriously!

Best Regards,

JLS

[SteveP]

This behavior still exists in 8.6  What can be done is to wire the vi's Canceled boolean output to a Case whose True contains Clear Errors.vi which has its Error In wired to the File Dialog's Error Out.

[gmart]

Much discussion was had whether to stop returning an error 43 for the File Dialog function (which is used in the Express VI). It made no sense to many people that a cancellation event should generate an error. Why wasn't there a "cancelled" indicator? The error was about to be removed, but then the realization hit that for the many years of the function's life in LabVIEW, it has returned an error 43. What should be done to the user base who implemented their code to handle this error? So rather than cause upgrade nightmares, I beleive the cancelled indicator was added and the error was left as is. This is my understanding of the situation and hopefully it helped better explain why the behavior is the way it is.

[Edjsch]

It doesn't help to wire a Case structure with a Clear Errors vi to the cancelled output (as SteveP suggested). HOWEVER, (in the Write TDMS File example vi) if I put the rest of the code in the False of the Case and the Clear Errors vi in the True (cancelled) case, then it works and suppresses the error (42).

Now get this: I then deletetd the Clear Errors vi and it still works! Then if I delete the Case structure (leaving the False case), the error on cancelling comes back!

You should be able to replicate this and seems to be a good work-around. Does anyone (NI Apps people?) know why this works?

[OliviaC]

Hi Edjsch,

Using a case structure works because error 43 is being handled by being wired into the case structure. Without the case structure, the error isn't being handled and pops up a dialog box. Another work around would be to wire an idicator to the error out from the File Dialog VI and hide the indicator on your front panel. The down side is you'll still get an error from the TDMS VI's because they are trying to access a file but you have not specified one.

[Edjsch]

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.