PRB: Access Key Causes Different Event Order than Mouse ClickID: Q74905
|
In Visual Basic, events may be generated in a different order if you choose a control (such as a button, a check box, or an option box) using an access key rather than with the mouse. The events that occur in a different order are Click, LostFocus, and GotFocus.
By inserting the DoEvents statement as the very first statement in the Click event handler, you can cause the LostFocus and GotFocus events to be handled before the body of the Click event handler.
This behavior is by design. It is not a bug in Visual Basic.
You can create an access key at design-time by changing the Caption
property of a control to include an ampersand (&). The access key is the character after the ampersand, and at run-time you press the ALT+character key to choose the control. (See page 120 of the "Microsoft Visual Basic: Programmer's Guide" version 1.0. manual.)
When you press an access key (ALT+character) to choose a control, the Click
event is generated before the LostFocus and GotFocus event; however, when
you choose a control by clicking the mouse, the LostFocus and GotFocus
events are generated before the Click event.
The example below shows this different order of events. The example
uses command buttons, but also applies to Check and Option boxes:
Sub Command1_Click ()
Print "Command1_click"
End Sub
Sub Command1_LostFocus ()
Print "Command1_lostfocus"
End Sub
Sub Command1_GotFocus ()
Print "Command1_gotfocus"
End Sub
Sub Command2_Click ()
Print "Command2_click"
End Sub
Sub Command2_LostFocus ()
Print "Command2_lostfocus"
End Sub
Sub Command2_GotFocus ()
Print "Command2_gotfocus"
End Sub
For additional information, please see the following article(s) in the Microsoft Knowledge Base:
Q177992 HOWTO: Intercept Keyboard Input from Visual Basic
Additional query words: shortcutkey hotkey
Keywords : kbVBp300 kbVBp400 kbVBp500 kbVBp600
Version : MS-DOS:; WINDOWS:1.0,2.0,3.0,4.0,5.0
Platform : MS-DOS WINDOWS
Issue type : kbprb
Last Reviewed: April 3, 1999