On 10/11/06, Paul Shaffer <[EMAIL PROTECTED]> wrote: > 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. > >
I agree with the above assessment/suggestions. There is usually a reason why certain mechanisms are not added to or are dropped from .NET - most of the time it is because there is a better way to handle those things. The biggest problem that the current console code has is that it was approached as if someone were writing the whole project in C and not C# (or any object oriented language). A lot of the perceived need for threading goes away when you get away from straight line procedural code. 73 de Phil N8VB _______________________________________________ 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
