To register for the SensLogon events, we need to implement the ISensLogon interface, with its required methods. In .NET we usually use delegates and events for notification. To translate between the COM method calls and the .NET events we would rather have, we need a structure to mask the old COM code.

When another programmer imports this library, we only want my .NET-friendly classes and events to be exposed. The main class we will expose is called SensLogon, and will have static events for logon, screen lock, etc. To directly receive the messages and then raise the events, this class would need to implement the ISensLogon interface, but that would expose the methods of the interface to anyone, allowing other code to fake the events. To prevent this, we will create a private inner class called SensLogonInterop to implement and hide the interface, register for the events, and forward the events to the containing class. Some of the code for this implementation is in Listing 4 (though much of the code is removed for brevity, it is very similar to what is shown).

The SensLogonInterop class has a few constant and static values at the top for registering with the COM+ Event System. These members are used in the class constructor to register it with the Event System. Since it is a private inner class, it can only be instantiated by the SensLogon class. The SensLogon class keeps a static reference to the only instance, thus preventing it from being garbage collected.

Once we have a class that will get the events raised by the SENS Events system, we need to add events to the SensLogon class so that it can raise them. This is the trickiest part. COM interoperability is slow, so if no classes within an application are registered to events, we do not want COM to send them. For efficiency, we need a system that registers with COM when a class first registers with SensLogon and removes the COM registration when no classes are left.

The typical way of declaring an event in a C# class is inadequate because we cannot perform any special processing when a delegate is attached to an event. Thankfully, C# provides a way of creating custom event registration code: write an event as though you are writing a property, but use the add and remove keywords instead of get and set. The add keyword is for when a delegate is attached to the event, and the remove keyword is for when a delegate is detached from the event. This is illustrated at the bottom of Listing 5. It takes more work to attach and detach events, but because of the RegisterEvent and UnregisterEvent routines, it is a lot simpler than it could have been.

Also, to actually raise the events, we have protected static OnEventName methods, which are used to raise the events defined (having a protected method that raises an event is standard procedure for all events in the .NET Framework). The appropriate method is called by the SensLogonInterop class when an event comes in, thereby causing the associated event to be raised, if anyone is registered for that event.

Bringing It All Together
Now we get back to the initial problem: getting an event whenever someone locks or unlocks their screen. In the DotNetSENS Console project, add a reference to the ManagedSENS project. Then, the code should change to the code in Listing 6. This is very similar to the code in Listing 1, but it uses our new .NET class for catching the SENS event. From start to finish, these are the steps to catch the screen lock and screen unlock events.

1. The application starts up, and the DisplayLock event has a delegate attached to it
2. This attachment causes the SensLogon class to create an instance of the SensLogonInterop class
3. The SensLogonInterop class registers for the ISensLogon events with the COM+ Event System
4. The application then attaches to the DisplayUnlock event, which does nothing other than remember the delegate to call
5. The application then waits for the user to hit the enter key before quitting
6. Meanwhile, when the screen is locked, SENS sends the event out to the COM+ Event System
7. The COM+ Event system passes the event to the instance of SensLogonInterop by calling DisplayLock
8. When DisplayLock is called, it calls SensLogon.OnDisplayLock
9. OnDisplayLock then raises the DisplayLock event
10. The application catches the event, and writes out to the console my login name
11. When the screen is unlocked, steps similar to steps 6 through 10 are run

SENS Events in .NET 2.0
In .NET 2.0, Microsoft provides some events that look similar to SENS events (http://winfx.msdn.microsoft.com/library/ en-us/cpref/winfx/ref/microsoft.win32.asp?frame=true). These events are actually provided through messages sent to a Window's main message handler, the WndProc method. Through P/Invoke, you can register for these messages, and receive them in .NET 1.1 or you can attach to the events provided in .NET 2.0 (check out the documentation in MSDN about WTSRegisterSessionNotification for information on these messages). Unfortunately, no messages are sent when the screen saver starts and stops. Also, these messages do not provide any information about the account that caused them.