RSTimer - Precision Timer 2.1.0.1

Latelly I've been working on a project where I needed a precise timer, and I did not have time to write one.

So I looked up on the internet, and I found a free one.

I am so impressed on the precision on this timer, that I thought to post the link here, and maybe it will benefit you also.

This is the link where I got it:
http://www.programmersheaven.com/dow.../download.aspx

I did a small test to see how precise it is, I wrote this code:

Code:

---

Option Explicit

Private MSCount As Long, LCount As Long

Private Sub Form_Load()
    RSTimer1.Interval = 1    ' 1 millisecond
    RSTimer2.Interval = 1000  ' 1 Second
   
    RSTimer1.Enabled = True
    RSTimer2.Enabled = True
End Sub

Private Sub RSTimer1_Timer()
    MSCount = MSCount + 1
End Sub

Private Sub RSTimer2_Timer()
    Debug.Print Timer, MSCount - LCount
    LCount = MSCount
End Sub

---

This is the result I got:

Code:

---

77032.41      1000
 77033.41      1000
 77034.41      1000
 77035.41      1000
 77036.41      1000
....

---

As you can see, the the RSTimer2 fired exactly every 1 second, and RSTimer1 fired exactly 1000 times per second !

14 months old thread without comment!!!

So, what is the point?
That is what 2 timer intervals intended to work without anything else.

However, if your project have something else (long and short) to do, you won't get that result, some intervals will be missed.

I'm not sure I follow...

Do you expect the timer to fire the event on time even when your code takes longer than the interval ?

What exactly is the problem with it ?, and what do you expect from it ?

If you don't want to download an OCX, a single class file SelfTimer posted here in the CodeBank does the same :)


What anhn refers to is that if your application is busy, the timer event can't run. The native timer simply totally misses the event. This one and SelfTimer, being probably both based on the same thing (API timer), do trigger the event once application is not busy with something else anymore.

That's what happens when you have only one thread.

Quote:

---

Originally Posted by Merri

That's what happens when you have only one thread.

---

Umm... I don't think so.

The mistake people make is thinking the Timer control is some sort of clock timer. It isn't, it's a repeating one-shot interval timer.

Exiting the Timer event re-arms the one-shot, which I believe done by calling MsgWaitForMultipleObjects on a Waitable Timer object produced via CreateWaitableTimer.


VB6 is not single-threaded. That's a complete myth. I have simple single-Form programs that start 11 or more threads when busy. You just don't get manual control over threading, it's implicit based on what you are doing.


Silly example attached. Just open Task Manager and enable the Threads column. Then run the demo program and direct it to "batch process" a very large text file. Watch the Threads column for the demo program as it runs.

I changed the code by disabling the Common Dialog control, I have a file with 1000000 C's, it has been running for quite a while now and Threads = 1.

I did the same thing.

Now I see 2 threads quite consistently. I would not have expected this much threading from the Common Dialog control in a million years.

I'm still not sure why I see 2 and you see 1 though. Were you discounting a thread you know isn't doing any work?

Did you disable the Common Dialog control code and instead load a file directly? It is the OCX that seemingly increases the amount of threads, thus threads that are out of your control. The VB code itself never goes into multiple threads.

Yes, I deleted the control entirely. That's why I found the two threads where you saw one very strange.

But I did leave the silly PictureBox graphic thingy in there and running.

Nope, I wasn't discounting, I saw just one. I actually had the common dialog control still included, I just didn't use it via code. But I did see that the thread count only increased when I clicked the button to select a file. The dialog probably uses multiple threads for looking whether contents change, one for the interface and some others for something else, hard to know without really knowing the actual code that is being executed.

However, it is pretty obvious that in VB that here is just one thread, because if there were more than one the interface wouldn't get stuck. Nothing else happened until the code crashed to a runtime error - pretty much what I expected. Also, I'm sure Wokawidget wouldn't have coded a special multithreading class if there was an easier way to get the results.

I see where the confusion comes from now.

No, I never meant to suggest that your VB6 code gets more than one execution thread. I was just saying that VB6 programs can be multithreaded because many controls are internally multithreaded.

Then when you commented about testing without the Common Dialog control and seeing only one thread I managed to entirely confuse myself about the point I was making. I had to go back and read other other posts before I got back on track again.

Sheesh, that's what I get for having too many things going on here I guess. :(


But anyhow...

What I meant to get across in the first place is that since many controls are multithreaded it means your VB6 program can indeed take some advantage of multiple CPUs/cores. This is probably more pronounced in something like a server using a control array of Winsock controls.

But we're far off the topic of timers now anyway.

I don't mean to bump this thread, but I have a problem that I just can't figure out. I installed the OCX, I added it to my components, and I added the timer control to my form. I'm using VB 6.0.


I tried your code:

Code:

---

Option Explicit
Dim WithEvents RSTimer1 As RSTimer
Dim WithEvents rstimer2 As RSTimer

Private MSCount As Long, LCount As Long

Private Sub Form_Load()
    RSTimer1.Interval = 1    ' 1 millisecond
    rstimer2.Interval = 1000  ' 1 Second
   
    RSTimer1.Enabled = True
    rstimer2.Enabled = True
End Sub

Private Sub RSTimer1_Timer()
    MSCount = MSCount + 1
End Sub

Private Sub RSTimer2_Timer()
    Debug.Print Timer, MSCount - LCount
    LCount = MSCount
End Sub

---

I get "Object Variable or with block variable not set".

So then I tried something else:

Code:

---

Option Explicit

Dim WithEvents Timer As RSTimer

Private Sub Form_Load()
    Set Timer = New RSTimer
    Timer.Interval = 1
End Sub

Private Sub Form_Terminate()
    Set Timer = Nothing
End Sub

Private Sub Timer_Timer(ByVal Seconds As Currency)
    label1.Caption = Format$(Seconds, "0.000") & " seconds has passed"
End Sub

---

And with that, absolutely nothing happens. -_-...

You didn't add Timer.Enabled = True to your Form_Load after you set the Interval property.