Re: do pop up boxes stop all events?

<tadamsmar@xxxxxxxxx> wrote in message news:1190289821.450242.266660@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

But it's not just that. I suspect that it just reschedules
with a 10 ms interval even if the event got a bit behind
on the queue. I does not reschedule in a way that to
insure catch-up if it gets behind. So it just keeps getting
more and more behind . . .

No. It does not reschedule in an attempt to catch up. But neither does it reschedule with a new 10 ms interval. And it does not matter how quickly your Timer event code executes. You can "get out of there" in just a few microseconds and the next event will still not occur on the next 10 millisecond interval (or anything like it) on most machines. The fact is that the underlying sytem which triggers the VB Timer (and the underlying system that triggers many Windows OS standard timing functions) does not really get a very high priority and the OS doesn't really consider such timings to be important. On most machines it simply is not possible to get 100 Hz out of the VB Timer under any circumstances. It's not just VB stuff that has that problem. Various standard OS functions have similar problems. The GetTickCount API for example, which returns the number of milliseconds since Widows was started, is often used by people who think it has a better resolution than the various VB Timer functions, but it hasn't. The GetTickCount API has a best resolution of about 16 milliseconds on many XP and Vista systems. There are better timers available in Windows of course (the multimedia timer and others), but GetTickCount and the VB Timer Control are not amongst them.

Anyway, to illustrate what I mean about the standard VB Timer's inability to produce a 100 Hz frequency on many (probably most) machines, paste the following code into a VB Form containing a ListBox and a Command Button and a Timer Control. When you click the Command Button the VB Timer will attempt to run at 100 Hz for a period of about one second and it will produce a count of the number of events and a running total of the elapsed time in the ListBox. On some XP machines you might be luckly and get something closely approximating 100 event in one second, but on many XP and Vista machines you will get something in the region of 65 events, and on almost all Win98 machines you will get just 18 events or thereabouts.

If you look at the code in the Timer event itself you will see that there is very little of it. At a guess I'd say that it takes just a few microseconds to execute at the most, something which you can demonstrate for yourself if you add a little extra code to record the actual code execution time using QueryPerformanceCounter. In fact that's why I went out out my way to collect the running data in an array instead of dumping it directly into the ListBox (which would be slow compared to standard VB math and logic and data handling, although even then it would still be just a fraction of a millisecond). So, nothing in the Timer event code itself is slowing anything down or causing any "missed events", that's for sure. And none of this really has much to do with other threads getting their own time slice, although of course that too would affect your program if other threads were demanding large slices of time. (By the way, in many cases you can sometimes improve the performance of certain time critical sections of your app by altering its thread priority, but that's not what we're talking about here).

Also, examine the running totals of the elapsed time closely. You might be lucky on your own machine, but on many machines you will see that not only are you getting just 65 events in one second but also that the events themselves are not even approximately evenly spaced out. On my own machine I get all sorts of different actual intervals (8, 11, 16 or 22 milliseconds and various others). So, that's why I said that if you want 100 Hz (or anything even closely approximating it) you will need to use a better Timer (of which there are many freeely available, by the way, if you don't fancy writing your own code).

Anyway, here's the test code:

Mike

Option Explicit
Private Declare Function timeGetTime _
Lib "winmm.dll" () As Long
Private Declare Function timeBeginPeriod _
Lib "winmm.dll" (ByVal uPeriod As Long) As Long
Private Declare Function timeEndPeriod _
Lib "winmm.dll" (ByVal uPeriod As Long) As Long
Private tStart As Long, elapsed(1 To 120) As Long
Private nCount As Long

Private Sub Form_Load()
' set highest possible resolution for timeGetTime
' so that we can record elapsed time as accurately
' as possible (1 millisecond on most machines)
timeBeginPeriod 1
'
Timer1.Enabled = False
Timer1.Interval = 10 ' attempt to set VB Timer to 100 Hz
End Sub

Private Sub Form_Unload(Cancel As Integer)
' reset timeGetTime resolution
timeEndPeriod 1
End Sub

Private Sub Command1_Click()
Caption = "Please wait . . ."
List1.Clear
nCount = 0
tStart = timeGetTime
Timer1.Enabled = True
End Sub

Private Sub Timer1_Timer()
nCount = nCount + 1
elapsed(nCount) = timeGetTime - tStart
If elapsed(nCount) >= 1000 Then ' after about one second
Timer1.Enabled = False
Caption = "Done"
displayoutput
End If
End Sub

Private Sub displayoutput()
Dim n As Long
For n = 1 To nCount
List1.AddItem n & vbTab & elapsed(n)
Next n
End Sub






.