>Kevin,
>
>Since I am using containers to populate the pages of the pageframe, I was thinking of adding something like a PostRequery method both the page frame and the container class. The pageframe method would call the PostRequery method for each page in the pageframe on which the container class had been instantiated. The pageframe PostRequery would be called from the primary business object PostRequery method. This way, the action is encapsulated within the page on which the control resides.
>
>Coments?
>
>Rex
>
>>Rex,
>>
>>>Where should that code go? In this case, I would only need to reqery the view once.>
>>
>>That depends on whether these views need to be requeried as the record pointer in the business object on page 1 is moved. If they only need to be requeried once, you can put it in the Init() of the container which will fire when the controls are added dynamically at run time.
>>
>>Regards,

What I have done is subclass the combobox (ccombocontrol) (I don't like contained controls) and add properties to accept a datanevironment and a behavior class.

New properties are cde (data environment), cdesc (field used for the display), and cid (field that has the key value to bind to).

For instance, to display region codes i set:
cde = RegionEnvironment
cdesc = regiondesc
cid = regionid

These are the only properties required to have the combo populate with data.
Now, this works fine with data in the combo that doesn't change, I can requery the combo to update it, but if the data changes after the form is loaded and I want automatic requeries, I would modify the baseclass to add a business object class (that includes the data environment) to the subclass of cComboBoxL.

The advantage to using the business object is that you can then set a reference to the parent biz obj and when that object gets requeried, it will requery the business object related to the combo box. there just needs to be a special call to the combobox's requery method to complete the update.

I have a kind of rule of thumb. One cursor to each business object, unless I know for sure any other 'supporting' cursors will never need to be requeried or updated. Codes that don't change, for instance. Any cursor that needs to be requeried or updated, gets its own business object on the form. Some forms have 10 or 12 business objects. The requeries work fine as long as the correct parent business object is set.

I really like my combo box subclass that contains its own data environment. I used to have the main business object open all the needed code tables etc. required for combo boxes. Now it is so simple to let the combo box handle its own data source and the main business object doesn't get cluttered with cursors that don't really belong to it.

I have a subclass control called cboProvince (Province/state codes). I drop it on a form, bind the control to the required field and the control opens the view it needs.