>>However, the instantiation order does seem to be related to the ZOrder, however unrelated those two things seem to be.
>
>Actually, those two being related together does make a lot of sense. In looking at the resultant .SCX, the physical order of those objects is changed in the file when you change the ZOrder in the designer.

Quite so. I made a thorough study of this a few years back. The problem (which has never been explained much in Help) is that the designer has a Z-order "limit" of 2 objects for ordering (last time I checked anyway, about vfp5 or 6). Any more design objects, and the designer can't handle it. A way around this is to get a blank form, cut & paste all the objects you want to order, and add them back, one-by-one or two-by-two, doing a Save in between each time in the stacking order you want (added backwards, of course, from bottom to top, or first instantiation to last). This will get you the (or did a few versions back, probably still does) the instantiation and runtime order you want.

Not to contradict what you guys have said about not relying on instantiation order, I fully agree...but sometimes it's just a visual stacking effect you want, and not the code instantiation order that matters, so the above can be useful occasionally.