FF3, TabOrder, ZOrder, Control Creation Order (Proposal)

[Paul Squires]

Hi Everyone,

One of the big changes in FF3 was a new algorithm that I implemented to output the controls code during code generation. As we've seen, in pre-3.05 versions, the zorder approach caused quite a few problems with GPF's and such.

Roger Garstang sent me an interesting project that highlights another problem with FF3's approach of using the WS_TABSTOP style as a primary factor in the order of control creation. Basically, his project uses frames and labels with accelerator letters enabled so pressing Alt+P on a label with text "&Position" would set the focus to a textbox right next to the label. The "problem" is that you need to have the label code generated immediately before the textbox and unless you set the label's WS_TABSTOP to true then there is no easy way to ensure that the label gets correctly generated immediately before the textbox. The additional problem of setting the label's WS_TABSTOP is that now the focus gets lost if the user starts TAB'ing from control to control (once it hits the label, the user won't see a focus rectangle).

In FF2, all controls would show in the Tab Order list in the FF Workspace. You could easily arrange the controls in the sequence that you wanted. In FF3, I thought it would be better to only allow the controls with WS_TABSTOP to be manipulated. In hindsight, i am second guessing that choice.

I am proposing that the Tab Order list be reverted back to the FF2 approach. However, I would want to modify the list display to be able to quickly visually show which controls have the WS_TABSTOP style set (maybe an icon preceeding the text in the list?).

The only other issue would be the "Send to front" and "Send to back" formatting options. My initial thoughts are to simply move the control to the first or last position in the code generation depending on which option is chosen.

Well, that's it. Please let me know if you agree, disagree, or could care less. I will hold off making any changes for a little while until we flush this out a bit more.

[Martin Francom]

Sounds fine with me.  Maybe a prerelease 06 beta would be a good idea.  Then the more adventurous amoung us can see if we get any unexpected behavior.

[Robert Rioja]

I don't mind beta testing anything you do.

Robert

[John Montenigro]

I have about 6 small utility programs that I mostly built under FF2, and that I've migrated succesfully to FF3. In these apps, the forms and controls have all been stable, and I've only been coding internal routines.

So I have not been hitting the problems that I've been reading about, and in fact I've been a bit reluctant to make changes until some of these issues have been rectified.

Thus my perspective is limited. But that's never stopped me from offering my thoughts, so here I go...

In FF2, I found that my needs were mostly met with the combination of making labels visible and using the Tab Order section of the Workspace. I had some difficulties, and was shown some workarounds that I can put into code.

But more importantly, perhaps, is my observation that I need FF to give me the means to create the user experience as I need it to flow.

So, I'm in favor of whatever makes that possible for me. (If needed, I'm sure we can create a list of the specifics that defines that.)

I'm willing to help in testing, too.

[Elias Montoya]

FF2 approach will be fine. 

[Mark Strickland]

I like the FF2 proposal.  An indicator of which controls had tabstops would be VERY helpful.  You could also add a checkbox that would hide/show controls without tabstops to "unclutter" the list.

[Roger Garstang]

Yeah, I think I mentioned this in another thread, but something even as simple as WS_TABSTOP controls being Black and others without it being a gray color or something.  Defaults for labels and frames having WS_TABSTOP off too.

So, in FF...what is the difference between Tab Order and Z-Order?  From what I've seen in the CodeGen files the tab order is the order the controls are created...which should also be Z-Order. Right?  When I think Z-Order and Move to Front/Back I usually think of it in more of a Vector Drawing/Object sense.  To me Z-Order would be a FF specific thing for how controls are able to be clicked in the IDE when you have a control on top of a Frame or something and click it then it is selected and not the frame, etc.  Although usually when I set my tab orders I set it Frame, then controls within a frame and labels then the textboxes/controls.  So, Z-Order even in my way of thinking could be controls higher in the list behind other controls which would match Tab Order since they would be created first and new controls placed on top of them.  So, unless you have tab order numbers visible so when we right click or select a menu option to Move Forward/Back/To Front/To Back and can see the orders in the IDE...I'd have all of the Move Options in the Tab Order Panel.  This would help with the arrow drawing issue when dragging in there too. (I never can tell where it is going to position with the arrow being slightly off and the further down you go the further it is off...especially all the way at the bottom)  Perhaps to indicate where the position is when dragging there it draws a line across between the list items or a selection bar that moves and inserts a blank line when dragging to let you know where it will go (Or actually moving the item in the list while dragging).

[Roger Garstang]

Not sure how a checkbox to hide non-tabstop controls would be used.  If hidden then when you position others how will you determine where you are moving?  It would need something like Excel's filter option.  Number each item by their tab order in the list and when hidden you would be missing numbers then in the list, so if you have 20 controls 1-20 and 5,8,10 are labels they would be the numbers missing.  Then if you drag control 20 to position 4 all the numbers would then shift, so now the hidden controls/labels would hide numbers 6,9,11.

[Mark Strickland]

I had not thought about moving with the non-tabstop controls off.  Good point.

Numbering them would help.  I suppose if I was moving them then the numbers would "remind" me that I might not be inserting them exactly where I would expect and I would likely turn on the hidden controls.

Hummmm .... how about if you could click on the column heading and sort numerically by tab order or by control name to find the misplaced one you wanted in a very long list.

Sorry ... is this called "Scope Creep"?   

[Marc van Cauwenberghe]

Would be fine if this could be solved in whatever way possible.
Beta testing would be OK. Hope that the IDE z-order problem also go away then.

Marc

[Paul Squires]

Hi Everyone,

I have finally had time to devote to this new feature. The TabOrder now displays ALL controls in the list regardless of whether the WS_TABSTOP is set or not. I have added a FireLink control to the TabOrder page that toggles between "Set WS_TABSTOP" and "Remove WS_TABSTOP". This allows you to set or remove that window style directly from the TabOrder page rather than having to go to the PropertyList page. Pretty convenient. 

These changes will be in v3.06.

[Roger Garstang]

Sounds cool.  What indicates the current control's state for Tab Stop or not?

Also, since it sounds like .06 is due out soon, did you toss in these too:
http://www.planetsquires.com/protect/forum/index.php?topic=2241.msg17610#msg17610
http://www.planetsquires.com/protect/forum/index.php?topic=2252.msg17656#msg17656

Couple easy fixes that might as well be tossed in to fix it all.  Can't wait to get this.  I have to send one final update to the project I sent you that has twice as many controls, and it even changed a little since I sent to you.  Customer failed to mention it wasn't two 16dot print heads side by side capable of 32dots, but two 16 dots about 2 feet apart, but still counting X/Y like they are together, so I have to send two text strings with the 2nd like Y of 17 = another print as Y = 1.