Thread marshalling - changing a control's thread affinity

[Martin Maat]

Hi,

I have a notification window that uses its own thread to animate itself. It
also fires events to the main UI.

The trouble (getting it thread safe) is not with the events fired, I can
marhall them just fine using (Begin)Invoke. It is with the internal thread
which updates the form itself. The form however was not created by this
animation thread which is only created later, after construction of the
form. It was created by the main UI thread.

In framework 1.1 there was no problem and with framework 2.0 I can just set
Control.CheckForIllegalCrossThreadCalls to false and all is fine again. I
tried to be a good boy though, just to be sure there will be no surprises,
to make it thread-safe.

Marshalling every call to the form's message loop using (Begin)Invoke is
pointless, it defeats the purpose of having a separate animation thread.
Animation got jerky, stalling the main UI thread. So I basically wanted the
form to be created on the animation thread itself.

I may be stupid but it took me a couple of days to come to terms with the
fact that this is impossible. It is like lifting yourself up by your shoe
laces.

Now I was thinking... can I not marshall the control to another thread
instead of marshalling each call to the appropriate thread?

Like a control is created on thread A. Then, when in thread B, I want to
mess with it. Then I want to be able to tell Windows "Hey, this control
which is owned by thread A, please consider it owned by thread B from now
on". And then call its methods from thread B.

This would be so much more convenient in my scenario. Can it be done?

Regards, Martin.

 

[Dmytro Lapshyn [MVP]]

Hey Martin,

Having two UI threads (even if one of them is used for animation) is
generally a bad idea. What prevents you from running the animation on the
main UI thread? If it's some heavy-duty processing that happens on the UI
thread, you should rather "offload" that processing to worker threads.

 

[Martin Maat]

Having two UI threads (even if one of them is used for animation) is
generally a bad idea. What prevents you from running the animation on
the main UI thread?

The resulting performance does. The application is an RSS reader. You may be
browsing articles using the main UI (thread) when the notification pane
shifts (or fades) in. This is an expensive operation that I do not want to
be performed on the main UI thread because it totally kills responsivenes
for the time the animation takes (I tried it, it sucks). Currently animation
is performed on a separate worker thread and everything performes really
smooth. It is only for the warnings I get about how this COULD one day
result in error because there is no guarantee Windows will not interfere at
an inconvenient moment, that I want to do it in a way that would be
absolutely safe. I never had any issues with it so far.

So if the CLR / Windows.Forms people urge me to do it "right" it would be
nice if they could also tell me what right is for my scenario which seems a
pretty common one. And performing animation on the main UI thread is not
good enough.

If it's some heavy-duty processing that happens
on the UI thread, you should rather "offload" that processing to
worker threads.

That is exactly the case, hence my question.

Martin.

 

[Mattias Sjögren]

So I basically wanted the

form to be created on the animation thread itself.

I may be stupid but it took me a couple of days to come to terms with the
fact that this is impossible. It is like lifting yourself up by your shoe
laces.

That sounds like the way to go. Why do you say it's impossible? First
create the thread, then instantiate the form from there.


Mattias