Thanks so much for the information Kevin. :o)

>Tracy,
>
>>In VFP, I validate in a custom method that is called from the validate or lostfocus of a control. The method could be called presave() and then perhaps a postsave() as well. In the presave() I would basically do what the business level should do. Other than subclassing controls and then dropping all of those subclasses on a form, what would be a good way to emulate that behavior in dotnet? Would an interface work or what about delagates? I'm trying to wrap my head around this and I may be thinking wrong to begin with.
>>
>>I have to save each field as I pass through the controls on the form. Form level saving is not an option in this case.
>>
>>The valid or lostfocus of the control now calls the presave() and if it passes, then the save is done (insert or update in sql server). In some cases, the business logic to determine whether or not the check passes and a save should be done, may need to be overridden. In addition to the actual saving (which I assume would be done via a call to the business object), where does the business logic go to do the check for the field validation? I think I've over confused myself in this whole process due to the validation at the field level...
>>
>>For example, if I want to process default behavior for 80% of the time in a control, but in 20% of the time I want to do something in addition to the default behavior or even not perform the default behavior, what then? Does it have to be done at the form control (UI) level using virtual and override, or can it be passed to the business level (hopefully a separate dll) somehow? What would go in the business level then? Would it be an interface? Or do I have a separate group of subclasses to maintain?
>
>Great questions...it boils down to an issue of division of responsibilities. You want the business layer to enforce business rules and you want the user interface to provide inform the user of the rule violations as well as provide appropriate indicators to show which UI control(s) content need to be corrected. An extra wrinkle is thrown in the mix when you need this to work for both Windows and Web front ends--in Windows Forms you would like the rules to fire when a user leaves the control. In the Web, you usually want them to fire when you hit the Submit button.
>
>We thought long and hard about this when we designed the MM .NET architecture. Our use of design patterns handles all of these scenarios and also works great with the new Windows Presentation Foundation.
>
>Basically, you should define a separate method for each rule you want to enforce. In MM .NET the business layer generates some of these basic rule validation methods for you. If you need them to fire for a particular user interface control, you can simply call that rule directly from the Validating event handler of that control (in the case of a TextBox). You can also choose to wait and check the rules when the user hits Save (sounds like you don't want this option in your app, but I'll explain it anyway <s>). In this case, MM .NET uses a chain-of-responsibility design pattern--the Save button calls a Save() method at the form level. The form-level save calls a Save() method on the business object. The business object (and any of its children/grandchildren) validate their rules. If any rules are broken, the form automatically displays an error icon next to the "offending" control(s) (and/or you can choose to display a messsage box containing the broken rules, or completely override MM
>.NET behavior to do something else--we describe how to do this in the Dev Guide). This works exactly the same way with WPF.
>
>This model also works well on the Web. When the user hits the Submit button MM .NET again uses a chain-of-responsibility design pattern. The Save button calls a Save() method on the form which calls a Save() method on the business object. Again, if any rules are broken, the form automatically displays an error icon next to each "offending" control.
>
>If you have any other questions, let me know!
>
>Best Regards,