What you have said below is mostly true for the current UI class design, which I think should be abandoned. You are concerned about issues that shouldn't even come up, but are due to a less than optimum overall class design. The pesky threading issues arise when you are directly changing controls in one form based on actions in another. I hope you don't perpetuate this design.
The actions in the settings form should cause changes to a model object. And if you are using vs2005/net2.0 you can use data binding to arbitrary objects in the main form. Threading issues mostly go away or are easily solved. It's the MVC/MVP pattern that is the most helpful in this case. The Invoke wrapper on the controls is not required at all with data binding or the observer pattern. It's so cludgy I shudder. I apolgize in advance for any mistakes, and for any perceived rudeness, I have the highest regard for your work. ================== Actually, based on my research, they didn't fix this in .NET v2.0. You still have to do the recommended workarounds they suggest for .NET v1.1 when accessing GUI controls from a thread other than the one that created them in order to avoid random crashing. I understand why they wouldn't want to default them to be thread safe due to performance concerns (checking thread IDs can be slow). But there's no reason not to have this as a property option on each control. This would keep the developer from having to wrap each and every control into a thread safe wrapper. I haven't seen any mention of whether they have addressed this in .NET v3.0. Eric Wachsmann FlexRadio Systems > -----Original Message----- > From: Jim Lux [mailto:James.P.Lux at jpl.nasa.gov] > Sent: Tuesday, October 10, 2006 4:36 PM > To: Eric Wachsmann > Cc: 'Flex-radio Reflector' > Subject: RE: [Flexradio] Vs2003 vis a vis Vista > > At 02:03 PM 10/10/2006, Eric Wachsmann wrote: > >Those are in our source. Look in the root\trunk\Source\Console\Invoke\ > >folder for the definitions. These are basically wrappers on the existing > >GUI controls that incorporate Thread Safe mechanisms. Why this is not a > >defined property on the controls from MS, I'll never understand. It > would > >save many programmers some headaches. > > Tnx > > In most of the .net 2.0 stuff, things are already thread safe. A > better threading model is one of the big advantages of VS2005, tec. > > Jim > _______________________________________________ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
