|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Thread marshalling - changing a control's thread affinityI 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. 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. Show quote "Martin Maat" <dummy@somewhere.invalid> wrote in message news:12insk0kgos9fb5@corp.supernews.com... > 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] wrote:
> Having two UI threads (even if one of them is used for animation) is The resulting performance does. The application is an RSS reader. You may be > generally a bad idea. What prevents you from running the animation on > the main UI thread? 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 That is exactly the case, hence my question.> on the UI thread, you should rather "offload" that processing to > worker threads. Martin. Show quote > "Martin Maat" <dummy@somewhere.invalid> wrote in message > news:12insk0kgos9fb5@corp.supernews.com... >> 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. >So I basically wanted the That sounds like the way to go. Why do you say it's impossible? First>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. create the thread, then instantiate the form from there. Mattias -- Mattias Sjögren [C# MVP] mattias @ mvps.org http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com Please reply only to the newsgroup.  |
|||||||||||||||||||||||
Other interesting topics