"Invalid use of Null" error on DoEvents statement in MsAccess - ms-access

Question

I have a weird situation in Access. Normally, the Invalid use of Null error is quite a simple thing - assigning a null to a string variable or some such. But I'm getting the error in a place where it seems to me it should not be happening. Here is the code snippet:
bch = Form_Akces.txtMaxCisla.BackColor
If Err <> 0 Then Stop
Form_Akces.txtMaxCisla.BackColor = vbYellow
If Err <> 0 Then Stop
DoEvents
If Err <> 0 Then Stop ' This is where I get the error
With qdf_GPsp
What's been happening is that I get this error only sometimes, usually only on the first time I run the code in a while. If I close the database and immediately re-open it, usually I do not get the error. It's been driving me nuts for quite a while, so I put in all these "If Err <> 0 Then Stop" statements, trying to track down where it happens. It's a live system, and users know to simply restart the app, but it's a massive PIA, and kind of embarrassing to boot.
Can anybody think of something to try or examine? I'm not exactly an amateur in Access, but this is far outside anything I have ever run across. Why a DoEvents statement should generate such an error is beyond me, especially since I am not doing anything even in the preceeding statements that should generate such an error, that it might be somehow 'held' until the processor gets an opportunity to throw the error. If I take out the DoEvents, I simply get the same error somewhat further down the line. txtMaxCisla is an unbound text field on the form Form_Akces, from which the routine containing this code is called. It is only on start-up - once everything is loaded and running, this never happens again. And it only happens once in a while - no pattern to it that I have been able to detect.
It's been going on for a couple of months, through numerous compile, decompile, recompile, compress and repair cycles, with no discernible change except that sometimes it happens other places, again with no reason for it that I can see.
Update *
No luck - it still crashes, and for absolutely NO reason that I can see. Here's the code now:
Public Sub ReloadMaxNumbers(tmc As TextBox)
Dim rst As DAO.Recordset, x$, xb$, xe$, bch&
On Error GoTo 0
If Err <> 0 Then Stop
DoEvents
If Err <> 0 Then Stop
...
The code stops on the SECOND test, after the DoEvents, with the same error, "Invalid use of Null". I realize this code is completely retarded, but it's the result of tracking back, trying to find the root of the error. Without this, it crashes further down the road somewhere, with this same error. At this point I can't think of anything else to even try.

Answer 1

I'm puzzled by Form_Akces in your code. If I create a form named Akces, the form's code module is named Form_Akces. But you said "on the form Form_Akces". So I am confused whether Form_Akces is the name of the form or the form's code module. Perhaps Access is also confused.
Either way, since you said the code is in the form's code module, I suggest you substitute Me for Form_Akces
Edit: I misunderstood your situation. That code you showed us is actually from a procedure in another code module, not the form's code module. In that case I would do something like this for the external procedure DoSomething:
Public Sub DoSomething(ByRef frm As Form)
bch = frm.txtMaxCisla.BackColor
frm.txtMaxCisla.BackColor = vbYellow
DoEvents
' whatever else you need
End Sub
Then in the form's code module where you call DoSomething:
DoSomething Me
And if DoSomething only operates on a single control each time, you could just pass a reference to that control instead.
Public Sub DoSomething(ByRef ctl As Control)
This approach will allow DoSomething to be re-used for other forms with no changes required because the target form name is not "hard-wired" into the procedure. Also, it won't break if you rename your Akces form. In the second variation, it would also accommodate changes to the control name.