Re: Responding to CTRL_CLOSE_EVENT when the application is blocked
From: Alex Blekhman (tkfx.DONTSENDSPAM._at_yahoo.com)
Date: 02/04/04
- Next message: David Liebtag: "Re: DS_CONTROL and captions"
- Previous message: Arnold: "Static Control"
- In reply to: Krzysztof Zelechowski: "Responding to CTRL_CLOSE_EVENT when the application is blocked"
- Next in thread: Słodkie Radio Retro: "Re: Responding to CTRL_CLOSE_EVENT when the application is blocked"
- Reply: Słodkie Radio Retro: "Re: Responding to CTRL_CLOSE_EVENT when the application is blocked"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 4 Feb 2004 18:31:52 +0200
"Krzysztof Zelechowski" <krixel@WP.PL> wrote in message
news:bvoqaj$sr2$1@nemesis.news.tpi.pl...
> First let me give some background information to start with. If you
attempt
> to close the console of your character-mode application, the system
presents
> a dialog box saying that it cannot be cleanly closed. If you want to
close
> it in a more user-friendly way, you have handle a CTRL_CLOSE_EVENT the
> system generates. You accomplish this by calling
> SetConsoleCtrlHandler(ExitOnClose, TRUE);
>
> where ExitOnClose is your handler. The handler gets called in a separate
> thread so you can clean up and terminate the process.
> My question is: can I choose to notify the other threads of my application
> (the main thread, in my case)? It is easy if they have a chance to get
that
> notification by examining a shared variable. However, this does not work
> for me because my application is reading input from the console at that
> time. The only solution I have come up with is to close the standard
input
> handle within the handler. I would like to do it in a more elegant way.
> What if it were reading from a local communications device? Performing an
> asynchronous read is not a solution because the standard handles are open
in
> a synchronous mode and the standard cin object which I am using does not
> support asynchronous operation. I would like to cause the read operation
to
> fail in order to unblock the main thread and test for notofication. It is
> not possible with signals and exceptions because they all act upon the
> current thread (unlike in Unix, where a blocking operation can be
> interrupted from outside without killing the whole process altogether).
Look here for KillThrd library:
http://www.microsoft.com/msj/archive/SFFF.aspx
Or search Google for KTTEST.
- Next message: David Liebtag: "Re: DS_CONTROL and captions"
- Previous message: Arnold: "Static Control"
- In reply to: Krzysztof Zelechowski: "Responding to CTRL_CLOSE_EVENT when the application is blocked"
- Next in thread: Słodkie Radio Retro: "Re: Responding to CTRL_CLOSE_EVENT when the application is blocked"
- Reply: Słodkie Radio Retro: "Re: Responding to CTRL_CLOSE_EVENT when the application is blocked"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
