Timer Event not always triggering on Timer Interval

[Miles R]

I have a form with the Timer Interval set to 100 milliseconds. If I move the mouse over various items on the form, the Timer Event triggers the display of various text boxes (makes visible or invisible).


Since the interval is 1/10 seconds, I would have expected it to be almost instantly responsive to mouse movements. Normally it is, but sometimes there is a lag of over a second.
I put in some simple test code in the Timer Event of the form to record the start time (and keep a record of the last timer event). If the difference between two events is > 300 milliseconds, this is flagged with a message box.
With the program idling (and nothing else except background processes running on the computer), sometimes the difference is over a second - even two seconds or more.
This means something is interfering with the timer function and it is not running every 100 milliseconds or anything close to it.

Has anyone else noticed this happening and what might be causing such a gap between Timer Events ?

Hope my explanation of what is happening is clear.

[isladogs]

Access can only handle one event at a time. This means that whilst any other process is running, timer events do not fire. As soon as the other process is complete the timer event will occur.

You can test this for yourself with a textbox set to Now() as a clock and a timer interval =1000. Whilst this is running, do something else that takes a few seconds to complete. The clock will pause whilst the timer cannot run then update when the timer triggers again

[Miles R]

Access can only handle one event at a time. This means that whilst any other process is running, timer events do not fire. As soon as the other process is complete the timer event will occur.

You can test this for yourself with a textbox set to Now() as a clock and a timer interval =1000. Whilst this is running, do something else that takes a few seconds to complete. The clock will pause whilst the timer cannot run then update when the timer triggers again

Thanks, but there are no other processes running except Windows background processes - as far as I can tell.

I stripped out all code from the Timer Event except the logging - code below :

Option Compare Database
Option Explicit


Dim lastx As Single


Private Sub Form_Timer()
Dim x As Single
Dim diff As Integer

x = Timer()

If lastx > 0 And x - lastx > 0.3 Then
diff = Int(1000 * (x - lastx))
MsgBox "Last time was " & lastx & vbCrLf & "This time was " & x & vbCrLf & "Difference = " & diff & " milliseconds"
lastx = 0
Else
lastx = x
End If
End Sub


Then, with the form open, I just sit and wait - hands off the keyboard. Within a minute the message box appears.
To me, this is a fault. I might expect the timer event to be delayed by a few milliseconds, but not a second or more.
Also, it is not as if the Access form is unresponsive, as it reacts instantly to mouse moves and button clicks - its just the Timer Event that is delayed for some reason.
If this is really the case, it means that I cannot rely on the Time Event to trigger in a timely fashion.

[isladogs]

There is a fault but I believe its in your code logic. Did you try stepping through the code?
Frankly I'm surprised it ever triggered the message as it always goes to Else for me.

Try this variation:

Dim lastX As Single

Private Sub Form_Timer()

Dim x As Single
Dim diff As Long

       
    x = Timer()
    
    If lastX > 0 Then  'or use If lastX > 0 And (x - lastX) < 0.3 Then
        diff = CLng(1000 * (x - lastX))
        MsgBox "Last time was " & lastX & vbCrLf & "This time was " & x & vbCrLf & "Difference = " & diff & " milliseconds"
        lastX = 0
    Else
        lastX = x
    End If
    
    Debug.Print x, lastX, CLng(1000 * (x - lastX))
End Sub

BTW The Timer depends on the system clock which runs approx 60 times / second i.e. intervals of 16 milliseconds approx
I would expect the diff value to be within the range 68 to 132 millseconds (100 ± 32)

[Miles R]

Thanks, but there is NO fault in the code (this test code that is - can't be certain no other issues elsewhere) and it does work exactly as I wrote it - example message below. It does not go to else if the interval between timers is > 300 ms.
(lastX is only every 0 the first time the code is executed).
Are you saying you have tried the code as I wrote it and the interval was never > 300 ms?
Be very interested if anyone else gets a large gap between timer intervals when nothing else is going on.
p.s. don't forget to set the Form Timer Interval to 100 ms.

[isladogs]

I did try it EXACTLY as you wrote it originally & of course the message box was never displayed with a timer interval =100 as you specified in your original post.
I changed the code in line with having that interval.

Obviously it will trigger if the interval is e.g. 500 in which case the difference will be within the range 468 to 532 millseconds (500 ± 32)
Tested repeatedly & works reliably for me.


.

[davegri]

Oddly also, if you hold the mouse button down for a period of time, the timer interrupt is delayed for that time.

[Micron]

Interesting that if you open the form and the timer event is firing and you can get the message if there's no keyboard or mouse movement. However, if there is a mousemove event involved (it seems that there is)

If I move the mouse over various items on the form,

then perhaps during normal use the issue is that the mousemove event continually fires if the mouse is moving. Consider that the mousemove event might queue up 1000 times in one mouse move and 10,000 times in another so I expect they'll all execute before passing control back so that the timer event can run. I realize that doesn't explain the experience when your hands are off of the mouse and keyboard; I'm suggesting that even if you figure that out, the approach may never work using mousemove.

I have to wonder why the timer event is even being used in hiding/unhiding controls.

[Miles R]

Thanks for the replies. I have got round the problem by using mouse move events, which are always responded to immediately - never a time lag.
The reason I initially used the timer event was because in this particular case, I don't like using Control Tip Text - it is not immediate - just me being fussy on my own project.
So, now mostly the mouse move events show/hide the information text when moving on or away from an object. The timer event is just belt and braces to hide the text if moving off the form (e.g. by opening another form).

Interesting to note the comments about holding the mouse button down - I too get the message box appearing as soon as the mouse is released. This must be preventing Access responding to any other events.
Also, the message box does appear more frequently if moving the mouse quickly. Maybe it is queuing up a large number of mouse move events which all have to be responded to before anything else.
(having said that, in the test database I was using, there aren't any mouse move events on the form, so it may be Windows itself that is queuing up its response to the mouse move).

I would suggest that this could be an issue for Microsoft to address, in that perhaps timer events should take priority over anything else, so they are never delayed by more than 1/10 second say.

Isladogs, did you ever get the message box to appear if you move the mouse quickly over the form?


I have just created a test database with just one form and the test code from before. Moving the mouse quickly over the form causes the message to popup quite regularly. Even occasionally when not doing anything at all. If no one else gets this response, I can only assume it is some issue on my computer. Can't think what though.

[isladogs]

Oddly also, if you hold the mouse button down for a period of time, the timer interrupt is delayed for that time.

That's exactly what I'd expect as Access is single threaded. Whilst the MouseDown event is running, everything else has to wait.

[isladogs]

If you want alternatives to using ControlTip text, have a look at my article: Control Help Text (isladogs.co.uk). There also a YouTube video to accompany it

EDIT: Tested your example app
1. Message box appears after:
a) moving the mouse with button held down then releasing the mouse button
b) moving the mouse without pressing the button then stopping
c) holding down the mouse button then releasing it

2. Message never appears if the mouse is left stationary & untouched over the form

All of those results are exactly what I'd expect

[Miles R]

Thanks for the replies. Yes, it seems its all to do with the mouse events.
I would argue this is a flaw in Access (it being totally single threaded). Holding the mouse button down or any other action should not hold up a timer event. Imagine having some other critical program stop working just because someone is holding down the mouse button. I would expect to be fired if I wrote code like that!

Maybe I'm going over the top a bit, as it is not particularly critical in Access - just don't write some code like a heart monitor or something in Access, as it might just stop for too long if you've got the mouse button pressed.

[Miles R]

Just had some further thoughts on this. In my test database, there is only one event in the program - the 100ms timer event. There are no mouse move, clicks or mouse down events or anything else, so even though Access is single threaded, why would holding the mouse button down cause an event in Access that stops it actioning the timer event - there is no mouse down event to respond to!.
Unless someone can explain why holding the mouse button down should cause an event in Access when there isn't one?

I can only think that this is some Windows 10 thing that causes the operating system to process a backlog of mouse moves that delays the system timing function or stops the timer functioning completely if the mouse button is down.