Add Cancelled output to Export Image invoke node.

[NI-hilator]

In my experience using and developing software it is typical save behavior to simply exit the dialog when a user clicks Cancel to a save operation.  This is reasonable if, when the file selection dialog is open, the user does not click anything (i.e. there is nothing in the file name field) and just clicks Cancel.  However, when the user has selected an existing file from the directory or there is a default file name in the file name field, I like to warn the user that the file was not saved when Cancel was clicked.

When invoking the Export Image method, if Always Overwrite is False, it will prompt the user if they are about to overwrite a file with dialog box that has an Ok and Cancel button.  This is great however there is no way to capture what the user clicked.

It would seem like good form to have a Canceled or Ok output just as in File Dialog express VI. 

[crossrulz]

I'm surprised to see that not even an error it thrown.

[Darren]

---

@crossrulz wrote:

I'm surprised to see that not even an error it thrown.

---

I agree, and I'd argue that an Error 43 output from the Invoke Node would be preferrable (and probably easier to implement) than a new parameter.

[GregFreeman]

I agree with Darren that the error out is a better way to handle it. Then you can manage the file being there however you want, and aren't stuck using the default dialog.

[fabric]

Surely a specific choice made by the user does not constitute an error? Yes, your application may choose interpret a cancelled operation as an error, but an "error out" from the node itself implies (to me at least) a failure of some sort...

I prefer the original idea.

[crossrulz]

I think it should be consistent with the Open/Create/Replace File VI which will generate an error 43 if the user cancels the dialog.

[NI-hilator]

Yes, there seems to be inconsistency in how Cancel is handled throughout various file dialogs.  The "low level" VIs like Open/Create/Replace, Read from Text/Binary File, New Zip/Unzip file seem to consistently give Error 43 when the user cancels.  The express VIs tend to not give and error when the user cancels, however this is not consistent.  The Read From Measurement File, Display Message to User, and Prompt User for Input do not cause any error from a cancel action but the File Dialog does.  Even more interesting (more desirable?) is the Write to Measurement File, which gives an "Are you sure? Your data will not be saved to file." with Do Not Save and Try Again buttons.  Furthermore, the Two Button Dialog does not have an error out at all.

[rolfk]

The premise that an error always means a serious problem can not be assumed at all. The mentioned File IO functions are implemented like this since about their inception in LabVIEW 2 or so, and can not be changed without serious compatibility issues when upgrading existing projects. Also there are many other areas in LabVIEW where a returned error could indicate a problem, but just as much can be a legitimite result of some operation that the caller needs to be able to deal with properly. For instance in network communication there are many errors that can be returned that can or can not indicate a problem. Same for VISA or other communication interfaces that return very regularly timeout errors, that often are not an indication of any problem but simply one that the remote site didn't send anything so far and you should retry after some time.

So the idea that an error 43 is not fully legitimate is not really a valid claim. After all if your code is prepared to deal with that error properly (and do some fallback operation or whatever) nothing is wrong, however if you forgot to handle that case at all, the error will at least indicate a potential problem if you do any error handling at all. And if you don't do any error handling then it doesn't matter anyhow!

[NI-hilator]

I never meant indicated an error 43 is not fully legitimate.  I was simply pointing out an inconsistency. Thank you for explaining the history behind the File IO functions.  The feature request is still a valid one - for the Export Image method to have some sort of indication that Cancel was clicked, be it a Canceled property or a generated error.

[rolfk]

@NI-Hilator, my comment was actually more directed towards fabric and not to you. Your observations are accurate. The reason that the Two button dialog and the according Express VIs do not create an error 43 is only because they have always already had a boolean that indicated which button was selected by the user.

[NI-hilator]

@rolfk - no worries.  Just clarifying my perspective.  Thanks for your insight and weighing in.