Which Timer?

  • Thread starter Thread starter Phil
  • Start date Start date
P

Phil

I'm glad to see that in VB 2005 I no longer have to create a form if I want
a timer like I did in VB6. I notice though, that there seems to be a Timer
component as well as two different timer classes to choose
from(System.Threading & System.Timers).
How does one decide which is most appropriate for any particular
application?
My current application is a sort of real-time data acquisition & control
system, and I need to poll an external device every 100ms or so.
TIA
Phil.
 
Phil said:
I'm glad to see that in VB 2005 I no longer have to create a form if
I want a timer like I did in VB6. I notice though, that there seems
to be a Timer component as well as two different timer classes to
choose
from(System.Threading & System.Timers).
How does one decide which is most appropriate for any particular
application?
My current application is a sort of real-time data acquisition &
control system, and I need to poll an external device every 100ms or
so.
TIA
Phil.
Click to expand...

http://msdn2.microsoft.com/en-us/library/tb9yt5e6(VS.80).aspx
http://msdn.microsoft.com/msdnmag/issues/04/02/TimersinNET/default.aspx


Armin
 
Hi Phil,

Since that your current application is a real-time data acquisition&control
system, you should use the server-based timer, i.e. System.Timers.Timer.

Hope this helps.
If you have any question, please feel free to let me know.

Sincerely,
Linda Liu
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Since that your current application is a real-time data
acquisition&control
system, you should use the server-based timer, i.e. System.Timers.Timer.
Click to expand...
Why?

Are you not to much guessing?

Cor
 
Isn't that what he said in the first post? "real-time data acquisition &
control "
 
Since that your current application is a real-time data
Can that not be done with even a simple console operation?.

It does not need a service, multithreading or whatever, however it can use
that but nothing says me what it is.

If it is a WebApplication, he can use Ajax for the clientside timer, however
I assume that it is a form application as the OP is comming from VB6 and is
asking this question, and imo is the Form timer than the best for it,
although about that is imo a lot of culprit written.

Cor
 
Cor Ligthert said:
Can that not be done with even a simple console operation?.
Click to expand...

I did decide in the end to go with the System Timer. The Threading one
looked like it might be better in terms of accuracy of the timer, but I'm
hoping that won't be too much of an issue for this particular application.
It does not need a service, multithreading or whatever, however it can use
that but nothing says me what it is.
Click to expand...

I am not implementing it as a service. I don't have any experience of doing
that, and am not sure what I would gain from it. I don't have very much
experience with multithreading either, so hopefully won't need to get into
this, as things start getting complicated.
If it is a WebApplication, he can use Ajax for the clientside timer,
however
Click to expand...

It's not a WebApplication. Not sure why you would think it might be.
I assume that it is a form application as the OP is comming from VB6 and
is asking this question, and imo is the Form timer than the best for it,
although about that is imo a lot of culprit written.
Click to expand...

It is part of a component that will be used in a forms application. This is
irrelevant though. All I want is a method in my class to be called every
0.1s. The user interface will be in a completely separate component, so has
no bearing on the issue. As I mentioned, in VB6, because the timer was only
available as a form component, you had to create a form every time you
wanted a timer, which was an annoyance, and just added extra unnecessary
overhead into the code. For this same reason I obviously wouldn't want to
use the Form timer unless I happened to be using it to control some aspect
of a form, such as an animation, an input time limit, or something like
that.

Thanks to everyone for their input.
Cheers,
Phil.
 
Phil,

Did you try to use the form timer outside a form?

I don't know how you come at those ideas nobody told you that. But take the
hard way and use one of those timer you have mentioned, I thought that I
wrote enough about it.

Cor
 
Did you try to use the form timer outside a form?

No. I naturally assumed it would require a form like the VB6 version did.
Perhaps I was wrong. If the code I've written using the system timer doesn't
work very well, I'll perhaps take another look at this, thanks.
I don't know how you come at those ideas nobody told you that.
Click to expand...

Mostly from the VB help docs. I didn't bother looking in detail at the form
based one once I discovered that there were now non-form based ones
available. The part of my application that needs the timer, doesn't have any
user interface, so a solution that doesn't involve forms seemed preferable.
But take the hard way and use one of those timer you have mentioned, I
thought that I wrote enough about it.
Click to expand...

The Threading one did look quite complicated, and I admit that was the main
reason I decided not to bother with it. The system timer is very simple
indeed, and as far as I can see it requires about two or three lines of
code. It seems to work pretty much in the same way as the VB6 timer that I'm
used to, with the one major advantage that I can create one in code just
using new, I don't have to have a form in my dll. I can't imagine the form
one would be any simpler, even if the new version now can be used without a
form.

Thanks again for your input.
Cheers,
Phil.
 
Phil said:
I don't see how I can use this in my dll (class library project) as
the System.Windows.Forms namespace is not defined.
Click to expand...

If you don't need a user interface for this encapsulated job, don't use the
Winforms timer. You would need a message loop (which requires a call to
Application.Run) to use a Forms.Timer. I wouldn't create a message loop just
for being able to use that Forms.Timer. You have to decide if you what you
have in the DLL is always part of a user interface, or, thinking the OO
abstract way, it's just an encapsulated job/thread. I don't know how you
want to implement it.

I'd probably implement the job as a class that either uses the
System.Timers.Timer (because it has an Elapsed event which is easier to use
(for me)) or encapsulates a thread containg a loop that does
the data acquisition and then waits by using threading.thread.sleep(100).

I once wrote a "Recorder" class that takes screenshots every n seconds. I
used a Timer.Timer because...see above.


Armin
PS: Be aware of the fact that the Elapsed event handler continues being
called even if the data acquisition takes longer than one tick interval
(maybe due to connection problems or whatever).
 
If you don't need a user interface for this encapsulated job, don't use
the
Winforms timer.
Click to expand...

I don't that's why I decided to use System.Timers instead. I was told though
that it would be simpler to use the form timer, and that this would work,
even without a form. I think I was misinformed.
You would need a message loop (which requires a call to
Application.Run) to use a Forms.Timer. I wouldn't create a message loop
just
for being able to use that Forms.Timer. You have to decide if you what you
have in the DLL is always part of a user interface, or, thinking the OO
abstract way, it's just an encapsulated job/thread. I don't know how you
want to implement it.
Click to expand...

The latter is more like my situation. The DLL will eventually be used within
a larger forms application, but I like the encapsulated OO style approach
to keep the cope separate. I obviously don't want any UI elements in this
DLL if it's not necessary.
I'd probably implement the job as a class that either uses the
System.Timers.Timer (because it has an Elapsed event which is easier to
use (for me))
Click to expand...

That's what I have done for now.
or encapsulates a thread containg a loop that does
the data acquisition and then waits by using threading.thread.sleep(100).
Click to expand...

That sounds interesting. I might take a look at this approach in the future.
 
Back
Top