Which Timer?

[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.Thr eading & 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.

[Armin Zingler]

Re: Which Timer?

"Phil" <N/Aschrieb

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.Thr eading & 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.

http://msdn2.microsoft.com/en-us/lib...e6(VS.80).aspx
http://msdn.microsoft.com/msdnmag/is...T/default.aspx


Armin

[Phil]

Re: Which Timer?

>

http://msdn2.microsoft.com/en-us/lib...e6(VS.80).aspx
http://msdn.microsoft.com/msdnmag/is...T/default.aspx

Cheers,
Phil.

[Linda Liu [MSFT]]

Re: Which Timer?

Hi Phil,

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

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/subscripti...ult.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/subscripti...t/default.aspx.
=============== =============== =============== =====

This posting is provided "AS IS" with no warranties, and confers no rights.

[Cor Ligthert [MVP]]

Re: Which Timer?

>
Since that your current application is a real-time data
acquisition&con trol
system, you should use the server-based timer, i.e. System.Timers.T imer.
>

Why?

Are you not to much guessing?

Cor

[Smokey Grindle]

Re: Which Timer?

Isn't that what he said in the first post? "real-time data acquisition &
control "

"Cor Ligthert [MVP]" <notmyfirstname @planet.nlwrote in message
news:uoL26UZvHH A.4800@TK2MSFTN GP05.phx.gbl...

>

>>
>Since that your current application is a real-time data
>acquisition&co ntrol
>system, you should use the server-based timer, i.e. System.Timers.T imer.
>>

Why?
>
Are you not to much guessing?
>
Cor
>

[Phil]

Re: Which Timer?

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.

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.

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.

[Cor Ligthert [MVP]]

Re: Which Timer?

>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.

However it is.

http://msdn2.microsoft.com/en-us/lib...er(VS.71).aspx

sample is on this page,

Cor

"Phil" <N/Aschreef in bericht
news:469755a4$0 $1634$ed2619ec@ ptn-nntp-reader02.plus.n et...

>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.

>
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.

>
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]

Re: Which Timer?


"Cor Ligthert [MVP]" <notmyfirstname @planet.nlwrote in message
news:efAa1HYxHH A.4076@TK2MSFTN GP02.phx.gbl...

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.

>
However it is.
>
http://msdn2.microsoft.com/en-us/lib...er(VS.71).aspx
>
sample is on this page,

The sample on this page is shorter :-)

http://msdn2.microsoft.com/en-us/lib...ers.timer.aspx

Although to be fair I think it's doing a little more.
They are both very simple.

Cheers,
Phil.

[Phil]

Re: Which Timer?

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.

>
However it is.
>
http://msdn2.microsoft.com/en-us/lib...er(VS.71).aspx
>
sample is on this page,
>

I don't see how I can use this in my dll (class library project) as the
System.Windows. Forms namespace is not defined.

[Phil]

Re: Which Timer?

>

If you don't need a user interface for this encapsulated job, don't use
the
Winforms timer.

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.

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.T imer (because it has an Elapsed event which is easier to
use (for me))

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.threa d.sleep(100).

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