How can you know which button was clicked in a dialog?

[JohnInDC]

I have a common dialog object, and I'd like to know which button was clicked when the dialog closes.

OK, here's the whole story... I don't want to generate and trap the cancel error in my save as dialog. There must be a better way to do that, and I'm on a quest to find it. No luck so far though, except that I understand what I need to do. When the dialog closes, I need to check to see if it was closed by the cancel button being clicked. If so, do nothing. If not, then do the save (export actually, in Crystal Reports).

I can't find a way to know if the cancel button was clicked though, other than generating and trapping that error.

I refuse to intentionally generate an error. It goes against the foundation of my belief system. It's an egregious affront to all decent principles of programming.

Thanks,
John

 

[DrJavaJoe]

Set the CancelError property to False and check if the Filename is blank.

if Len(CommonDialog1.FileName) = 0 then
'cancel clicked
end if


Two strings walk into a bar. The first string says to the bartender: 'Bartender, I'll have a beer. u.5n$x5t?*&4ru!2[sACC~ErJ'. The second string says: 'Pardon my friend, he isn't NULL terminated'.

 

[TipGiver]

Check the CommonDialog1.FileName

If it is "" then cancel was hit (no matter if you had selected any file)
Else you hit Save

 

[JohnInDC]

So when the user clicks the cancel button, it sets the filename to ""? Because I actually set a default filename, so the filename would have to be reset. Is that what happens?

Well, I'll find that out myself.

Thanks guys!!!

JT

 

[JohnInDC]

Sweet! It work great. Thanks again!

JT

 

[BobRodes]

<I refuse to intentionally generate an error. It goes against the foundation of my belief system. It's an egregious affront to all decent principles of programming.

You may find thread678-1090842 interesting.

Bob

 

[strongm]

Bob,

Thought I'd just comment here about that thread: I'm a big user of exceptions in production code, and tend to agree with many of the points that you tried to raise there

 

[BobRodes]

Thanks strongm, it's nice to know I'm not a lone standard bearer on that issue.

 

[JohnInDC]

Bob,

Thanks for the link to that discussion. It was very interesting.

I agree with what one person said:

If according to your logic the object should always be there, then throw an exception when it is not. If, however, there is a chance that your program is working correctly and the ID just might not be valid, then return null.

That's why I think generating an error when the user clicks cancel is wrong. If they hit Alt-F4, maybe, but the user canceling the save is not out of the norm. I'm really glad there's a way to avoid doing it that way.

JT

 

[BobRodes]

I guess (and I hate to take that discussion and beat it to death after it's already long dead) my feeling is that if you see the user opening the file for the purpose of getting a file, it violates that assumption for the user to not get a file. As such, to not get that file is an exception to the rules of engagement.

I believe that the concept of "error handling" is morphing into a concept of "exception handling". The reason is practical: the process involved can be profitably applied to any occurrence that falls outside of the established rules of engagement.

So, personally, I feel as comfortable generating an "error" when the user clicks cancel as I do with any other error in VB. In other words, it stinks, but it's the closest thing we have to the way things ought to be. And whether it's really an error or not isn't relevant to me. It's a pragmatic issue.

As for whether you ought to do it this way or the way that you chose, well, there are maybe 5000 words on that (with perhaps 1000 too many) in the other post.

Best regards,

Bob