>>>Learned in VFP6 to avoid using "Bring to Front" and "Send to Back" on forms as it plays havoc with the TabOrder of controls on a form. The ZOrder property values implicitly cause some "shuffling" of the controls on the form, which then could affect the TabOrder (and the "shuffling" could occur each time you load and save the form). The "fix" was to open the SCX/SCT as a table and remove all the ZOrder directives in the Properties column, then edit the form and cut/paste the controls to proper z-order.
>>
>>Toolbar does not use TabOrder - no item on a Toolbar could be Activated or follow TAB. Wizzard is disabled.
>>
>>ZORDER on design time defines:
>>- order of creating the PEM's (lowest ZORDER first) and destroying in reverse order.
>>- this is important for Dataenvironment, they will be opend in that order too
>>- by that, lowest ZORDER will be painted first.
>>- the order of records in VCS / SCX or PEMS added to the class / form.
>>
>>At least on VFP 9, I see no problem. In case of, one must set TABORDER again.
>>It is odd while changing TABORDER with the property sheet and create holes in the order - but somehow the poor prog must decide.
>
>The problem was that on occasion (at least in VFP6) that the "side-effect" (aside from jumbling of the TabOrder) would occasionally result in strange behaviors. This problem became especially apparent if you've got classlibs with form classes. As stated previously, I would have to open up the SCX/SCT (and sometimes VCX/VCT) and look at the Properties column and edit the memo field directly to remove the ZOrder and TabOrder values. On those occasions where I was getting unpredictable orderings, I usually ended up seeing identical ZOrder values (which I presume was part of the issue -- it was a "toss-up" on which way these identical values would be processed upon load and processed upon save of the form or class).

Never seen this. But it was VFP6 - and good to know. Sometimes VFP is odd. And I use scx rarely.