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.