When you TAB through the "Tab Ordered" controls on a form, what is suppose to happen when you get to the last control in the "Tab Order" does the focus move from the last control to the first control in the "Tab Order" ?
I would think that that is what is supposed to happen. But it doesn't seem to work that way. When I "tab" way from the last control in the "Tab Order" the focus seems to get lost.
I have no problems with that. The focus always goes in a circle, that is it jumps from the last to the first control in the tab order.
Yes,
I have tried to make a simple program to illistrate the problem but have not been able to do so.
The form that is having a problem has 40 or so control of various types on it. I was thinking the some stray label or command control had a Tab stop inadvertantly set. But after pressing the tab key many times the focus never circled back.
Would there be some way to use ZTRACE to see which control has the focus as the Tab Key is pressed to change the focus from one control to another ?
Are there any listviews or multiline textboxes or something that takes focus and tab isn't passed to the default window handler? That along with stray controls with tabstops, but even then it cycles through labels and such and should come around.
Roger, Ahhh, yes.... of coarse.... I think your probably right. I will test that idea.
That may not be the problem. I found the program is Tab Stopping at an Option Group even though the Option Group has the Tab Stop turned off. I tried to duplicate this with a simple program but Tabing worked correctly something else must be going on in this more complex Form. I will play with it a bit more to if I can find the source of the problem.
Ok, I sort of have attached an example program that demostrates the problem. What the example shows is that even though "Tab Stop" has been removed from the Option Control When you tab through the TabStop controls, the program still stops at the Option Control even though it's TabStop had been removed.
In this example if you continue tabbing you will loop back to the beginning. However when this form is a child form of a FireSpitter Control then the Tabbing process gets lost and will not loop back to the beginning after errantly stopping at the Option Control.
I no doubt have made a programming error somewhere, but I can't see it. I have double checked to make sure all the Option button Controls have the "Tab Stop" property turned off. Hopefully, someone here can spot my error and set me straight.
An OptionButton that is set to true will have tabstop automatically. This is Windows behaviour.
I think the problem may be the FireSplitter.
I created a test with the FireSplitter. The form on the left has several TextBoxes and the right has only 1. All with tabstop.
The tabbing works alright starting from the left top TextBox but after the last one on the left, it went off - did not get to the TextBox on the right and did not return.
Edit: "An OptionButton that is enabled..." changed to "An OptionButton that is set to true..."
Aren't each "panels" of a Splitter considered a form though? Tabbing on one panel wouldn't jump to another panel without code. May mean tab options for the Splitter control properties like once done with one cycle what panel to move to next, etc. It is probably putting focus on the splitter control or something at the end of the cycle.
Roger, I think Cho a bit of a different problem than what I am talking about, run the example program and tab throught fields you will see what I mean.
Hi Marty,
I ran your sample. I also put it in a FireSplitter and ran it. I do not have a different problem - it is my finding from running your sample.
The OptionButton bahave as Windows designed it to when it is "checked/True" - the OptionButton "Plan Name" is given the tabstop by Windows even though you did not because it is "checked".
This OptionButton "Plan name" happens to be the last tab stop on your form so coupled with the Windows-given tabstop give the impression it is the problem when it is not.
Try do this - unchecked it in the designer and I am sure your impression of the OptionButton being the problem will change.
Just my findings. Trying to help that's all. I still learn about tabbing with FireSplitter.
ps: I counter-check the OptionButton tabstop characteristics in VB6, same behaviour.
Cho, Thanks.... That's a good explanation for the behavior is was seeing.
If I don't have any of the options buttons set to check in the control's properties then the compiler (??) won't set it to a Tab stop. ???
If the option control is set to check at RUN time, will windows add the control to the tab stops???? Well, I will test it and find out.
Hi Marty,
From what I understand looking at the CODEGEN files that FF3 creates, the settings are applied in codes in the compiled exe. This means that the OptionButton checked/unchecked is applied during runtime.
As a test. I created 3 OptionsButtons (with OptionButton2 checked) and then look at the CODEGEN. This what I found in there. Notice the SendMesage at te end of each Create?
'------------------------------------------------------------------------------
' Create OPTION1 [OptionButton] control.
'------------------------------------------------------------------------------
hWndControl = CreateWindowEx( %WS_EX_LEFT Or %WS_EX_LTRREADING, _
"Button", _
"Option1", _
%WS_CHILD Or %WS_VISIBLE Or %BS_TEXT Or %BS_NOTIFY Or %BS_AUTORADIOBUTTON _
Or %BS_LEFT Or %BS_VCENTER Or %WS_GROUP, _
8, FLY_ClientOffset + 128, _
96, 24, _
hWndForm, IDC_FORM1_OPTION1, _
App.hInstance, ByVal %Null )
ff = FLY_SetControlData( hWndControl, %TRUE, %TRUE, _
"MS Sans Serif,-11,0,0,0,400,0,0,0,0,1,2,1,34", 0, %TRUE, _
%TRUE, %TRUE, %COLOR_WINDOWTEXT, _
%COLOR_BTNFACE, -1, CodePtr(FORM1_CODEPROCEDURE) )
' Set the Tag properties for the Control
FF_Control_SetTag hWndControl, ""
FF_Control_SetTag2 hWndControl, ""
HWND_FORM1_OPTION1 = hWndControl
SendMessage hWndControl, %BM_SETCHECK, %BST_UNCHECKED, 0
'------------------------------------------------------------------------------
' Create OPTION2 [OptionButton] control.
'------------------------------------------------------------------------------
hWndControl = CreateWindowEx( %WS_EX_LEFT Or %WS_EX_LTRREADING, _
"Button", _
"Option2", _
%WS_CHILD Or %WS_VISIBLE Or %BS_TEXT Or %BS_NOTIFY Or %BS_AUTORADIOBUTTON _
Or %BS_LEFT Or %BS_VCENTER, _
8, FLY_ClientOffset + 152, _
96, 32, _
hWndForm, IDC_FORM1_OPTION2, _
App.hInstance, ByVal %Null )
ff = FLY_SetControlData( hWndControl, %TRUE, %TRUE, _
"MS Sans Serif,-11,0,0,0,400,0,0,0,0,1,2,1,34", 0, %TRUE, _
%TRUE, %TRUE, %COLOR_WINDOWTEXT, _
%COLOR_BTNFACE, -1, CodePtr(FORM1_CODEPROCEDURE) )
' Set the Tag properties for the Control
FF_Control_SetTag hWndControl, ""
FF_Control_SetTag2 hWndControl, ""
HWND_FORM1_OPTION2 = hWndControl
SendMessage hWndControl, %BM_SETCHECK, %BST_CHECKED, 0
'------------------------------------------------------------------------------
' Create OPTION3 [OptionButton] control.
'------------------------------------------------------------------------------
hWndControl = CreateWindowEx( %WS_EX_LEFT Or %WS_EX_LTRREADING, _
"Button", _
"Option3", _
%WS_CHILD Or %WS_VISIBLE Or %BS_TEXT Or %BS_NOTIFY Or %BS_AUTORADIOBUTTON _
Or %BS_LEFT Or %BS_VCENTER, _
8, FLY_ClientOffset + 184, _
95, 32, _
hWndForm, IDC_FORM1_OPTION3, _
App.hInstance, ByVal %Null )
ff = FLY_SetControlData( hWndControl, %TRUE, %TRUE, _
"MS Sans Serif,-11,0,0,0,400,0,0,0,0,1,2,1,34", 0, %TRUE, _
%TRUE, %TRUE, %COLOR_WINDOWTEXT, _
%COLOR_BTNFACE, -1, CodePtr(FORM1_CODEPROCEDURE) )
' Set the Tag properties for the Control
FF_Control_SetTag hWndControl, ""
FF_Control_SetTag2 hWndControl, ""
HWND_FORM1_OPTION3 = hWndControl
SendMessage hWndControl, %BM_SETCHECK, %BST_UNCHECKED, 0
I think Roger explaned the "problem" very well.
The panels in the FireSplitter are bascially forms. Tabbing to the end of one panel/form will not make it jump to another panel/form unless you put your own codes to do the jump.
As to why it does not cycle back to the beginning, I do not know. And I think this is either the issue or it is by design.
Hi Marty,
I created a simple test project (attached below).
The 3 OptionButton all without TabStop and all Unchecked at design time.
One Command button set Option2 to Checked. The other Command button uncheck all the 3 OptionButton.
Playing around shows that whether the OptionButton is checked via code at runtime or mouse-clicked at runtime, Windows will automatically gives it tabstop.
Again, I do not think this is the issue, but rather that you have the form in the FireSplitter as explained earlier.
The "problem" is that the FireSplitter does not have the %WS_EX_CONTROLPARENT style set. I'll modify the custom control code to include that style.
I have attached an updated FireSplitter.inc file for you guys to try.
Thanks Paul. I will report back later today.
Fantastic, the tabstop is following nicely from one ChildForm to another.
I think the order is probably better if the flow is from:
ChildForm1 to ChildForm2 to ChildForm3
Now, the flow is:
ChildForm3 to ChildForm2 to ChildForm1
hmmmm.... probably has to do with the order that the forms are created when they are assigned to the panes. Maybe if they are created in the reverse sequence then the Tab order would be as you expect. I'll have to test that theory to be certain.
The forms were created and assigned in the order:
Form1 is the main form
Form2 assigned to ChildForm1
Form3 assigned to ChildForm2
Form4 assigned to ChildForm4
Actually, I stopped at Form3 to test the SplitType 0-Vertical and 1-Hoizontal. then I created Form4 and tested 2-Both (Full Left) and 3-Both(Full Bottom).
What I notice is that when the exe is run, there is no initial tabstop. Then I hit the Tab key and it goes in the order of the later/latest panel/s first.
For SplitType 0 and 1, hitting the Tab key put the initial tabstop to begin in ChildForm2 then cycle to ChildForm1.
For SplitType 2 and 3 , hitting the Tab key put the initial tabstop to begin in ChildForm3, flow to ChildForm2 and then ChildForm1.
I put this in a separate post so as not to confuse.
On the order of creation, maybe I just share my observation. This has nothing to do with the FireSplitter.
Just on a single form and the order the controls are created in it. I notice that after the controls are created and then I look into the Tab Order, the controls are presented with the latest created appearing at the top and the earliest created at the bottom. This makes the tabstop going in reverse to the order of controls creation.
I have to re-arrange them in the Tab Order using the up/down to make the tabstop flow correctly.
http://www.winehq.org/pipermail/wine-patches/2004-August/012158.html
Could something like this be why the properties for Class/Window Styles beeps and you can't tab between options in properties?
I am not sure why the beep happens when the focus is lost closing the Class/Windows styles. I have alreayd commented on the WS_EX_CONTROLPARENT in this thread: http://www.planetsquires.com/protect/forum/index.php?topic=2325.msg18241#msg18241