I've seen a handful of people confused by this, so I think it should be explicitly stated. All three concepts are the same in REALbasic. When you set the control order of a control on a window, you are telling REALbasic what order to create the controls in. So if you have a PushButton (control order of 0) and an EditField (control order of 1), then the PushButton is made first, and the EditField is made second.
Z-ordering is the 3D ordering of controls -- it determines what's in front of another control or what's behind it. So in our previous example, if the PushButton and EditField overlapped, then the EditField would be in front of the PushButton for the part which overlaps. That's because the EditField is created second. Think of z-ordering like painting: items which are put on paper first can be drawn over by items put on the paper later. In programming, the paper is the window. What's being drawn are the controls.
Finally, tab ordering is the order in which hitting the tab key cycles through controls. At the OS level, this is generally determined by the order of control creation. So in our example, the first control to have focus would be the PushButton. Hitting tab brings you to the EditField.
So, as you can see, the control order directly affects the order of creating the controls. This in turn directly affects the way they're drawn and how tab ordering works.
Thanks, that confirms my understanding of what's going on.
Is there any point in asking
1) whether there are any plans to split tab order from z order
2) whether we will ever be able to change either or both at runtime
3) whether control order can be counted on to be the same as the order of the Window.Control Property array?
Aaron, it occurs to me you may be thinking "I just answered that".
Perhaps I should have asked specifically for the first two questions, when are you going to start interfering with the natural ordr of things?
@Steve -- We don't discuss future plans. ;-) I can't even speculate on #1 or #2 as to whether they're good ideas or plausible to implement.
As for #3, unless it's documented as such, I'd say you can't rely on it. I'm pretty sure there's no such promise.
@Steve: This idea may work. Create an array of integers with the same number of elements as your window's control count. Then loop through the window's control array/collection and assign the index of the control to your arrays element that matches the tab index of that control.
Sorta like this: myArray(Windows.Control(iIndex).TabIndex) = iIndex
I'm sure I've got the wrong names of the properties, but I hope that gets the general idea across.
@Scott If you can find the real name of the TabIndex property, it'll make my week ;}
I must have been in VB mode when I wrote that. I was *sure* I saw that in RB, but apparently not. Wonder in Aaron can offer any insight/hints?
Is there perhaps something exposed via autocomplete in the IDE?
@Scott -- There is no TabIndex in RB, that's the point to the discussion in the first place. ;-) TabIndex = Z-Order = Control Order in REALbasic.
And it should stay that way. Would it occasionally be useful to have TabIndex, ZOrder, and ControlOrder separate in RB? Sure. Would it be confusing as heck? You bet!
@Adam: It might be confusing to long time RB users to separate them but trying to explain the current system to new users is equally confusing.
Want to make it first in the tab order? Sure, just send it to the back.
I see Mike's happy it's going to stay the same:
http://forums.realsoftware.com/viewtopic.php?p=23940#23940
@Steve -- I think trying to explain the three as separate ideas will confuse users just as much. I'm not entirely convinced it's even NEEDED.
What, exactly, would you require all three concepts to be separate for?
@Aaron: It's mostly my personal prejudice that the Zorder and tab-order should be different, I've never found an excuse for a feedback request. The apps with overlapping, focussable controls don't appear a lot in real life and would violate guidelines anyway.
I still maintain that explaining the concepts of Zorder and tab-order separately to a noob is easier than explaining them as inter-related. This blog posting is the first clear explanation I've ever seen. However I accept it's not needed or even worth the programming effort and possible side-effects to split them up.
What I do think is worth the effort is to be able to change the order at runtime. In particular for cloned controls, where some fixed controls are on the window already, both Zorder and tab-order need to be settable.
If that means achieving both by re-arranging the control-order and calling Window.Refresh, I could live with that.
And wouldn't you like to be able to complete this article?
http://ramblings.aaronballman.com/?p=408
;-)
Changing the subject abit if i make an html viewer object over the top of something and tell it to go to www.whatever.com.
I run the code and as im scrolling thru the website all my buttons (that have a lower control order) show up thru the web browser/page!?
Is this a bug or am i doing somthing wrong?