<a href="http://www.micropoll.com/akira/mpview/585320-168921">Click Here for Poll</a><a href="http://www.questionpro.com" title="online surveys">Online Survey</a><BR> | <a href="http://www.micropoll.com" title="Website Polls">Website Polls</a><BR> | <BR><a href="http://www.micropoll.com/akira/MicroPoll?mode=html&id=168921">View MicroPoll</A></div>

Visual Studio 2010!

Read now >

Windows Mobile Development Thoughts

Read now >

View Now
DevSource RSS FEEDS
XML Want an easy way to keep up with breaking tech news? And the Get DevSource headlines delivered to your desktop with RSS.
ADVERTISEMENT
ADVERTISEMENT

 

DevSource.com: Your Source for Visual Studio on Facebook
ADVERTISEMENT
Globally Hooking Windows Messages in .NET
By John Mueller

Rate This Article: Add This Article To:

Globally Hooking Windows Messages in .NET - ' The '
( Page 2 of 3 )

.NET Issues">

Sometimes, you want to know about messages outside your application. You might want to know when someone starts a particular application or where the mouse is globally. A global hook could help your application look for certain kinds of activity and even help guard against viruses.

Windows makes messages external to your application available as part of a global hook. The previous article in this series, Hooking Windows Messages in .NET, showed how to hook thread messages using pure .NET code. This article concentrates on the requirements for creating hooks that interact with all of the applications executing within Windows.

Understanding the .NET Issues

You could theoretically create a global hook using .NET code — except for two little problems.

When a DLL executes globally, it executes within the address space of the application that's using it. In addition, you might have multiple copies of the DLL executing, each of which is in its own address space. All the global variables you declare within the DLL are private to that instance of the DLL. Consequently, the hook handle declared for one instance of the DLL is different from the hook handle for another instance. The third argument of the SetWindowsHookEx() function is an instance handle. You don't need to provide this value when working at the thread level, but you do need to provide it when working at the global level, or the call will fail.

The second problem is that addresses aren't consistent in Windows. An address is only useful within the context of the application that creates it. If Application A attempts to use an address created by Application B, the reference fails. Now, consider how you use hook procedures. You save the address of the calling application, the one that's processing the message information, and use that address to send it data. Every copy of the DLL must send the information to the same window. However, you don't have any central place to store that data when working with .NET. In fact, you have to use a rather odd-looking global memory workaround when working with C++ to accomplish the task. By creating a global memory area whose address remains consistent, you can store the calling application's address.



 
 
>>> More Using Microsoft Visual Studio Articles          >>> More By John Mueller