rajeshnrh74
Programmer
- Jun 19, 2007
- 9
In vb6 form I've 1 Textbox, 2 option buttons & 1 command button. my need is I want to move from one option button to other by pressing Tab key. Help me out. This is customer requirement.
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 IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Moving Focus...
- Thread starter rajeshnrh74
- Start date
- Status
This can't be done without going against 25+ years of UI navigation practice.
The best thing to do in my opinion is to educate the customer with the "requirement" as to the correct way of navigating option buttons, after first educating yourself.
Basically, the arrow keys move from selection to selection in an option block, whereas the tab key moves from option block to option block. To see this for yourself, put a set of option buttons in a frame. Put another set of buttons outside a frame. (If you don't know how to do this, post back.) Satisfy yourself that the tabindexes are in order. Now, experiment with the behavior of the tab key and the arrow keys until you understand how they work. Once you do, no doubt you'll agree that it makes more sense to do it this way anyway.
I would suggest that you both educate your customer and sell them on the idea of doing things the way everyone else does. A strong selling point on the matter is this: often people who use the keyboard do so because they have some sort of disability. They have invested a great deal of time and effort into using the keyboard in the standard manner, therefore any deviation from that will almost certainly require a great deal of unnecessary effort on the part of that person to accommodate that deviation. This can create all sorts of unforeseen problems, including even possible liabilities due to disabled persons laws.
So, if the customer resists the idea of doing things the "right" way, you might suggest that you'd like their and your legal departments (or lawyers, if they don't have a legal department--of course the time spent by your lawyer to research this would be billable to the customer, perhaps loaded with a "processing fee") to sign off on this deviation from standard practice prior to going ahead with it. One has the feeling that Mr. Customer will probably say it's easier to just go with the flow...
Bob
The best thing to do in my opinion is to educate the customer with the "requirement" as to the correct way of navigating option buttons, after first educating yourself.
Basically, the arrow keys move from selection to selection in an option block, whereas the tab key moves from option block to option block. To see this for yourself, put a set of option buttons in a frame. Put another set of buttons outside a frame. (If you don't know how to do this, post back.) Satisfy yourself that the tabindexes are in order. Now, experiment with the behavior of the tab key and the arrow keys until you understand how they work. Once you do, no doubt you'll agree that it makes more sense to do it this way anyway.
I would suggest that you both educate your customer and sell them on the idea of doing things the way everyone else does. A strong selling point on the matter is this: often people who use the keyboard do so because they have some sort of disability. They have invested a great deal of time and effort into using the keyboard in the standard manner, therefore any deviation from that will almost certainly require a great deal of unnecessary effort on the part of that person to accommodate that deviation. This can create all sorts of unforeseen problems, including even possible liabilities due to disabled persons laws.
So, if the customer resists the idea of doing things the "right" way, you might suggest that you'd like their and your legal departments (or lawyers, if they don't have a legal department--of course the time spent by your lawyer to research this would be billable to the customer, perhaps loaded with a "processing fee") to sign off on this deviation from standard practice prior to going ahead with it. One has the feeling that Mr. Customer will probably say it's easier to just go with the flow...
Bob
Yowie. First, I wholeheartedly agree with Bob. Second, we have apps that MUST be key-friendly for users with ADA issues. I took a look at one that I did several years ago, and apologize in advance for not remembering exactly how, but the tab key does indeed tab thru check boxes in a frame object. Hopefully option buttons will behave the same. I have KeyPreview = True on the form (like it should matter), and the tab stop properties set to true for the controls.
Of course, Bob's comments are the way to go, unless (like us) there are special-needs issues to address. Good luck!
![[cheers]](/data/assets/smilies/cheers.gif "[cheers] [cheers]")
Sure, the early bird gets the worm, but the second mouse gets the cheese in the trap.
Of course, Bob's comments are the way to go, unless (like us) there are special-needs issues to address. Good luck!
Sure, the early bird gets the worm, but the second mouse gets the cheese in the trap.
<Hopefully option buttons will behave the same
I took 30 seconds to verify that they do not, and the reason seems obvious to me. Each check box represents a discrete selection in and of itself; the fact that they often fall into logical groups is irrelevant. A group of option buttons represents a discrete selection in toto; as such a means to navigate the block is necessary.
So, let me sum up how this works.
1. Option buttons come in groups of at least two (a single option is always selected and therefore superfluous). A group of option buttons represents all of the selections possible for one choice domain (e. g. color, where colore is the choice domain, and perhaps red, green and blue are the options.
2. One option in a group is always selected; by default it is the first one.
3. Option buttons not in a frame are all part of the same group.
4. Option buttons in different frames are in different groups.
5. Options in the same group are mutually exclusive; there can be only one possible option selected in a given group.
6. Check box selections are not mutually exclusive; by default, no check box selection is dependent in any way on any other check box selection.
7. Check boxes may be checked, unchecked or greyed. The latter value can only be selected programmatically. Typically it would be selected when A implies B, but the reverse is not true. In this scenario, selecting A will automatically select B, which can then not be deselected directly. B would then be greyed.
8. Tab will go to the first option button in the frame in the tabindex order. Pressing arrow keys will then loop around the buttons in the frame, changing the selected option to the control that has focus as you go. Tabbing again will exit the frame and go to the next focusable control in the tabindex order.
9. This behavior is also true of check boxes that are in frames.
10. Check boxes are selection toggled by pressing the spacebar.
Some best practice rules:
1. Don't put option buttons directly on the form.
2. Option buttons in a given frame should be in sequence in the tabindex order, top to bottom or left to right. (You may want to programmatically change the tabindex order to right to left in countries where the writing is right to left.)
3. In general, don't put check boxes directly on the form either. Check boxes that are in a frame allow the user to run through them with the arrow keys once they have tabbed into the frame. However, sometimes it makes sense to have a single check box in the main tab order.
4. Put option buttons that are in the same frame in a control array.
5. Consider hotkey support for options and check boxes.
6. Above all, DON'T TRY TO CHANGE THE STANDARD NAVIGATION RULES. It isn't an improvement, really it isn't. All you're doing is making your application more difficult to use.
I would recommend to anyone creating a UI to imagine that you have only one finger at your disposal (a reality for someone who may have to use your application), and attempt to navigate it. You should realize pretty quickly that the standard mouse is quite difficult to use (don't grip the mouse with your other fingers), and you will in many situations prefer to use the keyboard. I would also point out that Microsoft put much more effort into setting up the keyboard the way it is than anyone who is likely to want to change it, which is why I would take a good deal of convincing to go along with doing so.
HTH
Bob
I took 30 seconds to verify that they do not, and the reason seems obvious to me. Each check box represents a discrete selection in and of itself; the fact that they often fall into logical groups is irrelevant. A group of option buttons represents a discrete selection in toto; as such a means to navigate the block is necessary.
So, let me sum up how this works.
1. Option buttons come in groups of at least two (a single option is always selected and therefore superfluous). A group of option buttons represents all of the selections possible for one choice domain (e. g. color, where colore is the choice domain, and perhaps red, green and blue are the options.
2. One option in a group is always selected; by default it is the first one.
3. Option buttons not in a frame are all part of the same group.
4. Option buttons in different frames are in different groups.
5. Options in the same group are mutually exclusive; there can be only one possible option selected in a given group.
6. Check box selections are not mutually exclusive; by default, no check box selection is dependent in any way on any other check box selection.
7. Check boxes may be checked, unchecked or greyed. The latter value can only be selected programmatically. Typically it would be selected when A implies B, but the reverse is not true. In this scenario, selecting A will automatically select B, which can then not be deselected directly. B would then be greyed.
8. Tab will go to the first option button in the frame in the tabindex order. Pressing arrow keys will then loop around the buttons in the frame, changing the selected option to the control that has focus as you go. Tabbing again will exit the frame and go to the next focusable control in the tabindex order.
9. This behavior is also true of check boxes that are in frames.
10. Check boxes are selection toggled by pressing the spacebar.
Some best practice rules:
1. Don't put option buttons directly on the form.
2. Option buttons in a given frame should be in sequence in the tabindex order, top to bottom or left to right. (You may want to programmatically change the tabindex order to right to left in countries where the writing is right to left.)
3. In general, don't put check boxes directly on the form either. Check boxes that are in a frame allow the user to run through them with the arrow keys once they have tabbed into the frame. However, sometimes it makes sense to have a single check box in the main tab order.
4. Put option buttons that are in the same frame in a control array.
5. Consider hotkey support for options and check boxes.
6. Above all, DON'T TRY TO CHANGE THE STANDARD NAVIGATION RULES. It isn't an improvement, really it isn't. All you're doing is making your application more difficult to use.
I would recommend to anyone creating a UI to imagine that you have only one finger at your disposal (a reality for someone who may have to use your application), and attempt to navigate it. You should realize pretty quickly that the standard mouse is quite difficult to use (don't grip the mouse with your other fingers), and you will in many situations prefer to use the keyboard. I would also point out that Microsoft put much more effort into setting up the keyboard the way it is than anyone who is likely to want to change it, which is why I would take a good deal of convincing to go along with doing so.
HTH
Bob
- Status
Similar threads
