.SetFocus is not selecting the whole field

[Seth Schrock]

I have a textbox that I use as a search field. To trigger the search, I use both an AfterUpdate event on the textbox and I have a button for those that are more mouse oriented.

Both the button's OnClick and the textbox's AfterUpdate events call the same private sub. In that subroutine I test the results to see if there was a match and if not, I do a .SetFocus back to the search textbox so that the user can retype a new value.

Problem: If the subroutine is called from the OnClick event of the textbox, then the cursor goes to the beginning of the field instead of selecting the whole field.

If the subroutine is called from the button's OnClick event, then the whole field is selected like I want.

I did check Access's setting for what to do when entering a field and it is set to select the whole field. I initially thought that it was because the control already had focus if I triggered the subroutine from the textbox's AfterUpdate event, so I tried having it set focus on the button and then going back to the textbox. There was no change for either method of triggering the subroutine so I took it back out.

Here is my code:

Private Sub FindLoan()
 
If Me.txtLoanNumberSearch & "" <> "" Then
    Me.Recordset.FindFirst "LoanNumber = " & Me.txtLoanNumberSearch
    If Me.Recordset.NoMatch Then
        Me.imgWarning.Visible = True
        Me.lblInvalidLoanNumber.Visible = True
        DoCmd.GoToRecord , , acNewRec
        Me.txtLoanNumberSearch.SetFocus
    Else
 
        Me.imgWarning.Visible = False
        Me.lblInvalidLoanNumber.Visible = False
        Me.txtLoanNumberSearch = ""
    End If
End If
 
End Sub

Both events that call this subroutine, only call the subroutine and nothing else so there is no other code that is ran.

I'm out of ideas.

[zmbd]

That is by design.
What you need is the following:

With Me.txt_controlnamehere
    .SetFocus
      z_int_length= Len(.Value)
    .SelStart = 0
    .SelLength = z_int_length
End With 

[Seth Schrock]

That works if I'm on an existing record, but if I'm on a new record it still puts the cursor at the beginning of the field.

[NeoPa]

Seth:
That works if I'm on an existing record, but if I'm on a new record it still puts the cursor at the beginning of the field.

If this is a new record then how could it be otherwise? Do you have a new record with data showing in this control?

Z's code is almost exactly as I would have suggested (I wouldn't have used a variable to save the length of .Value), and makes perfect sense. Generally, when switching controls on a form (using Tab keys etc), each newly selected control has its value fully selected. If you select a control that is already selected, however, as in the AfterUpdate() route through the code, nothing will typically happen.

Your choices are either to select the whole of the contents as Z's suggested, or to select another control first then come back to the one you want. Just as you would as an operator.

Please, if you actually have a problem with this code, could you report it back more explicitly - remembering we have only the information you choose to give with which to try to determine what's going on.

[zmbd]

Seth, You changed the problem there - nowhere in the OP do you state that you are working with a data-entry/details section of the form:

I have a textbox that I use as a search field.

I do a .SetFocus back to the search textbox so that the user can retype a new value.

This code may not always work in a new record field because the value of the control field has not been established; thus, there is no length.

This code should work for a static control as you described in the OP and has been in use in my database for 10 years both in a combo-box and in a textbox just for this purpose.

[Seth Schrock]

I'm not working with the detail section, if you notice in my code that if I type in a number were there is no match in the recordset then it goes to a new record. If I was previously on a record when this occurred then your code works. I am now on a new record but still working with an unbound text box that I use as a search box. If I type in the wrong number again, then it goes to the beginning of the search box and does not select the whole thing. So lets say I'm on loan number 123456 which is a good number. I then type into my search box 9999 (a nonexistent number). It then goes through my code and does select the whole field (the four 9s) and takes me to a new record. I then type in 99999 (another nonexistent number). Now it just puts the cursor at the beginning of the 9s and does not highlight them. Does that make more sense?

[NeoPa]

Yes it does Seth.

I'm thinking a small change in the code might be called for here. Let us know if this works :

With Me.txtControlName
    Call .SetFocus
    .SelStart = 0
    .SelLength = Len(.Text)
End With

As you haven't actually left the control at this point, .Value hasn't been updated, so .Text needs to be used instead.

[zmbd]

Seth, your code may deal with a new record, that however was not what the code was intended to deal with... it was intended to deal with a static text box is I indcated in post #5 quotes.

The search text box should have a value in it if I understand correctly - I do not see where that would have been cleared.

Seth, I'll have to see the code you used after my suggestion in #2 to understand why it "failed" in the new record case. It shouldn't have anything to do with the new record unless you used one of the record controls as the name for the "txt_controlnamehere"

As I said, I've used this particular code for a very long time without fail.

[NeoPa]

As a relevant point, but a tangent from where you are currently at, why would a Command Button need to call the procedure if an AfterUpdate() event procedure already handles that? By clicking on any other control of the form you are automatically triggering the AfterUpdate() event procedure anyway.

[Seth Schrock]

@Z I don't have the database with me at the moment, so I can't give you an exact copy, but basically, I have just replaced my line 9 with your With statement.

@NeoPa I hadn't thought of the fact that I left the textbox would trigger the AfterUpdate event (not sure why I didn't), but my idea was to provide a way for people who prefer to use the mouse more than the keyboard. Personally, I would rather use the keyboard as much as possible, but many of my users prefer the mouse. Should I just take away the button's OnClick event and let the AfterUpdate of the textbox do its work?

[NeoPa]

Seth:
Should I just take away the button's OnClick event and let the AfterUpdate of the textbox do its work?

Essentially yes. I would do away with the Command Button completely, but if you must have it then it really needs no code associated.

Seth:
basically, I have just replaced my line 9 with your With statement.

Please try my slightly amended With code too, separately. I doubt it will make much difference, as I was not allowing for the fact that the code is only ever run when the update has completed, but it would be interesting to know anyway.

[Seth Schrock]

I just tried the amended With code and it did the same thing.

You mentioned in post #4 that the other option would be to select another control and then move back to the textbox. I tried this and that doesn't work either in that it still goes to the beginning of the textbox and doesn't select the whole field. Is this the sign of a design problem on my part?

Also for clarification, in post #7 you said that the .Value of the textbox hadn't been changed so the .Text would need to be used. I thought that the value had already changed when the AfterUpdate event occurred. My understanding was that the BeforeUpdate event triggered, then the change happened, and then the AfterUpdate event was triggered. Is this not correct?

@Z Here is my code that has NeoPa's tweak.

Private Sub FindLoan()
Dim intLength As Integer
 
If Me.txtLoanNumberSearch & "" <> "" Then
    Me.Recordset.FindFirst "LoanNumber = " & Me.txtLoanNumberSearch
    If Me.Recordset.NoMatch Then
        Me.imgWarning.Visible = True
        Me.lblInvalidLoanNumber.Visible = True
        DoCmd.GoToRecord , , acNewRec
        With Me.txtLoanNumberSearch
            .SetFocus
            intLength = Len(.Text)
            .SelStart = 0
            .SelLength = intLength
        End With
    Else
 
        Me.imgWarning.Visible = False
        Me.lblInvalidLoanNumber.Visible = False
        Me.txtLoanNumberSearch = ""
    End If
End If
 
End Sub

[zmbd]

Let's see what is actually in the txtLoanNumberSearch at run time:
insert between lines 11 and 12

debug.print "text = " & .text
debug.print "value = " & .value

<ctrl><G> to get the debug window up and then run your form both ways; please report back what is printed in each case for both properties.

[Seth Schrock]

Both values were the same. While the form was sitting on a new record, I typed in 987654321 and I got:
text = 987654321
Value = 987654321

I then typed in 123456789 and I got:
text = 123456789
Value = 123456789

So the value does get changed prior to the AfterUpdate.

[NeoPa]

Seth:
I just tried the amended With code and it did the same thing.

Thank you. I was starting to suspect that I had been mistaken earlier by the time we discussed not needing the code behind the Command Button. It was a thought, but clearly flawed for exactly the reason you included in your own reasoning. I would still avoid the use of the extra variable (intLength), but I'm sure that makes no practical difference.

What I'm going to suggest now is a variation on Z's request. Please use the following With block in place of your current one and post back the results. This will hopefully throw some light onto what the code thinks it's doing at the time :

        With Me.txtLoanNumberSearch
            Call .SetFocus
Debug.Print .SelStart, .SelLength, Len(.Text), .Text,
            .SelStart = 0
            .SelLength = Len(.Text)
Debug.Print .SelStart, .SelLength;
        End With

If, for any reason, what you've typed into the control is not included in the results, then please include that in your post too.

I expect you'll have guessed by now that the behaviour you describe is unexpected, so we're interested in helping you to determine why it is.

[Seth Schrock]

 0             9             9            123456789      0             9 
 0             9             9            987654321      0             9 
 0             5             5            99999          0             5 

This is with form sitting on a new record.

Each time column 4 was what I typed into the textbox. And this does work if I use the command button (which I haven't removed yet).

[NeoPa]

This indicates that your code is working in all situations. It implies that something is happening after the code completes that resets the selection. Can you confirm that when the full contents are not selected the cursor is nevertheless found within that control?

Bear in mind that, the AfterUpdate() procedure is triggered when you leave a control, after the update has occurred, but before the change of selection. This implies that a change of selection is still pending and should occur after your code has completed execution. This would naturally cancel out any selection made within the code.

[Seth Schrock]

You are correct that the cursor is still within the control that I'm wanting. It gets positioned at the beginning of the control.

I mapped out all the events that trigger and when. Because of the record moves the form's OnCurrent event triggers. However, it triggers before the .SetFocus occurs and does not occur afterwards. In fact no other event/function/subroutine occurs after the .SetFocus. Here are then the subroutines that I can see that could affect the change of selection:

Private Sub FindLoan()
 
If Me.txtLoanNumberSearch & "" <> "" Then
    Me.Recordset.FindFirst "LoanNumber = " & Me.txtLoanNumberSearch
    If Me.Recordset.NoMatch Then
        Me.imgWarning.Visible = True
        Me.lblInvalidLoanNumber.Visible = True
        DoCmd.GoToRecord , , acNewRec
        With Me.txtLoanNumberSearch
            Call .SetFocus
            Debug.Print .SelStart, .SelLength, Len(.Text), .Text,
            .SelStart = 0
            .SelLength = Len(.Text)
            Debug.Print .SelStart, .SelLength:
        End With
    Else
 
        Me.imgWarning.Visible = False
        Me.lblInvalidLoanNumber.Visible = False
        Me.txtLoanNumberSearch = ""
    End If
End If
 
End Sub

Private Sub txtLoanNumberSearch_AfterUpdate()
FindLoan
 
End Sub

No code has been edited out for clarity or any other reason. That is the entire code. Line 8 of FindLoan runs, the form's OnCurrent event triggers, it comes back to line 9. The only lines of code that run after setting the focus, start, and length are the End With, End If, End If, End Sub, End Sub. If there is anything else you need, just let me know.

[NeoPa]

What I'm thinking of is not code Seth, but the action of whatever you hit to cause the focus to move. Even though that was done before all the code runs, it should only take effect afterwards. That said, it would tend to leave the cursor elsewhere than in that control, and would be consistent across new and existing records. That's as far as I've got I'm afraid :-(

[Seth Schrock]

Hmmm... Well I normally have been typing in the number and pressing Enter. Your comments prompted me to try other methods: Tab and clicking in another field. Both resulted in the same thing. I have tried adding a line between lines 8 & 9 that set the focus on another control. I did the same thing (move focus to another control and back again) in the AfterUpdate event of the textbox and that did the same thing still. Obviously you are correct in saying that it must be what causes the event to trigger that is throwing it off.

Maybe I can trick the system so that instead of having an AfterUpdate event on the textbox, I will just let the pressing of the enter key take me to the next control (the command button that does work) and have a GotFocus event that triggers the FindLoan subroutine. Do you think that would work or some variation of it?

This would take care of the problem with clicking the button causing the FindLoan sub to run twice if I remove the OnClick event. Both advancing from the textbox to the command button and clicking on the button would cause the GotFocus event to run.

[zmbd]

- STOP between lines 7 and 8 of last posted code.
- Arrange the window so that you can see both the form and the vba in debug mode.
- {F8} thru the code code and watch the behavior of the form let's see what's happening in slow motion.

[Seth Schrock]

I have tried stepping through the code while watching the form (I have dual monitors), but I can never see the cursor. Even when the code is done running I still can't find the cursor. Just now I tried using the Stop like you suggested instead of using a break point, but I still can't see the cursor.

[Seth Schrock]

Well I decided to try my own suggestion. It didn't work. However I did find out something interesting. I now have FindLoan only being called from the command button's GotFocus event. If I just type in a number (while on a new record) and
1) press tab
2) press enter
3) click on the button
It does the behavior that we can't figure out. If I then click the button again, it does exactly what I want it to do. It almost seems like the control hasn't been saved and that is causing it to not work. However, I'm using the .Text property not the .Value property so I would think that that shouldn't matter, but it seems to. Is there code that could save the control so that the first time I run the code it thinks that it is the same as when I run it the second time?

[NeoPa]

Seth:
Maybe I can trick the system so that instead of having an AfterUpdate event on the textbox, I will just let the pressing of the enter key take me to the next control (the command button that does work) and have a GotFocus event that triggers the FindLoan subroutine. Do you think that would work or some variation of it?

Good thinking, but not a good plan. AfterUpdate() is there because there are so many possible ways of causing the control to update.

@Z.
The active form will never display when its code is running. Certainly not in 2003 or before. Even in stopped mode that form can never be selected.

[NeoPa]

Seth:
Is there code that could save the control so that the first time I run the code it thinks that it is the same as when I run it the second time?

I only wish I knew what you meant Seth.

PS. We cross-posted so you may need to check my last post too if you haven't seen it already ;-)

[Seth Schrock]

Something is different between running the code the first time and the second time (as described in post #23). I was just wondering if we there was a way to make the code make the difference occur the first time it is ran so that whatever is in place to make it work the second time also is in place the first time in runs.

[zmbd]

Neopa: I watch active forms all of the time while stepping thru code, have since V97, hence why I suggested do so with Seth's form. Now I wasn't expecting dual monitors; however, that shouldn't make a difference.

Seth: Remove the code I suggested from the Afterupdate event.
In the "gotfocus" event of the control we're working with (in this example I've named it "combo3"
IN this example it's a combo-box; thus, the need for the "text" and not the value as the value might be from a bound hiden column:

Private Sub Combo3_GotFocus()
Dim z_int_length
With Me.Combo3
      z_int_length = Len(.Text)
    .SelStart = 0
    .SelLength = z_int_length
End With
End Sub
 

[NeoPa]

Z:
Neopa: I watch active forms all of the time while stepping thru code, have since V97, hence why I suggested do so with Seth's form. Now I wasn't expecting dual monitors; however, that shouldn't make a difference.

Not dual monitors Z. My point is that active forms cannot be selected (brought to the front) when they are running code in break mode. That said of course, as long as it is visible already, I expect it remains visible. I'd be surprised (though I'd believe if you told me it does.) if you could see things like selection highlighting change as the code runs though.

@Seth.
I sort of see where you may be coming from, but I doubt the simple matter of repeating the code would be enough. Let's see what Z's come up with and see if that throws any more light on the matter.

[Seth Schrock]

Okay. This is weird. I'm on vacation so I emailed the database to myself to work on it at home. I currently have it so that my command button has the GotFocus event (I haven't taken that off since I tried it back in post #23). So FindLoan is only called from the command button's GotFocus event so that both hitting enter while in the textbox and clicking the button triggers the event. It works perfectly on my computer at home. At first I thought that it was because of adding Z's code in the textbox's GotFocus event, but I then commented that out and it still worked.

So... What could be different about my setup at work and my setup at home that makes this not work on my work PC?

[NeoPa]

Seth:
So... What could be different about my setup at work and my setup at home that makes this not work on my work PC?

That's a good question, but not one you should consider asking others to work out for you. It would be interesting if you could tell us, bearing in mind that only you have access to either machine. Trying to work it out from the limited information available to us so that you don't need to look at what is in front of you is not a good balance of effort, I would suggest.

[Seth Schrock]

I'll see what I can figure out. Hmmm... I can't think what to look for, but as you said neither can you remotely.

Thanks to both of you for all your help. I'm choosing Z's post (#2) since that did work once I switched PCs.

[NeoPa]

Makes sense to me. After all, it was the basis of all that went on afterwards anyway :-)