I have a very simple from with about 10 fields. The first field, in my tab order, is a text box text1 the second is a control that does a seek, on the click procedure, from the user input of text1. Without changing the tab order how can I move the cursor back to text1 after the seek?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Help with VFP 7 form
- Thread starter HAINC
- Start date
Dan Freeman
Programmer
Thisform.text1.Setfocus()
(Or, old school, from the valid of the second control, RETURN -1)
(Or, old school, from the valid of the second control, RETURN -1)
Olaf Doschke
Programmer
Dan has given you the answer.
But I don't get your logic. Why do you get the idea you need to change the tab order to be able to move back?
If you do nothing, the click on a button causes it's click event, and the SEEK won't influence the focus at all, the focus will be on the button, because the user clicked it or used TAB to go there and SPACE or RETURN to click. Anyway, the focus does not stay on the text1 box, as the button also can have the focus. What do you think programmatic change of the tab order would change? The focus would still be on the button, wouldn't it?
What would your idea be, if you could change tab order on the fly and make the text1 the next control in tab order? Aactually you could, so would you do Keyboard '{TAB}' then? Have a look at intellisense, there also is '{BACKTAB}' in the list of example usages. As the user you would also be able to backtab with [SHIFT]+[TAB]. This is how you move in reverse tab order. If you don't know that, you only learned Windows half
As said, dan has given you the answer, in any case don't rely on any tab order and arrangement of controls, forms can change in time and in some years the seek button may be after several controls all for entering filter conditions. Alos don't Keyboard '{BACKTAB}', this is not a recommendation for an alternative solution, this will fail after modifications of the form, while Thisform.text1.Setfocus() will continue to work
The tab order is merely a service to the user to give your form controls an order, in which keyboard users can navigate them, which supports their workflow usage. Not setting it you get weird jumping forth and back, and programmatically changing tab order you would only disturb the tab key usage.
The setfocus() solution is also fine in the aspect it allows the user to repeatedly seek, and finally he may tab two times to get over the seek button to the next step in tab and workflow order. But indeed you could also do nothing and simply tell your users they can move back to text one with reverse tabbing.
Bye, Olaf.
But I don't get your logic. Why do you get the idea you need to change the tab order to be able to move back?
If you do nothing, the click on a button causes it's click event, and the SEEK won't influence the focus at all, the focus will be on the button, because the user clicked it or used TAB to go there and SPACE or RETURN to click. Anyway, the focus does not stay on the text1 box, as the button also can have the focus. What do you think programmatic change of the tab order would change? The focus would still be on the button, wouldn't it?
What would your idea be, if you could change tab order on the fly and make the text1 the next control in tab order? Aactually you could, so would you do Keyboard '{TAB}' then? Have a look at intellisense, there also is '{BACKTAB}' in the list of example usages. As the user you would also be able to backtab with [SHIFT]+[TAB]. This is how you move in reverse tab order. If you don't know that, you only learned Windows half
As said, dan has given you the answer, in any case don't rely on any tab order and arrangement of controls, forms can change in time and in some years the seek button may be after several controls all for entering filter conditions. Alos don't Keyboard '{BACKTAB}', this is not a recommendation for an alternative solution, this will fail after modifications of the form, while Thisform.text1.Setfocus() will continue to work
The tab order is merely a service to the user to give your form controls an order, in which keyboard users can navigate them, which supports their workflow usage. Not setting it you get weird jumping forth and back, and programmatically changing tab order you would only disturb the tab key usage.
The setfocus() solution is also fine in the aspect it allows the user to repeatedly seek, and finally he may tab two times to get over the seek button to the next step in tab and workflow order. But indeed you could also do nothing and simply tell your users they can move back to text one with reverse tabbing.
Bye, Olaf.
Olaf Doschke
Programmer
correction:
I wrote SHIFT+TAB in square brackets, the forum has a TAB TGML markup tag, which made it four spaces, that's unfortunately breaking this sentence.
Bye, Olaf.
I wrote SHIFT+TAB in square brackets, the forum has a TAB TGML markup tag, which made it four spaces, that's unfortunately breaking this sentence.
Bye, Olaf.
Mike Lewis
Programmer
Just to add a small point to Dan's answer:
If you want to put focus back on Text1 so that the user can enter a new search term, you should also set Text1's Format property to K. That way, the existing contents will be highlighted, and the user will easily be able to overwrite them.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
If you want to put focus back on Text1 so that the user can enter a new search term, you should also set Text1's Format property to K. That way, the existing contents will be highlighted, and the user will easily be able to overwrite them.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Mike Lewis
Programmer
Olaf said:
But the forum also has an "ignore" tag, which let's you "escape" the markup.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Olaf Doschke
Programmer
Right, in this case I could have unchecked TGML (like now), as I didn't add a code section. But in general: The [TAB] tag is one of the least expected. I would expect [TAB] to simply insert a tab into the text. Instead it tabs to the Attachment input control.
Well, well, in a VFP Editbox you can simply set AllowTabs = .T., there isn't a HTML analogon, I assume.
Bye, Olaf.
Well, well, in a VFP Editbox you can simply set AllowTabs = .T., there isn't a HTML analogon, I assume.
Bye, Olaf.
Olaf Doschke
Programmer
>I would expect [TAB] to simply insert a tab into the text.
In this case I meant [TAB] as the key, not as the tag.
Sigh.
Even me, being a stickler for details, I say: This is overcomplicating things.
Bye, Olaf.
In this case I meant [TAB] as the key, not as the tag.
Sigh.
Even me, being a stickler for details, I say: This is overcomplicating things.
Bye, Olaf.
- Thread starter
- #9
Than you all for your quick timely responses to my question.
Olaf, Sorry about the confusion with the Tab Order. My intent was not to touch the tab order at all I thought someone may suggest that I change my tab order that is why I said without changing the order. The Thisform.text1.Setfocus()
is exactally what I was looking for.
Olaf, Sorry about the confusion with the Tab Order. My intent was not to touch the tab order at all I thought someone may suggest that I change my tab order that is why I said without changing the order. The Thisform.text1.Setfocus()
is exactally what I was looking for.
Olaf Doschke
Programmer
I see, okay. No, I don't think anyone would suggest an unnatural tab order, just so tab from a button goes back to a previous control, since there is Setfocus, that's much simpler anyway.
Well, you couldn't have known that.
Bye, Olaf.
Well, you couldn't have known that.
Bye, Olaf.
- Status
Similar threads
- Locked
- Question