I found several examples of how to Open and Set named Win32 events from within .NET code, but I also needed to catch Win32 events in my .NET application. That is, I wanted to do the equivalent of Win32's (C++)
WaitForMultipleObjects(), only in C#. I found no examples of this at Microsoft or on the Internet at large. All of the discussion of
WaitHandle and its derivatives,
ManualResetEvent only talked about multi-threading, not about inter-process communication. I was left unsure if it was possible (or at any rate whether it was simple, most things are possible with enough contortions and excursions into managed C++...); so I gave it a try. The result? It's remarkably simple ...
Our environment uses an executive process to control which other processes are running, and in what state they are running, e.g. as "primary" or "secondary", the latter being a warm back up that can be quickly switched over to primary should the first copy fail.
There are a handful of named events used to communicate between the executive and the worker processes, e.g. one event to tell them to transition from "secondary" to "primary" and another to tell them to shut down. This executive process uses well known environment variables to communicate the names of the events to its worker processes.
Historically, all these processes were Win32/MFC applications. Now some are becoming .NET apps, but it is most convenient to keep the same communications mechanism for the time being.
Using the code
Since the way to do this is so simple, I'll just show the code. The bold part was to just go ahead and assign the result from the Win32
OpenEvent() call to an
uint unEventPermissions = 2031619;
hEvent = OpenEvent(unEventPermissions,
if (IntPtr.Zero == hEvent)
AutoResetEvent arEvent = new AutoResetEvent(false);
arEvent.Handle = hEvent;
That's it! Now you can put this
AutoResetEvent object into a
WaitHandle array and use
WaitAny() (or use
WaitOne() directly on the
AutoResetEvent object or use
WaitAll(), etc.). Here's an example:
waitHandles = new WaitHandle;
waitHandles = arEvent;
bool bDone = false;
while ( !bDone )
Console.WriteLine("Top of while");
int waitResult = WaitHandle.WaitAny(waitHandles, 2000, false);
if (waitResult == WaitHandle.WaitTimeout)
Console.WriteLine(" WaitAny timed out.");
else if (0 == waitResult)
Console.WriteLine("0 == waitResult. Yippee !!!");
else if (1 == waitResult)
Console.WriteLine("1 == waitResult !!!");
If you download the demo project you'll actually get three solutions, one that is the MFC/Win32 (C++) application that is the source of the named event, another that is the .NET (C#) event sink application that opens and waits on the external event, and a third that is an MFC/Win32 (unmanaged C++) event sink application, it is the logical equivalent of the C# app. Be sure to run the
MfcEventSource program first, then start either of the other two.
Points of Interest
I guess that Microsoft can't be expected to provide examples and practical descriptions of all the available classes, but in this case the fact that
WaitHandle objects are only described for use with multi-threading but there is no mention of multi-process usage seems misleading. On the other hand, once you see what is available on these classes and boldly go ahead and use those features, it seems to work quite well. Any one knows any reason to fear otherwise? Thanks.