If you're in an STA, then the WaitHandle class's WaitOne and WaitAny methods will pump messages for you while they block.
It'll actually use CoWaitForMultipleHandles under the covers. Of course there's a horrible flaw in both CoWaitForMultipleHandles and MsgWaitforMultipleObjectsEx: if you do a 'wait all' and there's a message pump involved, it'll only return when all the handles are signaled *and* you've got at least one message waiting for you in the call. This is pretty useless, because the semantics most developers actually want is "Wait until all these handles are signaled, but please let me pump messages while I wait." Because Win32 is unable to deliver the semantics you might actually want, WaitHandle.WaitAll will actually throw an exception if you call it from an STA. But WaitOne and WaitAny will both pump messages if you're on an STA. -- Ian Griffiths -----Original Message----- From: Curt Hagenlocher Sent: 31 July 2006 17:59 To: [email protected] Subject: [ADVANCED-DOTNET] MsgWaitForMultipleObjectsEx I'm trying to do something that (I think) I understand pretty well in the unmanaged world, but am not sure how to approach from inside the CLR. I have a server application to which I want to add support for a particular single-threaded reporting library written using COM. Requests to the server application may end up generating one or more requests to this reporting library. I'm pretty sure that I want to create a new [STA] thread to "own" the COM object and listen for requests from other parts of the application on an internal queue. But don't know I can ensure that messages are pumped while I'm waiting on the queue -- and I know from previous experience that this library requires a working message pump. In an unmanaged app, I'd be using MsgWaitForMultipleObjectsEx. What's the correct approach in the managed world? =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
