TextBox.Value is incorrect in Keydown. It shows the previous value. It's a searchbox. If I previously searched for "John Smith", and now I am searching for "Mike Gold", the textbox_keydown event (pressing the enter key) shows textbox.Value = "John Smith" - it should say "Mike Gold".
If I press the enter key a second time, it now reports the correct value "Mike Gold" (because it always reports the previous value).
How do I get it to search for the correct value the first time.
I mean, this is bizarre. The screen clearly shows "Mike Gold" in the textbox. Yet the keydown event says that the words "John Smith" are in the textbox. Huh?
It isn't that you need to do this in all text box events, but you have to understand what happens and when. Remember, that the .VALUE only changes when you get to the BEFORE UPDATE/AFTER UPDATE events. Prior to that the value has not changed so .Value is meaningless if you want the current text that is in the text box. So you would need to use the .Text property for key press, key down, and key up events. And this is okay because if you are using those then that control does have the focus which is necessary to use the .Text property.
It isn't that you need to do this in all text box events, but you have to understand what happens and when. Remember, that the .VALUE only changes when you get to the BEFORE UPDATE/AFTER UPDATE events. Prior to that the value has not changed so .Value is meaningless if you want the current text that is in the text box. So you would need to use the .Text property for key press, key down, and key up events. And this is okay because if you are using those then that control does have the focus which is necessary to use the .Text property.
Thanks Bob, that's very informative. After reading this post of yours, I tried adding textBox.BeforeUpdate and textBox.AfterUpdate to my code, as a test. This was the first time I had ever used these events (I am more accustomed to using Keydown and Changed).
I'm still not comfortable using BeforeUpdate and AfterUpdate because I'm too unfamiliar with them to know when they fire. I hope I can find online a little more info about these events.
Here's a short primer for you. Reduced to the simplest terms, you would use BeforeUpdate events if there's a possibility that you'll need to undo or change the data that's been entered, or cancel the saving of a record because all of the data entered isn't valid.
AfterUpdate events are used to perform some act, depending on the data that was entered into or selected from the control.
Both of these events occur for controls that accept data (textboxes) as well as controls that allow data to be selected (comboboxes, listboxes, checkboxes, etc) and for the form itself.
Events for Controls
BeforeUpdate events for textboxes are generally used to validate data that has been entered into the textbox. If the data doesn't meet the criteria, the update is canceled and the user notified of his/her transgression. This simple example checks to see how many characters are entered into a field intended to hold a nine digit Social Security Number. If there are more or less than 9 characters entered, the user is warned with the message box, the update is canceled, and the data in the textbox is highlighted, waiting for the user to correct their mistake.
Code:
Private Sub txtSSN_BeforeUpdate(Cancel As Integer)
If Len(Me.txtSSN) <> 9 Then
MsgBox "The Social Security Number Must Contain 9 Digits! Do Not Enter Dashes!"
Cancel = True
Me.txtSSN.SelStart = 0
Me.txtSSN.SelLength = Len(txtSSN.Text)
End If
End Sub
As I said, this is a simplified example. In reality, you would also have to ensure that all the characters entered were numeric, not alpha characters.
AfterUpDate events for controls are used to perform some action, depending on what data was either entered into or selected from the control. This event is commonly used with textboxes, comboboxes, listboxes and checkboxes/radio buttons. If the checkboxes/radio buttons are part of an Option Group, the AfterUpdate event of the Option Group itself is used, rather than that of the individual checkboxes/radio buttons.
The following example uses the AfterUpdate event of a combobx named cboGender to decide whether the textbox txtGynDoctorsName needs to be visible. The textbox is set, by Default, to not be visible. If Female is selected from the combobx, txtGynDoctorsName is made visible, so that it can be filled in; if Male is selected, it remains invisible.
Code:
Private Sub cboGender_AfterUpdate()
If Me.cboGender.Value = "Female" Then
txtGynDoctorsName.Visible = True
Else
txtGynDoctorsName.Visible = False
End If
End Sub
Once again, this is a simplified example. In real life, code would also need to be placed in the Form_Current event to insure that the visiblity/invisibilitry of the txtGynDoctorsName textbox is persisted as the user moves from record to record.
It should be noted that these events will only fire if data is manually/physically entered (typed in or pasted in, or clicked on) the control. If these things are done thru code, you'll have to call these events in order for them to fire.
Events for the Form
Checking whether a required field contains data or is empty, has to be done at the form level, in the Form_BeforeUpdate event. If you tried to check this in the control BeforeUpdate event, the user could simply not enter the textbox at all, and no flag would be raised as the control's BeforeUpdate event would never fire!
We'll use the cboGender combobox again. If gender isn't chosen, we don't know whether the txtGynDoctorsName textbox needs to be visible or not.
Code:
Private Sub Form_BeforeUpdate(Cancel As Integer)
If IsNull(Me.cboGender) Then
MsgBox "You Must Select Gender!"
Cancel = True
cboGender.SetFocus
cboGender.DropDown
Exit Sub
End If
End Sub
The Form_BeforeUpdate event fires if the user tries to move to another record or tries to close the form. If no selection has been made from the combobox, the user is warned with the messagebox, the record save is canceled, focus is returned to the combobox, the combobx is dropped down, to reinforce the fact that a gender choice must be made, and the sub event is exited. This last has to be done if you’re “stacking” validation here, otherwise all of the validation messageboxes would fire, one after the other, without waiting for the user to respond.
The Form_AfterUpdate is seldom used. If you try to change the value of a control in this event, as people do from time to time, you'll set up an endless loop that you'll never be able to exit! Say you try to assign the current Date/Time to a field, MyTimeDate.
Code:
Private Sub Form_AfterUpdate()
Me.MyTimeDate = Now()
End Sub
Now that the field has been changed, the form is once again Dirty, so Access will try to save the record again, going to Form_BeforeUdate, then to Form_AfterUpdate where the Date/Time will be changed again, and so forth and so on, until you finally hit <Alt> + <Control> + <Delete>
As I said, for most purposes simply avoid using Form_AfterUpdate.
