Is it possible to cancel the "cancel-event" when pressing ESC in a dialog box?

Here's the situation:
I have a form where I have a cancel and Ok button (and of course lots of other non-important-for-this-case controls). This dialog box should be like any other dialog box, if you press ESC then the form closes and dialogresult should be Cancel. This part is easy, set the cancel button to have dialogresult cancel and the forms CancelButton property should point to this button

The problem is that I want the ESC key to do two different things, depending on situation. Under normal situations it should just close the form, but when I have a certain thread running on the form, I want the ESC key stop this thread (but still leave the form open)

The problem is that unfortunately MS has made it so that when the CancelButton is set on the form, the form closes after the code in the Cancel button has been fired. I haven't found any ways to stop the form from closing after ESC key has been pressed, being able to this would be the best solution IMHO


One solution to do what I want to do is this:
Remove the above mentioned CancelButton from the property on the form and handle the KeyDown Event to check for the ESC key, this gives me complete control. The negative side is that I pretty much need to handle the KeyDown Event on all controls on the form

Is my above mentioned solution the best way to do this? Or is there are way to stop the form from closing after ESC key has been pressed? Or is there some other much better solution I haven't thought about?

When you start the thread, set the form's CancelButton property to nothing, that'll prevent the form's closing code from running, next you'll need to use the form's KeyUp event to detect the escape key and if the thread's running, cancel it and reset the form's CancelButton property back to your cancel button.

Also when the thread completes successfully be sure to re-set the form's cancel button property to your button.

Pretty much what you've already concluded to, I'd just use the KeyUp event instead of KeyDown for Escape key checking.

__________________
Currently using: VS 2005 & 2008 Pro w/sp1 on Win7 Ultimate x64.


There are 3 kinds of people in the world: Those who can count and those who can't.
4 out of 3 people have trouble with fractions.

Windows has a 64 bit GUI for a set of 32 bit extensions on a 16 bit shell for an 8 bit OS using a 4 bit kernel made by a 2 bit company that can't stand 1 bit of competition.

Ah yes, that is a possibility, I'll try that

Thanks for the tip

Ok


I just found a could be solution for that problem. Setting the KeyPreview on the form to true, the forms KeyUp (or KeyDown) event is fired when ESC is pressed, no matter which control is activated... that should take care of that problem

You can use the FormClosing event and e.Cancel it depending on e.CloseReason and your own thread work reason.

Note that the application user is in command, so if user want to close it regardless of what goes on she should be allowed to do so without needing to kill the process. What you can do is to check if work is in progress and if user tries to close you present a dialog that tell user what is going on and give option to continue/close, if user chooses to close anyway you should stop that thread work right away and allow the dialog form to close. You can also do this without "another dialog from the dialog" by making it clear what is happening with for example a statusstrip with status text and progress, which makes it obvious to user if cancelled before 100% whatever is going on will not complete.

__________________

In my example closing the form should without warning kill the thread (like if the user presses the cancel button or the big fat red X). It's just that from the users point of view the thread (which searches for items) should end if the ESC key is pressed (or close the form if no search is in progress)
Seems like the above solution works great

Note: please don't kill the thread.. Do your searching with a BackgroundWorker with SupportsCancellation set to TRUE, and often during your search, check the _backgroundWorker.CancellationPendign property. If it is True, Return from DoWork.

This is the proper way to stop background operations. Killing threads is like using task manager End Process to quit your apps; it can leave things in a proper mess

__________________
DW1 DW2 DW3 DW4 DNU PQ

Well, I don't kill the thread directly. The thread has a loop, for each "round" it looks at a boolean value, if true it exits the loop, ending the thread normally