Mark Ingram wrote:
> "The CLR has been unable to transition from COM context 0x1b0f58 to
> COM context 0x1b10c8 for 60 seconds. The thread that owns the
> destination context/apartment is most likely either doing a non
> pumping wait or processing a very long running operation without
> pumping Windows messages. This situation generally has a negative
> performance impact and may even lead to the application becoming non
> responsive or memory usage accumulating continually over time. To
> avoid this problem, all single threaded apartment (STA) threads
> should use pumping wait primitives (such as CoWaitForMultipleHandles)
> and routinely pump messages during long running operations."
>
> So, in my C# loop (reading in a bunch of images) - how do I pump
> windows messages so that my application responds?

"Mark Ingram" <no.one@nowhere.com> wrote in message
news:OwWmWA9EHHA.3776@TK2MSFTNGP02.phx.gbl...
> "The CLR has been unable to transition from COM context 0x1b0f58 to COM
> context 0x1b10c8 for 60 seconds. The thread that owns the destination
> context/apartment is most likely either doing a non pumping wait or
> processing a very long running operation without pumping Windows messages.
> This situation generally has a negative performance impact and may even
> lead to the application becoming non responsive or memory usage
> accumulating continually over time. To avoid this problem, all single
> threaded apartment (STA) threads should use pumping wait primitives (such
> as CoWaitForMultipleHandles) and routinely pump messages during long
> running operations."
>
> So, in my C# loop (reading in a bunch of images) - how do I pump windows
> messages so that my application responds?

Carl Daniel [VC++ MVP] wrote:
>
> The crude way (that lots of people will probably jump on and say "don't do
> that") is to call Application.DoEvents every now and then while you're
> reading files (e.g. once per file).
>
> The right way is to move your lengthy processing to a worker thread. Use
> async delegates, the thread pool, the new BackgroundWorker (2.0) class, or
> the System.Threading API directly. Be aware that once you move processing
> to a worker thread, you need to marshall all UI access into the correct
> thread using Control.{Begin}Invoke. It's not allowed under Winforms 2.0 for
> a thread other than the owning thread to touch any GUI compoent. (It was
> allowed in 1.1 and before, but there was no guarantee that it would work,
> and it's prone to deadlocks. This is a core Windows limitation, not
> anything specific to Winforms).
>
> -cd
>
>