Caveats
As with all hooks, performance needs to be a top consideration,
although this hook carries a smaller performance penalty than most
other hooks. This is because this hook intercepts fewer messages than
other hooks do. For example, the WH_MOUSE
hook
intercepts many messages every second -- mainly messages such as
WM_MOUSEMOVE
. The WH_SHELL
hook
intercepts messages at a higher level. By this I mean that instead of
calling the hook’s filter function for all messages that are
either sent or posted to create a window, it waits until the window
has been created and then at that point its filter function is
called.
Two of the codes that this hook implements work only on Windows 2000 and greater operating systems. These codes are:
HSHELL_ACCESSIBILITYSTATE
|
HSHELL_APPCOMMAND
|
We should pay attention to when the hook’s filter function is
called. For instance, when window is created, the
HSHELL_WINDOWCREATED
code is fired
after the window is created and displayed.
However, if the window is being destroyed, the
HSHELL_WINDOWDESTROYED
code is fired before the
window is removed from the screen and destroyed.
The HSHELL_TASKMAN
code is fired before the
Windows task manager is opened. This is the only hook code that
allows you to return a TRUE
value to prevent the
action from occurring. No other hook codes have this ability.
It is important to remember that the
HSHELL_APPCOMMAND
hook code is fired only if the
application itself has not processed the
WM_APPCOMMAND
message. Also keep in mind ...
Get Subclassing and Hooking with Visual Basic now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.