Hooking question

[pigeonrandle]

Hi,
Has anyone had any experience with hooking messages in other
application windows (like SPY++). I want to listen for WM_MOVE
messages, but can only seem to find examples of Keyboard and Mouse
hooks.

Please (and thankyou),
James Randle.

[William DePalo [MVP VC++]]

<pi**********@hotmail.comwrote in message
news:11*********************@s13g2000cwa.googlegro ups.com...

Has anyone had any experience with hooking messages in other
application windows (like SPY++). I want to listen for WM_MOVE
messages, but can only seem to find examples of Keyboard and Mouse
hooks.

Let's review:

All of the hooks work in a similar way: There are two types - thread
specific and system wide. In the former case the thread doing the hooking is
interested in events that belong to it. In the latter case, the thread doing
the hooking is interested in all events of a type across all threads in all
processes in the system.

In order for the system wide hook to work the code in the hook procedure
must be mapped into the process whose events you want to hook. That means
the hook has to be in a DLL.

In all cases, a hooked event manifests itself as an invocation of a
callback.

So the only difference really in the mechanics of the hooks is in the
callback. If you understand the keyboard example, say, what you want to do
differs from that only in the implementation of the callback.

As you say the event that you are interested in is out of process, then you
need to use a system wide hook. Check the docs for SetWindowsHook(WH_CBT,
....) and its callback - CBTProc().

System wide hooks mis-used often cause system instability. I've always
thought that it is best to use them sparingly. And when you must, detect the
event in the callback, but process it in your own application if you can do
that - say by posting yourself a message. That way, if something bad
happens, it happens in one application (yours) and not in innocent bystander
applications.

Regards.
Will

[pigeonrandle]

Will,
Thanks for replying - especially with a decent amount of info. I think
i was sinking under all the terminology.
I was under the impression (from what i see in SPY++) that i could just
attach a hook to a single window in another process. From what you're
saying though, am i right in thinking that SPY++ hooks all the messages
for all the processes, and then just displays the relevent ones for the
window(s) you selected (filtering by the window handle i presume)?

Thanks again,
James

William DePalo [MVP VC++] wrote:

<pi**********@hotmail.comwrote in message
news:11*********************@s13g2000cwa.googlegro ups.com...

Has anyone had any experience with hooking messages in other
application windows (like SPY++). I want to listen for WM_MOVE
messages, but can only seem to find examples of Keyboard and Mouse
hooks.

Let's review:

All of the hooks work in a similar way: There are two types - thread
specific and system wide. In the former case the thread doing the hooking is
interested in events that belong to it. In the latter case, the thread doing
the hooking is interested in all events of a type across all threads in all
processes in the system.

In order for the system wide hook to work the code in the hook procedure
must be mapped into the process whose events you want to hook. That means
the hook has to be in a DLL.

In all cases, a hooked event manifests itself as an invocation of a
callback.

So the only difference really in the mechanics of the hooks is in the
callback. If you understand the keyboard example, say, what you want to do
differs from that only in the implementation of the callback.

As you say the event that you are interested in is out of process, then you
need to use a system wide hook. Check the docs for SetWindowsHook(WH_CBT,
...) and its callback - CBTProc().

System wide hooks mis-used often cause system instability. I've always
thought that it is best to use them sparingly. And when you must, detect the
event in the callback, but process it in your own application if you can do
that - say by posting yourself a message. That way, if something bad
happens, it happens in one application (yours) and not in innocent bystander
applications.

Regards.
Will

[William DePalo [MVP VC++]]

<pi**********@hotmail.comwrote in message
news:11*********************@h48g2000cwc.googlegro ups.com...

Thanks for replying - especially with a decent amount of info.

You are welcome.

I think i was sinking under all the terminology.

I feel your pain. :-)

I was under the impression (from what i see in SPY++) that i could just
attach a hook to a single window in another process. From what you're
saying though, am i right in thinking that SPY++ hooks all the messages
for all the processes, and then just displays the relevent ones for the
window(s) you selected (filtering by the window handle i presume)?

I should tell you that I have not looked at the code so I can't say for
sure. My guess is that it uses a system wide hook and filters the display.

At the risk of adding even more head-splitting details into the mix ...there
are other ways to fry this fish. Sometimes an application will put up a
system wide hook with the express purpose of insinuating itself into a
target. That done, it might subclass the window. Sometimes a remote thread
is created in the target process:

http://www.codeproject.com/threads/w...sp?msg=1026016

http://www.catch22.net/source/files/InjectThread.c

In any case - creating a system wide hook, starting a remote thread,
subclassing a window you don't own - these are all pretty nasty things that
should be done only when you have no other choice. What's your ultimate
goal, btw?

Regards,
Will

[pigeonrandle]

Hello Again,
And again, many thanks for your insight. Bed got the better of me about
5 minutes after i replied yesterday, so apologies for the belated
response.

I'm writing a program that is a remote control for another application.
I would like to record information about 'how the other app is used',
(in particular how its mdi forms are moved around) but the jounal
record/playback doesnt fit the bill because when i am remote
controlling the other app, it sits under a transparent window in my
form.
Totally complicated, but absolutely necessary!
Besides, the other apps mid windows always popup in stupid places. lol,
standard.

There are also a million other functions i would like to include, and
most of them will need to peer into the messages of particular windows
in the accursed other app.

James.

I like challenges, especially the ones i can do.
William DePalo [MVP VC++] wrote:

<pi**********@hotmail.comwrote in message
news:11*********************@h48g2000cwc.googlegro ups.com...

Thanks for replying - especially with a decent amount of info.

You are welcome.

I think i was sinking under all the terminology.

I feel your pain. :-)

I was under the impression (from what i see in SPY++) that i could just
attach a hook to a single window in another process. From what you're
saying though, am i right in thinking that SPY++ hooks all the messages
for all the processes, and then just displays the relevent ones for the
window(s) you selected (filtering by the window handle i presume)?

I should tell you that I have not looked at the code so I can't say for
sure. My guess is that it uses a system wide hook and filters the display.

At the risk of adding even more head-splitting details into the mix ...there
are other ways to fry this fish. Sometimes an application will put up a
system wide hook with the express purpose of insinuating itself into a
target. That done, it might subclass the window. Sometimes a remote thread
is created in the target process:

http://www.codeproject.com/threads/w...sp?msg=1026016

http://www.catch22.net/source/files/InjectThread.c

In any case - creating a system wide hook, starting a remote thread,
subclassing a window you don't own - these are all pretty nasty things that
should be done only when you have no other choice. What's your ultimate
goal, btw?

Regards,
Will

[William DePalo [MVP VC++]]

<pi**********@hotmail.comwrote in message
news:11**********************@75g2000cwc.googlegro ups.com...

And again, many thanks for your insight.

You are welcome.

Bed got the better of me about 5 minutes after i
replied yesterday, so apologies for the belated
response.

:-)

I'm writing a program that is a remote control for another application.
I would like to record information about 'how the other app is used',
(in particular how its mdi forms are moved around) but the jounal
record/playback doesnt fit the bill because when i am remote
controlling the other app, it sits under a transparent window in my
form.
Totally complicated, but absolutely necessary!
Besides, the other apps mid windows always popup in stupid places. lol,
standard.

There are also a million other functions i would like to include, and
most of them will need to peer into the messages of particular windows
in the accursed other app.

OK, so this is at the level of thinking out loud so take it with a grain of
salt.

You might want to take a look at the Computer Based Training (CBT) hook. The
problem it lives to solve is not remote control but rather user training.
Typically these applications first demonstrate a sequence of user interface
options and say - OK - now you try it. That's where the hook comes into
play. I receives notification of the user's actions and compares that to
what it expected to see if the user is catching on. Perhaps that's along the
lines of what you want when you say

<quote>
I would like to record information about 'how the other app is used'
</quote>

There is another option as well. I am assuming that you don't have the
source to the application that you want to control. So at first blush you
need the system wide hook bit it seems intrusive and wasteful where you want
to control one application. So you might want

[In your application]

a) register a private message - see RegisterWindowMessage()
b) set a WH_CALLWNDPROC hook system wide - SetWindowsHookEx(WH_CALLWNDPROC,
....)
c) send the target application the registered message

[in your hook DLL]

d) on reception of the private message load your remote control stuff into
the target application
(because you get control in the target process (on NT/2K/XP/2K+3) you can
now use thread specific hooks)

[in your application]

e) remove the hook after having sent the private message

In that way, you have a system wide hook installed only for the short time
it takes to put your remote control business in operation. Note that no
matter how you go, debugging code that you use to instrument an external
application is always a bear. Good luck.

Regards,
Will

[pigeonrandle]

William,
Merci! Another bounty of excellent information.

I've been doing a lot of digging around today and have finally got my
head around (the most part) of how this all fits together.

I found this article

http://www.codeproject.com/system/Mi...ndowToTray.asp

which uses a global hook (the code is well commented too) to trap
messages in another process.
It was nice to see an example that wasnt focused on mouse coordinates,
but more useful windows messages.

If i may, i have a quick question?!
In the example you've given, when you refer to 'loading my remote
control stuff', i presume you mean 'injecting another dll function'
(check my newly learned terminology out!) into the other process that
would 'forward' any messages i have an interest in to my program,
before letting the other process use them.

REALLY thanks!
James.
William DePalo [MVP VC++] wrote:

<pi**********@hotmail.comwrote in message
news:11**********************@75g2000cwc.googlegro ups.com...

And again, many thanks for your insight.

You are welcome.

Bed got the better of me about 5 minutes after i
replied yesterday, so apologies for the belated
response.

:-)

I'm writing a program that is a remote control for another application.
I would like to record information about 'how the other app is used',
(in particular how its mdi forms are moved around) but the jounal
record/playback doesnt fit the bill because when i am remote
controlling the other app, it sits under a transparent window in my
form.
Totally complicated, but absolutely necessary!
Besides, the other apps mid windows always popup in stupid places. lol,
standard.

There are also a million other functions i would like to include, and
most of them will need to peer into the messages of particular windows
in the accursed other app.

OK, so this is at the level of thinking out loud so take it with a grain of
salt.

You might want to take a look at the Computer Based Training (CBT) hook. The
problem it lives to solve is not remote control but rather user training.
Typically these applications first demonstrate a sequence of user interface
options and say - OK - now you try it. That's where the hook comes into
play. I receives notification of the user's actions and compares that to
what it expected to see if the user is catching on. Perhaps that's along the
lines of what you want when you say

<quote>
I would like to record information about 'how the other app is used'
</quote>

There is another option as well. I am assuming that you don't have the
source to the application that you want to control. So at first blush you
need the system wide hook bit it seems intrusive and wasteful where you want
to control one application. So you might want

[In your application]

a) register a private message - see RegisterWindowMessage()
b) set a WH_CALLWNDPROC hook system wide - SetWindowsHookEx(WH_CALLWNDPROC,
...)
c) send the target application the registered message

[in your hook DLL]

d) on reception of the private message load your remote control stuff into
the target application
(because you get control in the target process (on NT/2K/XP/2K+3) you can
now use thread specific hooks)

[in your application]

e) remove the hook after having sent the private message

In that way, you have a system wide hook installed only for the short time
it takes to put your remote control business in operation. Note that no
matter how you go, debugging code that you use to instrument an external
application is always a bear. Good luck.

Regards,
Will

[William DePalo [MVP VC++]]

<pi**********@hotmail.comwrote in message
news:11*********************@i3g2000cwc.googlegrou ps.com...

Merci! Another bounty of excellent information.

Pas de quoi.

I've been doing a lot of digging around today and have finally got my
head around (the most part) of how this all fits together.

I found this article

http://www.codeproject.com/system/Mi...ndowToTray.asp

which uses a global hook (the code is well commented too) to trap
messages in another process.

I haven't read that article but ther is lots of good stuff there.

If i may, i have a quick question?!
In the example you've given, when you refer to 'loading my remote
control stuff', i presume you mean 'injecting another dll function'

You see most (I think a couple on 9x are exceptions that provide the rule)
global hooks run in the process of the application whose event is being
hooked. That's why system-wide hook procedures need to be in DLLs. Windows
loader already "knows" how to load DLLs into processes. So what Windows does
behind the scenes is load a the hook procedure DLL into EVERY process in
which an event causes a callback to happen in the hook procedure.

And that's what's so scary. System wide hooks bloat everything and anything.
And error in one can say cause a trivial application like Notepad to crash
and burn. So, I sketched a simple kind of trampoline where you hop into the
target process by means of the global hook, insinuate yourself and then take
down the hook.

So, I was deliberately vague about load the remote control stuff because I
don't know what you need. With the method I sketched, the point is that once
you trap the registered message you are executing in the other process. If
your stuff is cast as a DLL, you can do a simple LoadLibrary() to install
it.

(check my newly learned terminology out!) into the other process that
would 'forward' any messages i have an interest in to my program,
before letting the other process use them.

REALLY thanks!

Really, you are welcome. :-)

Regards,
Will

[pigeonrandle]

Will,
Thanks again. It feel like I am about to step through the looking glass
(-:

James.

William DePalo [MVP VC++] wrote:

<pi**********@hotmail.comwrote in message
news:11*********************@i3g2000cwc.googlegrou ps.com...

Merci! Another bounty of excellent information.

Pas de quoi.

I've been doing a lot of digging around today and have finally got my
head around (the most part) of how this all fits together.

I found this article

http://www.codeproject.com/system/Mi...ndowToTray.asp

which uses a global hook (the code is well commented too) to trap
messages in another process.

I haven't read that article but ther is lots of good stuff there.

If i may, i have a quick question?!
In the example you've given, when you refer to 'loading my remote
control stuff', i presume you mean 'injecting another dll function'

You see most (I think a couple on 9x are exceptions that provide the rule)
global hooks run in the process of the application whose event is being
hooked. That's why system-wide hook procedures need to be in DLLs. Windows
loader already "knows" how to load DLLs into processes. So what Windows does
behind the scenes is load a the hook procedure DLL into EVERY process in
which an event causes a callback to happen in the hook procedure.

And that's what's so scary. System wide hooks bloat everything and anything.
And error in one can say cause a trivial application like Notepad to crash
and burn. So, I sketched a simple kind of trampoline where you hop into the
target process by means of the global hook, insinuate yourself and then take
down the hook.

So, I was deliberately vague about load the remote control stuff because I
don't know what you need. With the method I sketched, the point is that once
you trap the registered message you are executing in the other process. If
your stuff is cast as a DLL, you can do a simple LoadLibrary() to install
it.

(check my newly learned terminology out!) into the other process that
would 'forward' any messages i have an interest in to my program,
before letting the other process use them.

REALLY thanks!

Really, you are welcome. :-)

Regards,
Will