>Hi Bob,
>
>>I never use a DE on a form or a report. The downside is I don't have a picklist of fields to choose form when designing.
>
>This is not a downside. A different mindframe is required though. When designing controls for a business object, you don't have to start within the business object. Start from a form, add the view to the data environment, change the alias to v_YourView and drop the controls on the form. Do your settings and copy them. Now add them to the business object.


It's not that big a deal really, although GPF's because of invalid names in a controlsource are a problem.

One important thing though, I don't put ANY controls in a business object. I'm assuming you mean a cbizobj. I use it strictly to handle the processing requirements of the view that is the primary alias. This way, any form that has any business reason for updating a view will have the appropriate business object on the form. This way, the business object isn't tied to an implementation.

I think business objects would be better as custom objects (with object references for the data environment, data behaviour etc). I don't think they should contain controls. I did that in my first codebook project but I think it is better to let the business object do what it should only do : manage the business data.