>>Even better, it's best to code so that instantiation order (excluding outer containers like a form) does not matter, so the issue never comes up to begin with...
>
>You're probably right. But the scenarios I'm thinking of the rest of the the fields depend on the previous fields of a data-entry form, in which case the Tab and Inits would coincide.

The inter-dependent things may better be solved in a custom method of the form, which gets called from whenever necessary - form's activate, or control's refresh etc, depending on some condition (like - if your third combo's displayvalue is impty or something like that). This way you have several checkpoints which take care of your combos, and call the check'n'rebuild code, which checks if refresh is necessary.

Though this may sound like an overkill, I've found that such distinct methods serve me well, because soon I discover they should be called from some button's .click, some other textbox's refresh, from the rightclick menu and from a toolbar button. This gives me a little abstraction - the action is in the method, and triggering the action is attached to interface elements.