Friday, January 27, 2006

Using Event to Intercept Message across process

the CF is paired down due to memory constraints, and a lot of functionality was lopped off because a workaround was typically available. But when dealing with multithreaded code, waiting with a timeout is a fundamental operation.

There is a great class to let you FireEvent between different process and trap them within a c# application. Visit Trey Brain blog at http://bytemellc.com/dotText/trey/category/6.aspx He write his own, properly functioning ManualResetEvent. As describe by MSDN the required api functions: CreateEvent ( creates the event ), SetEvent ( sets the event to signaled ), ResetEvent ( resets the event back to unsignaled ), WaitForSingleObject ( waits for an event to become signaled, with the ability to return after a timeout period ), and CloseHandle ( kills the event ).
Unfortunately it is not possible to wait for multiple object using win32 p/invoke so the cient applciation will have to create a listener thread for each event and use waitforsingle object.
So this class that he wrote provide some p/invoke code, and it worked fine on any Windows Mobile 5 phone running compact framework 2. Autoreset event didn't work properly. After some research ( dumpbin of the exports for coredll.dll ), it turns out that coredll.dll does not export the SetEvent, ResetEvent, or PulseEvent api's. Rather there's a new function called EventModify that takes an event handle, and an operation flag ( Set, Reset, or Pulse ). So he modified the code to use the EventModify api instead of the Set and Reset macros.
And it works great. By doing this you can set event across process. The only issue to follow would be to use WaitForMultiple Object within one thread on the listener C# client instead of using one thread per event.

--
Thomas

No comments: