So as some of you know, in my previous life I used to be a server side developer that worked mostly on middle tier work. That meant that mostly I dealt with applications that would run on web servers and loved the work. For the last year though I have made a transition to Windows Forms Application Development. This has lead to me learning a bunch of new concepts on how an application should work.
Recently in my endless quest to be a good UI developer, I decided to get Chris Sells' Windows Forms 2.0 Programming book. I was skimming through a section dealing with presenting dialogs and came across a gem of knowledge in a chapter about dialogs. Chapter 3 called "Dialogs" started out a bit boring, but at the end of the chapter, the conversation goes from dialog results to using some of the new providers in the .NET framework. As I was reading, I was trying to find the down side to using them. On the application I work on we still do validation the old way and in past conversations validators were spoken of in negative terms. To me from the outside they look cool. You basically put an error provider on a page and this would provide the code necessary to activate the errors on the native windows controls. All (I think) controls have a 'CausesValidation' property. This will control if a control's 'Validating' and 'Validated' events get fired.
For each control that you want to have validation, you can just register an event handler to handle the validating even. You would then put your validation code in the event handler. The event handler would call into the ErrorProvider.SetError(sender, error) method where error is a message that will show up as a tool tip next to the offending code. Ok cool, but for some of us, we may not want to do this because your UI would have necessary business logic to do the validation. This is not ideal. So what is the solution? Well, you could have your controller manage mapping validators to the UI layer. When a controller is setting up the view and mapping to events, it could contain delegates that would be fired as a response to a validating request.
The validation abilities that are built in are cool. There is a way to invoke validation on entire sections of the UI with the ability to call the form's ValidateChildren method or a container control's Validate method.
So then after the ErrorProvider lesson, I learned about an extender property called the ToolTip component. It allows you to drop it onto a design surface to give all controls 'extended' properties. In the case of the tool tip extender it allows you to set 'Tool Tips'. Chris goes on to talk about how to use the two of them together and then ties it to a basic lesson on F1 help integration.
All in all chapter 3 was a fulfilling read. I took away a few things to make the app I work on better and that is never a bad thing.
--Rich