In trying to make a container as self-contained as possible, I'd like to open the table or tables it depends upon from within the container. In other words, I can drop it on a form and know that it will handle opening the tables it needs, instead of me having to open the tables used by the container in the form's Data Environment or opening them with a standard USE command. I can accomplish this, but it seems there's not a really elegant way. If I put the code for opening the tables in the Init of the container, the tables are not open when - for instance - a grid in the container is initialized, because the container's Init runs last. This causes the grid to not work as expected, though it throws no error. I can "fix" the grid by reassigning its RecordSource and the ControlSource of each column, but that's kludgey, to my mind. I can put the code to open the tables in the first object that is initialized (called in the order the objects were added to the container) and that works and the grid works as expected, if the object is instantiated before the grid. That seems kludgey, too. If the code to open the tables is in the Init of the grid, the grid is broken in that case, too (it won't refresh properly and display the table to which it's attached via the RecordSource property). Is there something I'm missing/forgetting here? There is no Load method for a container, so unlike a form, the code to open tables can't go there before any of the Inits are run. Frankly, for many years, I've just had such containers be not-so-self contained and just opened the necessary tables in whatever form I dropped the container on. I'm just trying to change that. Suggestions?

You can bind the grid in the form's Load() - turn databinding off or leave it unassigned in the designer then turn it on in Load() via code after the data sources are available.

It's a common pattern and I've used that in just about all of my applications when using business objects.

+++ Rick ---

Slight variation on Rick's response.

Set the form's BindControls to .f. in the designer. (As Rick says "turn databinding off")

Set this.BindControls = .t. in the form's init. The containers should all be initialized by then.

Ok, thanks to both of you for your answers. My point was to make the container completely self-contained, so using BindControls (something I know about - late and early binding, but really never use, so it gets forgotten about) breaks that. It's not terrible, but I could also add the tables I know the control will need in the Data Environment, which is, as mentioned, what I've really always done in the past. That solves the problem, too. And it's not of great importance. I was just trying to get a bit of improvement and see what I might be forgetting (like BindControls, obviously). Thanks again.

It's been a looooong time since I've built a FoxPro form...

I'm back in that world. LISA G is the old acronym for form event order.

Load Init Show Activate GotFocus

The data environment actually loads first. Its tables are available to all events, even Load().

Controls' init() run between the form's load() and init().

The thing is, for the most part, I pass parameters to my forms to describe the data I want them to show, and parameters get passed to Init(), which runs after Load().

So in my data entry form class, BindControls is to .f. at design time, and then set to .t. in the Init() if and only if the data is loaded properly based on the given parameters.

Thanks for the correction – another reminder not to to trust LLMs - even with something that should be so simple to verify as the form load order!

The thing is, for the most part, I pass parameters to my forms to describe the data I want them to show, and parameters get passed to Init(), which runs after Load().

Same here. Explicitly enabling after the data is loaded.

It works well with business objects when binding to objects, but when binding to tables it can often be tricky based on where and when they load.