🚀 go-pugleaf

"Anders Johansen" <home@dduck.dk> wrote in message 
news:47c966f6$1@newsgroups.borland.com...

> The events one can hook using SetWinEvent mostly seem to
> match the messages one would lift from the windows message
> queue using the traditional global hook approach.

Are you referring to SetWinEventHook()?

    http://msdn2.microsoft.com/en-us/library/ms696160.aspx

> Unfortunately, I am stumped figuring out which event constant
> is equivalent to the WM_SYSCOMMAND.SC_RESTORE
> message.

Near as I can tell, there isn't one mentioned in the documentation.  Have 
you tried simply logging the actual values that your event callback receives 
while a window is being restored?


Gambit 

"Remy Lebeau \(TeamB\)" <no.spam@no.spam.com> wrote:
>Are you referring to SetWinEventHook()?

Yes.

>> Unfortunately, I am stumped figuring out which event constant
>> is equivalent to the WM_SYSCOMMAND.SC_RESTORE
>> message.
>
>Near as I can tell, there isn't one mentioned in the documentation.  Have 
>you tried simply logging the actual values that your event callback receives 
>while a window is being restored?

Oh, you mean doing actual work? No, for some reason that did not occur to me
<kicks myself>. :D I guess I could throw together a neat little program that checked 
just that in about 15 minutes. Will do tomorrow.

Thank you for the suggestion. It's funny how one so often forgets to take the 
obvious course...

Somewhat relates to the topic: 
When using these events and LL hooks, I suppose the smart thing to do is to 
decouple the event processing from the actual triggering in the hooks, so as
not to slow down the entire system. What I did was to translate the events into
custom named Windows messages and posting them to an invisible window with
a custom winproc, there to be translated into "ordinary" (i.e. C++) events. This
should allow my processing to fall behind, while the events build up in my
applications message queue, right? Or is this totally misguided?

Anders