>Yes, as I posted a little after my previos post, you're right, though I would hesitate to call it Zorder, that had me confused. I think "Intra-Container Object Instantiation Order" (though rather long-winded) is the better description, Zorder seems an arbitrary and rather meaningless word, besides the fact there is a method called the same...
>
>But it does work exactly as you say...

Hi again,
I initially missed your other post, sorry :).
I think I agree with you on the naming, except for the fact that *all* propagating events(Init, Refresh, Destroy, ...) are processed in ZORDER order, perhaps "Event Processing Order" would be more to the point if not more succinct *g*.
I think "ZORDER" comes from the fact (as documented in Help, and both Hacker's Guides) that the "property" also controls the visual layering(think Z axis) of controls. I am quite sure that this is standard usage of "ZORDER" in other contexts.
The method by the same name allows the order of event processing/visual overlay to be changed at run time (approach with *extreme* caution).
Another reason to keep ZORDER (file under useless trivia), as seen under VFP5, a ZORDER property actually appears in one of the fields of the vcx, I think it was the Properties field under some conditions (I think addition of new object and use of "Bring to Front", "Send to Back" but don't quote me on that one).
Anyway, now that this has been clarified we can all go back to writing code that is independent of instantiation order *G*.

HTH,
Ned