VBA example: how to keep the focus of the text box

Second floor Wolf Robot brotherA better solution has been provided. This article only sets this picture to record the concept of Lou pig analysis. Please skip this step if you are looking for answers ~~

 

• Origin

In Excel VBA programming, a user form is designed for input. The form contains one text box and two buttons. The text box is used for scanning gun input.

The scanner is required to be input continuously, that is, each time a bar code is scanned, the text box is automatically cleared, and the text box continues to get the focus.

 

We know that scanner input is actually equivalent to inputting a string into the text box and press Enter. Therefore, in theory, we can program in the KeyDown event subprocess of the text box to determine whether the entered character is a carriage return key, if yes, the text box is cleared.

1 Private Sub TextBox1_KeyDown (ByVal KeyCode As MSForms. ReturnInteger, ByVal Shift As Integer)
2 If KeyCode = 13 Then TextBox1.Value = ""
3 End Sub

At this point, if it is vbprogramming, it should have been completed. However, the actual operation showed that the text box was automatically cleared after the scanner was entered, but the focus went to the next button.

 

• Cause

If you are not careful, manually use the SetFocuse method to set the text box to get the focus.

1 Private Sub TextBox1_KeyDown (ByVal KeyCode As MSForms. ReturnInteger, ByVal Shift As Integer)
2 If KeyCode = 13 Then
3 TextBox1.Value = ""
4 TextBox1.SetFocus
5 End If
6 End Sub

The program runs again, and the focus is still on the button. No wonder the SetFocus method does not work after the KeyDown event subprocess (after the End Sub statement) is executed.

Why is the focus automatically transferred after the KeyDown event is executed? Finally, I had to clear the code for repeated tests and finally come to a conclusion:In Excel VBA programming, after the text box control receives the Enter key, it moves the focus to the next object in the tab key order.. (This conclusion can be confirmed by referring to the EnterKeyBehavior attribute description of the text box control)

The special emphasis is on Excel VBA programming because I vaguely remember that in VB6, the system would not "smartly" Help the text box with focus shifting. (If VB6 is not used for many years, the recall may not be correct! However, in many other event-oriented UI programming, the system will not automatically help the text box with focus shifting .)

 

• Fruit

Since the original committee is identified, it is natural to find a solution, and it depends on me. From the text box, press the Enter key to the Button1 button to get the focus. The following events are generated in sequence:

1 TextBox1_KeyDown (ByVal KeyCode As MSForms. ReturnInteger, ByVal Shift As fmShiftState)
2
3 textboxshortexit (ByVal Cancel As MSForms. ReturnBoolean)
4
5 button#enter ()
6
7 Button1_KeyPress (ByVal KeyANSI As MSForms. ReturnInteger)
8
9 Button1_KeyUp (ByVal KeyCode As MSForms. ReturnInteger, ByVal Shift As fmShiftState)

My initial thought: Since focus shifting is a system action that cannot be intervened, I will "reverse it" afterwards, in this way, the focus can be reset back to the text box using the SetFocus method from the Exit event (this statement is not rigorous. If it is implemented in the Exit event, the SetFocus method is not applicable, but Cancel = True, ). However, this brings about a logic problem. Judging from the business perspective, the text box must be kept focused only when the text box is entered, otherwise, all controls except the text box are not focused and cannot be operated! Therefore, the Code logic that interferes with focus transfer can only be implemented in the KeyDown event.

Since it cannot be reversed after the event, it can only be interrupted. I tried to use exit sub or call to exit the subprocess in the keydown event again. If it fails, the system will still automatically perform focus transfer.

At the moment, I thought that since the sub-process cannot be interrupted, why not interrupt the event. The method is to create another userform2 form. When you press enter in the text box, hide the existing form and display

In the userform2 form, the activate event of userform2 is triggered,

At the same time, the switching of the form display interrupts the text box to transfer the focus to the button. As long as the userform2 form is hidden in the activate event, the original form is displayed, and the setting of the focus to the text box is OK. This event is generated manually in the subprocess of the keydown event and is controlled. Therefore, it can be viewed as part of the code logic of the keydown event.

1 'userform1 form
2
3 Private Sub TextBox1_KeyDown (ByVal KeyCode As MSForms. ReturnInteger, ByVal Shift As Integer)
4 If KeyCode = 13 Then
5 TextBox1.Value = ""
6 UserForm1.Hide
7 UserForm2.Show
8 End If
9 End Sub

 

1 'userform2 form
2
3 Private Sub UserForm_Activate ()
4 UserForm2.Hide
5 UserForm1.Show
6 UserForm1.TextBox1. SetFocus
7 End Sub

The actual test results are very satisfactory, and the speed of form switching is invisible to the naked eye. It feels that the text box remains focused, and continuous input with a bar code gun does not require the keyboard or mouse to assist in positioning.

 

This is my solution, and it may be complicated. If you have a better solution, please come and give us some guidance!