>>
>>If I understand you correctly, I don't see a need for some sort of parent/child relation. I see the customer table more as a lookup in your scenario. You might use a similar approach as the cifcombo: in the case you show existing records, the customer name is displayed in the combo. For a new record, let your users type in the name, and if it is not found, fire an addform. You might want to place a push button aside of the combo that would trigger a form to display detailed customer info, and allow for changes there.
>>
>
> Hmm..The way I had planned it, I've got a button next to the customers name that can be used to bring up a find form (there are too many customers for a combo). So far, so good. Then I could place code in something like Valid() to call my customerobj to check if it already existed.
>
> Should I leave estimateobj as the primary business object? Bind the customer fields directly to a view in the estimateobj data env. Where would I force a save of this info into my customerobj? PreSaveHook() of estimateobj?
>
>Thanks,
Paul,
I understand your reason for dropping out the combo idea. Then we might perhaps need two forms. One to
the information of an existing customer, and the other one to one customer. This one might just be another bizobjmaintform, with parameters that they could fill in to make their search.
If they find nothing, they just add a new record. This form should return the customerId (or a blank). In this implementation, the customerobj has an indepedant life, no special relationship. The only check needed in some sort of BeforeSave() hook is to be sure the customerid is not left empty.
José
