fguihen Posted November 22, 2005 Posted November 22, 2005 my usual validation technique is to use an if statement eg if(textbox1.text =="") { label1.text= "you must enter a username"; } this is fine for a small form, but i have a form with many controls to be validated and that seems a very crude way to validate. what is the "textbook" expert way of validating controls like text boxes , check boxes, raido buttons... Quote
*Experts* Nerseus Posted November 22, 2005 *Experts* Posted November 22, 2005 There is no "standard" method of validation as you yourself pointed out. For smaller forms/applications you may do just fine with checking a few controls and popping up a message box or changing a label caption. I'd also suggest looking at the ErrorProvider, which can place an icon next to the error'd field and creates a tooltip to explain the error. This is a bit easier than using a label to display the message as it allows you to check and display multiple problems (better for the user, harder for a programmer). My current project uses DataBinding to DataSets. All validation is done against the DataSet, not against controls, so that we can provide Web UIs as well as Windows UIs. We use XSL files that have tests written in XPath. The DataSet, as an XmlDocument, is transformed by the XSL to determine what's valid or not and display a report of the failed tests (produced by the XSL transform). In our case, we are writing XPath that would produce a "hit" when something fails. We happen to have the transform produce another DataSet of errors that can be used for a visual report as well as driving an ErrorProvider (for Windows) to indicate the bad fields. The error report can be used to jump to a control that has a problem by analyzing the error and the binding on the UI. There are two samples of validation, one very easy and one very complex. I've read how others have put all business rules right in their objects. In that scenario, the UI code (presumably Windows for you) would only interact with an object. The object would provide a means to validate it's current state and would have to provide the UI with a way of displaying what's wrong. In that scenario, the object handles all of the tests using whatever it has available. Meaning, if the object simply has a private field named lastName, your code would look much the same but check the private field rather than a UI textbox. This concept, among others, is discussed in the book Expert C# Business Objects, (also available for VB.NET). -ner Quote "I want to stand as close to the edge as I can without going over. Out on the edge you see all the kinds of things you can't see from the center." - Kurt Vonnegut
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.