Runtime Error '2185' on control that has focus

[OldBirdman]

I've spent all day on this, and can't see what I'm doing wrong. I've Googled and all I find have the same mistake, using .Text when they should use .Value. In this case, .Text is correct.

Private Sub txtSearch_Change()
Dim wk As String
wk = Me.txtSearch.Text 'This is the statement that gets Runtime Error '2185'
. . .
End Sub

I tried wk = txtSearch.Text to no avail.
I tried txtSearch.SetFo cus before the use/assignment, also didn't work.
Obviously, the control has the focus, as I am typing in it, and want to monitor what is entered, as it is entered.

Trying to trick Access into doing my bidding, I tried

Private Sub txtSearch_Change()
Dim wk As String
cmdExit.SetFocus
wk = txtSearch
txtSearch.SetFocus
txtSearch.SelStart = 255
. . .
End Sub

Now wk has the correct information, but the error occurs on the .SelStart = 255 statement. Leaving that out means that the entire string in the TextBox is selected. Not acceptable.

I copied the code for this control to a new database, new form with one control only. The code works. I copied the form to the new database, removed the RecordSource so I wouldn't have to duplicate the entire program. Works fine.

I don't want the code debugged, as the code works. I'm looking for ideas about what, on a form, might conflict with the "Got Focus". You know, like if the TextBox Backcolor is light blue, the moon is full, and the form is modal, there is trouble, so change on of these. That kind of idea.

OldBirdman

[missinglinq]

[code=vb]
Private Sub txtSearch_Chang e()
Dim wk As String
wk = Me.txtSearch.Te xt 'This is the statement that gets Runtime Error '2185'
. . .
End Sub
[/code]The .Text property is, indeed, appropriate in this context; it's one of the few times/events where it should be used. And it works fine for me, first time out, as it should have for you! Aside from corruption, which does happen to objects other than forms, I have no idea of what could have caused this! There's obviously code missing, from Line 4 of your post, and I'd be interested in knowing what this code is, for two reasons.

1. Access is notorious for popping error messages that aren't really germaine to the problem at hand
2. Access frequently hilites not the line causing the error, but rather the line before the line that is causing the problem

Linq ;0)>

[OldBirdman]

How can you imply that Microsoft programs might have errors in them? I'm stunned!

The next (and only) line of code missing is:

Call SetExtension(wk)

The code didn't work if the next line of code were "Debug.Prin t wk" or no more code, only the "End Sub" statement

I added another TextBox to the form, and error '2185' still occurs with

Private Sub Text42_Change()
Debug.Print Text42.Text
End Sub

I then created a new form, from scratch, with only a TextBox, and of course, this code worked, as I stated in my original post. Starting again, with a new form, I copied all the controls and code to the new form, and error '2185' occurred. So I started again, and copied all controls except the TextBox, which I built from scratch using the toolbox.

Now my form works. I don't know why, but it does. Now that I know that Microsoft Access has bugs, I can blame everything on them. But honestly, I have no Idea what is different here from the old form. I certainly copied EVERYTHING EXCEPT the one TextBox Control, which was recreated, but the code is identical, and so are all the properties.

When I present a problem to this forum, I try to remove anything I don't think is germain to the issue. I have 2 reasons for this: 1) I don't want to waste anybody's time trying to understand what my program is about, and 2) I don't want the thread to get off-topic.

If it is necessary, I don't mind at all posting the actual code. When I search for answers before posting questions, I find a lot of posters, on many forums, trying to explain their company's business plan, or internal workings. Some of my posts have gone off-topic when ideas are posted about having my code do something other than what I want. It's MY code, and I'm trying to generate MY "Look and Feel".

Anyway, thanks very much for looking at the problem.

OldBirdman

[AlTro]

I'm looking for ideas about what, on a form, might conflict with the "Got Focus". You know, like if the TextBox Backcolor is light blue, the moon is full, and the form is modal, there is trouble, so change on of these. That kind of idea.

You wanted an answer in this way? :)
Well, the color of textboxt might be black or white, and the moon might be full or the moon might be new, and form might be modal or not, but it seems that this error tends to happen when form does not allow additions.

I have exactly the same issue, trying to access Text property of textbox in OnChange event, and yes, was getting the same 2185 error.
Long hours of googling finally revealed this Access error 2185 after calling SetFocus and attempting to use the Text property of a Combobox.
So as a workaround you might try to

 Private Sub txtSearch_Change() 
 Dim wk As String 
Me.AllowAdditions = True
 wk = Me.txtSearch.Text 'This is the statement that gets Runtime Error '2185' 
 . . . 
Me.AllowAdditions = False
 End Sub

Seems it is working for me this way, still testing form behaviors in this case.
However there is a noticeable drawback. Form flickers when it adds and then removes the row for adding data. :(

[FishVal]

...
However there is a noticeable drawback. Form flickers when it adds and then removes the row for adding data. :(

So, why not to put the form within subform control on another form and move that textbox from original place in the form's header/footer to the parent form detail section?

[OldBirdman]

I am going to stick with the Full Moon idea for my issue. If the AllowAdditions is getting in the way when the form data is empty, then this is a completely different problem. I can see where Access can't give focus to a control bound to nothing. No record, and can't add record, so where is it supposed to be putting the input?

When creating a form that will never have any bound controls, such as my "Filter" form, I routinely set the "Allow ..." to No. I don't know why. My form in one database has 22 textboxes on 13 tabs that are monitored for change, and test the value in .Text.

In the year since I posted this thread, I have discovered a couple of things that may affect focus. If the code window is open, as it usually is in program development, then that window can get the focus. Access is then confused about where the focus should be. Stepping thru code has given different results than having the code run without a breakpoint.

Also, exiting the Sub OnClick ... can affect whether a combobox.dropdo wn will persist, or not.

I can change the forms Allow Additions to "No", either in design view or VBA. My form works as it should. The fact that I could fix it by creating a new form with ALL the same properties and then re-add this control strongly implies a corruption issue, not a errant property. I never thought to change the data handling properties, as this form and all the controls were unbound.

Sorry FishVal, but I would not make the form more complex as a work-a-round. Not with 22 textboxes.

[FishVal]

Sorry FishVal, but I would not make the form more complex as a work-a-round. Not with 22 textboxes.

I would not too since, as you clearly stated, it was a bug which gone after form rebuilding.
My point was about that reproducible bug with empty recordset / additions not allowed / textbox in form's header combination.
Instead of playing with AllowAdditions property, which causes flicker, the textbox could be moved to another form. Placing the old form within subform event would not change much (if ever at all) interface appearance.

Regards,
Fish.