This post originated from an RSS feed registered with .NET Buzz
by Doug Thews.
Original Post: Error Provider Opinions
Feed Title: IlluminatiLand
Feed URL: http://apps5.oingo.com/apps/domainpark/domainpark.cgi?client=netw8744&s=JETBRAINS.COM
Feed Description: A technology blog for people enlightened enough to think for themselves
Am I the only one who doesn't like the way that the ErrorProvider is designed? IMHO, the ErrorProvider should be tied to a control (or possibly part of a custom control class, that can be overridden, when need be). But, this assignment to a initial control, then physical placement somewhere on the form (which should be standardized as part of the control that it's assigned to), then once again invoking the provider, only to have to tell it the control again seems very redundant.
What I'd like to see is something similar to the way ASP.NET does it - just a more robust. Each instantiated control can implement an ErrorProvider interface. The control maker gives some control, but the mundane details should be hidden. You should be able to bubble up your own events that will ultimately return a Yes/No answer as to whether the field has en error. And no more of this need to keep passing the control around. The Error Provider should know who it is assigned to.
I'm sure there are a wide range of opinions on this. Please speak your mind.
Previous Topic
