Hi Kevin,

The basic rule I would recommend is to keep encapsulation within the form. Anything that relates to the form or controls on the form should be done on the form itself. I would not call a different class to handle this. However, anything that is generic and will be used on more than one form and can be UI independent should be done in the business object. For example, you state that you need an ADO.NET DataSet to bind to a DataGrid. I would have the creation of the DataSet be done by the business object as a method. Your form would call the business object's method and then use the DataSet to set the controls contained in the form.

>Hi, Cathi...
>
>Thanks for your response. I understand what you're getting at, but am still a bit confused, perhaps because I'm trying to fit the recommendation with our general requirements.
>
>Sometimes it's not just passing the contents of one control, it's passing the contents of a set of controls. Other times, it's a matter of setting controls. Being able to pass the form class as an object seems like the 'easy' way, but I understand that UI changes will mean changes in other places as well. So I hear what you're saying, but I'm still a bit confused. Here are some of the things I'm trying to do:
>
>1) Loading/populating controls [like checkboxlists, listboxes, mover forms, etc.] based on client configuration tables that are brought back as ADO.NET datasets. While a bit oversimplified, it's like one big mass 'ADDITEM' process into a bunch of controls.
>
>2) Polling the selected values of these controls [i.e. save selections to an XML file, and then restore those selections when the user exits-reenters the software]
>
>3) Preparing a grid [we set columns and tablestyles programmatically, based on different run-time conditions]
>
>4) Setting widths of controls based on screen resolution [we don't allow resizing, so we set widths of certain controls based on the user's resolution]
>
>5) Building a giant WHERE clause based on a QBE screen where users make selections into listboxes, radio buttons, etc.
>
>6) Reading contents of control[s] for local validations.
>
>Part of the problem is that I don't have a strong feel for what kind of code should be 'allowed' in the UI. Are things like setting control widths, doing ADDITEMS, etc., appropriate in the UI, or should they be in a 'rules' class as well? Same goes for things like setting up grids. It's difficult to imagine that the UI shouldn't be able to contain *any* of this.
>
>Are there code samples on Web Sites that illustrate any of this? I think if I saw a few examples on best practices, I'd understand. Unfortunately, I haven't really been able to find any.
>
>Sorry if I'm sounding dense on this.
>
>Thanks,
>Kevin