I\'ve written a form that performs queries asynchronously as text is typed into a textbox, however I somewhat arbitrarily seem to get the following error th
You said "somewhat arbitrarily" I think if everything is fine you must get the error when your form's recordset is empty.
In fact it's a know bug in Access and this error can occur if these conditions are met: a) The control is in the Form Header or Form footer section b) The form is filtered such that no records match (or there are no records) c) No new record can be added.
In this case, the Detail section of the form goes blank. The controlis still visible, but Access gets really confused and can throw the error you describe.
More info: http://allenbrowne.com/bug-06.html
I added a text box named txtFoo
to my form. Here is the procedure for its change event.
Private Sub txtFoo_Change()
Debug.Print "Value: " & Nz(Me.txtFoo.value, "*Null*") & _
"; Text: " & Nz(Me.txtFoo.Text, "*Null*")
End Sub
Then, with nothing in txtFoo
(IOW its value is Null) when I type "abc" into txtFoo
, here is what I see in the Immediate window.
Value: *Null*; Text: a
Value: *Null*; Text: ab
Value: *Null*; Text: abc
Basically, each character I add to the text box triggers its change event and prints the text box's current contents to the Immediate window.
As far as I understand, you want to do something similar ... except you want a different action in place of Debug.Print
. Take another look at your change event procedure and compare it to mine.
Private Sub txtBox_Change()
qryText = txtVendorName.Text
UpdateRequested = true
End Sub
That is the change event for a control named txtBox
. Within that procedure you reference the .Text
property of a control named txtVendorName
. However txtBox
is the active control at the time its change event code runs ... so you can not access the .Text
property of txtVendorName
because it is not the active control.
Given that this problem surfaces for only the one form, but not on other new forms, I would suspect the problem form has become corrupted. Read the 2 answers to this SO question and try decompile to cure the corruption: HOW TO decompile and recompile. Decompile is often recommended as a routine practice during development.
You could also use the undocumented Application.SaveAsText
method to save your form as a text file. Delete the bad form, and use Application.LoadFromText
to import the saved text copy.
Make sure you have a backup copy of your db file in case anything goes wrong.
I know this is an old thread but it's the first I found when I had the same problem. None of the answers helped except Kaganar's own solution, which pointed me in the right direction. I'm guessing the reason people had trouble reproducing the error is there are some important details missing from Kaganar's description:
Because I believe the full answer is...
The Text property of any control is inaccessible when the form has a record source with no records to edit
I think there is part of Access that does not realise the textbox exists :) To understand how that might come about...
Hey presto! No Textbox.
Return a record, or allow additions, or delete the recordsource, et Voila! There is your Textbox with it's Text.
I know my answer is out of date. Yet you just can set focus three times. On TextBox in header, on any texbox in detail space and On TextBox in header again. I use access 2003.
To set or return a control's Text property, the control must have the focus, or an error occurs.
To move the focus to a control, you can use txtBox.SetFocus
or DoCmd.GoToControl "txtBox"
.
Also, the Text property is not always available:
While the control has the focus, the Text property contains the text data currently in the control; the Value property contains the last saved data for the control. When you move the focus to another control, the control's data is updated, and the Value property is set to this new value. The Text property setting is then unavailable until the control gets the focus again.
The form had a lingering data source. I'm not sure why this would cause to the behavior described above, especially considering the text box controls are unbound, however since removing the data source the text boxes are behaving as expected.