> Try the following. I have not used it but I only read about it earlier
> today. The idea sounds good:
[quoted text clipped - 13 lines]
>>
>> Graham
I fully agree with your assessment about using InvokeRequired in the
control itself to make the control threadsafe. I personally fail to
understand why this is not so to beginwith in Microsoft controls which
are essentially nothing more than wrappers for controls in
Comctl32.dll.
I first saw this in Chris Sells's book on WinForms and have used it
since then. This makes life easy for the clients as they dont have to
worry about providing delegates each time they call controls from the
worker thread. In addition, keeping the thread logic within a control
makes it easy to remove/add worker thread.
--------
Ajay Kalra
ajaykalra@yahoo.com
> Thanks Ajay,
>
[quoted text clipped - 51 lines]
> >>
> >> Graham
Gravy - 01 Dec 2004 20:43 GMT
Agreed Ajay, but the only problem I have found in doing this is any public
methods on the base class to my user control are not thread safe and unless
I provide new implementations of them (for example Focus(), Enabled, Visable
etc) the client experience is inconsistant. This was one reason I asked the
newsgroup earlier if anyone knows of a wrapper class sfor Form, Control and
or UserControl. I don't think anyone has done this though.
Graham
>I fully agree with your assessment about using InvokeRequired in the
> control itself to make the control threadsafe. I personally fail to
[quoted text clipped - 75 lines]
>> >>
>> >> Graham
Dmitriy Zaslavskiy - 02 Dec 2004 03:29 GMT
Few points:
1. Its really slow (switching thread and creating expensive objects such as
mutex)
2. If you want to do a bunch of updates you would want to switch manually
3. This one is probably the biggest: Invoke implies synchronization which
can lead to deadlocks.
4. Because of 3 you might want to do BeginInvoke but it changes things a
lot.
Therefore regardless of choice made by Control designers someone would not
be happy.
5. True that most controls (but not all) are wrappers of user32 and comctl32
controls but those are also not thread safe.
The truth is user32 in general is not very thread safe. There are APIs which
have thread affinity for example DestroyWindow
Gravy why does this tool raise any questions you didn't have before?
I wrote the tool but it's not really production quality so if you have
questions let me know.
>I fully agree with your assessment about using InvokeRequired in the
> control itself to make the control threadsafe. I personally fail to
[quoted text clipped - 75 lines]
>> >>
>> >> Graham
Gravy - 03 Dec 2004 01:37 GMT
Dmitriy,
the thing that got me thinking about all this thread safe control stuff
again was highlighted by GThreadCop. I was getting a lot of vialotion in one
particular method. To cut a long storey short the violations were happening
because my controller class (non UI) was dealing with interfaces that the UI
forms / controls implement. Now, in order for my controller to switch to the
UI thread I had to add a property on my interface with returned the
underlying control, but in order to get the underlying control I had to call
in to a UI control from a worker thread (the controller). Anyway after using
the GThreadCop a bit more I see that I can ignore this violation anyway.
BTW, thanks for the points below. I thought there had to be some reason for
a windows form or control not doing this.
> Few points:
> 1. Its really slow (switching thread and creating expensive objects such
[quoted text clipped - 95 lines]
>>> >>
>>> >> Graham
Dmitriy Zaslavskiy - 03 Dec 2004 03:14 GMT
Check out the comments on
http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=3cba64b4-
3765-49ba-8a05-11d247195e65
on how to tell GThreadCop to ignore known OK functions
> Dmitriy,
>
[quoted text clipped - 115 lines]
>>>> >>
>>>> >> Graham