Thank you Nick! This is exactly what I needed. I had heard the Reflection term thrown around, but never realized what it was. Being a Visual C++ developer, this term means something very different to me. Thank you again. :)

I've done quite a bit of work in this area dating way back to the .NET 1.0 beta days. As far as hot keys, understand that only dialogs process characters and may or may not pass those messages to child controls, such as your UserControl. In the case of IE, it most likely won't because a site could hijack your settings (the web is a very dangerous place to visit, probably even more hostile than Iraq right now!). That would be my educated guess. As far as visual styles, calling Application.EnableVisualStyles() must be done in an application - not your control. What this does is load a general manifest from the .NET Framework directory (ex: %WINDIR%\Microsoft.NET\Framework\v1.1.4322) BEFORE controls are created, which encapsulate the Windows Common Controls. Once those are loaded into an address space for a process and used by a particular module, that module cannot use two different versions (but the process can, IIRC). You need to instead embed a manifest in your PE/COFF executable (not the assembly itself, rather, the manifest of resources) using a particular ID. For starters, read my article Windows XP Visual Styles for Windows Forms[^], which describes the "old" way (still supported) of embedding manifests as Win32 resources. You'll also want to read Visual Styles[^] on MSDN. Another article you may find interesting about making your embedded UserControl scriptable (as well as exposing events), take a look at a very old article of mine on a different site, User Controls for Winodws and the Web[^]. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles]

Thank you for the article...that is a big help.

That's a really good idea. Thanks for the quick response.

Thanks Simon. That was the exact article I was looking for.

Worked perfectly. Thanks a ton. -Ron

this.Focused

It looks like NetShareDel is the API function you need. Software Zen: delete this;

That's basically the way the underlying Win32 function works. One common approach is to try to open the file - it will be there and accessible when you can open it.

Checking for the WM_QUERYENDSESSION and WM_ENDSESSION worked perfectly! Thanks Gaul.