>>>Ordering the way your objects are initialized by using tab order doesn't seem like a particularly good design technique...you're not recommending this, are you? :)
>>
>>It seems harmless... then you could create a new method and property: (nActualTabOrder) to set the tab order straight? Thats only if you need a special Initialization Order.
>
>Suppose another developer comes in (which occurs here) and makes a little change in an object or two, which alters tab order a little. Then builds & runs, and app crashes. New developer scratches head, etc...
>
>I'd prefer not to rely on something as "distant" as tab order for instantiation...either adding objects in desired order at runtime (probably best), or grouping init code into a container (which always fires later) seems a better philosophy...
>
>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.

But you're right.