Re: Handling Ctrl-Break quickly and efficiently in a Windows GUI a

Thanks, but my app cannot accept input until this operation succeeds. It
could involve a network transaction to a server, so it could take awhile, it
could even timeout.

To make it clearer, imagine you hit the New Memo button in your e-mail
client. While it's bringing up a memo form for you to type in your message,
it has to put up a wait cursor. Most users hit New Memo and just start
typing, assuming that their keystrokes will end up in the new memo. So I
don't want to throw away their keystrokes, but I do want to allow them to hit
Ctrl-Break at any time to cancel the operation.

"Alexander Grigoriev" wrote:

Since you should still run a message loop to handle Stop button, just let it
handle the rest WM_KEYDOWN you're not interested in. If they are discarded,
so let it be.

If you want the users to be able to type ahead, just don't make the app
busy. Put all background processing to a separate thread.

"ACABThomas" <ACABThomas@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:D63B5928-2E7B-499F-9DB5-F23C268E7226@xxxxxxxxxxxxxxxx
I have a multithreaded Windows GUI application written with Visual C++.
When
my program is busy, I display the hourglass cursor and allow them to click
a
"Stop" button to cancel processing. I also want to allow the user to hit
Ctrl-Break to signal my program to stop processing.

To do this today, I use PeekMessage to watch for a WM_KEYDOWN message,
check
if it's VK_CANCEL, and if so, terminate my operation. The problem is that
PeekMessage will return the first WM_KEYDOWN message that it finds in my
message queue. So if I do not specify PM_REMOVE in the call to
PeekMessage,
then the WM_KEYDOWN for the Ctrl-Break could get hidden behind the
WM_KEYDOWN
for any other key that the user happens to hit. But, if I do specify
PM_REMOVE, I'm not in a position to handle the keystrokes at that moment
(because my program is busy), so I end up throwing away the messages, and
thereby causing type ahead to not work. This is painful for my end users
as
this is an e-mail application, they are typing as a new, blank Memo is
coming
up (with the wait cursor up), and their keystrokes are lost.

Rather than toss the other WM_KEYDOWN messages, I could try to store them
and process them when my program is no longer busy. But that seems
awfully
messy and fraught with complications.

I thought maybe I could set a signal handler, perhaps using
SetConsoleCtrlHandler, but that only seems to work for console apps, not
GUI
apps.

I'm currently thinking that I can play games with RegisterHotKey to
accomplish this, but that feels unclean also.

Is there a clean way for a Windows GUI app to get notified of Ctrl-Break?
Is there a way to set a signal handler, or scan the entire message queue,
scanning past multiple WM_KEYDOWN messages, without having to remove each
message from the queue?




.

Quantcast