Tab order in .05

[Roger Garstang]

Still some minor glitches I think.  Appears to mostly be with Frames, but possibly other controls not in Tab List.  Using some Up/Down controls, and they like to buddy with the frames...which aren't in the Tab Order List.  I had to set them to TabStops so I can move them.  When changing properties like Window Styles and such and closing out it is still beeping too which was reported once already, is this normal?  Also some random issues in drag selecting controls...seems to do it when I drag the selection square from bottom up, especially when top of selection rectangle is at the very top of the form- Rectangle stays on screen when I let up off mouse and nothing is selected.

[Roger Garstang]

Marking them as TabStops also makes it stop at each...even labels.  FF2 didn't do this.  I need my labels by the controls, but not TabStops.  I think we need to go back to showing all in the Tab Order List to adjust, so you don't have to set the TabStop style to see them there.

[Roger Garstang]

This problem is proving to be a pain...got them all in the order I want with Tabstop style on, but then it stops at everything and not just the non-label/frame controls.  I turn off Tabstop Styles for the labels and frames and it doesn't keep their order so Alt+Underlined Letter of label/frame doesn't work and UpDn controls auto-buddy wrong.  If I turn the tabstop back on I see the labels/frames moved all over the place.  Updated my post in the UpDown Control thread as to what I found with the UpDn behavior too where the controls aren't placed the same as FF2.

[Paul Squires]

Hi Roger,

I haven't looked into this yet..... I will investigate tomorrow to see if a convenient solution can be reached. It may mean going back somewhat to the FF2 way of doing things. FF3 uses a combination of tabindex and zorder when generating the list of controls. Another approach you may take could be to manually create an accelerator table and set the SetFocus to the required control via code.

[Roger Garstang]

I think what I may end up doing if I get the final version done before FF changes is compile it the way it keeps them in order, then change the generated source to remove the %WS_TABSTOP Styles off the Labels and Frames.  I think it should work then.  Been forever since I used Accelerator Tables...I can probably remove the styles quicker than creating one of those.

[Paul Squires]

Hi Roger,

I think that I am starting to understand your problem. You need the WS_TABSTOP in order to position the Label just before the TextBox so that the Alt+ accelerator defined for the Label will position to the TextBox. However, defining the WS_TABSTOP will also cause the keyboard to "disappear" whenever the user TABs to a Label in the taborder. It is kind of a chicken and egg problem.

An "easy" solution would be to retain the WS_TABSTOP style for the Labels/Frames, etc and then programatically reposition the focus whenever the Label gets focus. It requires a bit of extra code, but it works:

Code Select Expand


'--------------------------------------------------------------------------------
Function FORM1_LABEL1_CUSTOM ( _
                             ControlIndex  As Long,  _  ' index in Control Array
                             hWndForm      As Dword, _  ' handle of Form
                             hWndControl   As Dword, _  ' handle of Control
                             wMsg          As Long,  _  ' type of message
                             wParam        As Dword, _  ' first message parameter
                             lParam        As Long   _  ' second message parameter
                             ) As Long

   Select Case wMsg
      Case %WM_SETFOCUS
         SetFocus HWND_FORM1_TEXT1
         Function = %TRUE
   End Select
         
End Function


the above code is a bit cumbersome if you have a lot of controls that need the focus to be changed. A faster (and cooler) way to do it would be to hook the message pump in FF_PumpHook. The code below will reposition the focus to the TextBoxes whenever the Labels receive focus.

Code Select Expand


   Select Case GetFocus()
      Case HWND_FORM1_LABEL1:  SetFocus HWND_FORM1_TEXT1
      Case HWND_FORM1_LABEL2:  SetFocus HWND_FORM1_TEXT2
   End Select


[Paul Squires]

Oh, and I'm not sure why the beep happens. It seems to only happen when you close the popup dialog by clicking on another property in the PropertyList. Clicking anywhere else in the application seems not to activate a beep. Weird. (BTW, I usually have the sound off on my computer... I guess that's why I never really noticed the beep).

[Roger Garstang]

I compiled this morning and sent to the customer to test.  I ended up removing the TabStop style from all Labels and Frames in the generated code like I mentioned.  I removed it from my Up/Dn controls too since I have it set that up/dn arrow keys work when focus is in textbox, so no need to tab to the Up/Dn controls.  Worked perfect, and too many labels/frames to make a OnFocus work around for each.  I think the bigger problem though is when not a tabstop FF doesn't keep the controls positioned right.  Marty may have found something in another thread too where controls without tabstop style that aren't listed in the tab order list then are missing a font (Although I can't get it to happen here).  I think we need to have the controls listed in the tab order list no matter what to position them and maybe make them a different color or something if not a tab stop.  You mentioned FF3 uses Tab and Z-Order too...aren't they pretty much the same thing in the end?  The order the controls are created determines both doesn't it?  And, within the IDE z-Order to me would just mean which control is on top for me to click when they are stacked.  Not really a way to edit z-order like there is for Tab Order either if they are different and seperate processing is needed for both.

On the beeping, it occurs when I close the property page with its X button.

[Roger Garstang]

Couldn't tell if this was fixed or not in latest, but just letting you know it isn't.  Almost thought it was, but next compile scrambled the order again and Up/Dn controls buddied wrong.  Taking TabStop style off Up/Dn controls also made them draw behind the text boxes, so still some issues with those too.