Threading

[Giovanni]

Hi All,

I need help with the following: Using VB.NET 2005, I am building a
custom class in a separate assembly. The purpose of this class is to poll
the internet to determine connectivity. I have that part functioning
properly using HTTPRequest and HTTPResponse.

The problem lies here: I'd like to execute this monitoring on an
interval (Ex.: every 5 minutes), to get an up-to-date status. This updated
status would then be propagated to the class/service/app. that instanced my
class, which in my case is a WinForms application, but it can be a Windows
Service, or console app. etc...

I am trying to use the System.Threading.Thread class as from what I have
read, the other 2 types of timers are not really be usable in my situation:
System.Timers.Timer and System.Forms.Timer. I may be wrong on the
System.Timers.Timer, but the System.Forms.Form one, I am sure of this.

What is the best approach to get status data out of my custom class to
the calling app. without cross threading issues (which I am currently
experiencing when I try to transfer info to my WinForms app.). Furthermore,
should I be starting and stopping the timer while I actually perform the
polling, etc...?

Regards,

Giovanni P.

[Cor Ligthert [MVP]]

Giovanni,

I have read the same as you. My experience is however that for a simple
application the system.forms.form timer is the best (and because that you
are polling one time in 5 minutes in my idea more than sufficient)..

For windowservices is the System.Timers.Timer
for worker threads the threading.timer

The last two work on there own threads and are therefore not as easy to
abort as the first mentioned one. Don't forget for smooth use to disable the
timer if you enter its elapsed event and to enable it again if you leave
it.

I hope this helps,

Cor

"Giovanni" <Gi******@discussions.microsoft.com> schreef in bericht
news:0A**********************************@microsof t.com...

Hi All,

I need help with the following: Using VB.NET 2005, I am building a
custom class in a separate assembly. The purpose of this class is to poll
the internet to determine connectivity. I have that part functioning
properly using HTTPRequest and HTTPResponse.

The problem lies here: I'd like to execute this monitoring on an
interval (Ex.: every 5 minutes), to get an up-to-date status. This
updated
status would then be propagated to the class/service/app. that instanced
my
class, which in my case is a WinForms application, but it can be a Windows
Service, or console app. etc...

I am trying to use the System.Threading.Thread class as from what I
have
read, the other 2 types of timers are not really be usable in my
situation:
System.Timers.Timer and System.Forms.Timer. I may be wrong on the
System.Timers.Timer, but the System.Forms.Form one, I am sure of this.

What is the best approach to get status data out of my custom class to
the calling app. without cross threading issues (which I am currently
experiencing when I try to transfer info to my WinForms app.).
Furthermore,
should I be starting and stopping the timer while I actually perform the
polling, etc...?

Regards,

Giovanni P.

[Giovanni]

Hi Cor,

Thanks for the info? I was just curious as to whether to disable my
timer, do the work, and re-enable my timer; which is what you have confirmed.
I guess my last issue is still deciding whether to use the
System.Forms.Timer or the System.Timers.Timer as you will recall that I am
going to be using this functionality from a class in a separate assembly
which for the moment is only being called by a WinForms app, but would be
implemented in Console or Service type contexts.

Regards,

Giovanni

"Cor Ligthert [MVP]" wrote:

Giovanni,

I have read the same as you. My experience is however that for a simple
application the system.forms.form timer is the best (and because that you
are polling one time in 5 minutes in my idea more than sufficient)..

For windowservices is the System.Timers.Timer
for worker threads the threading.timer

The last two work on there own threads and are therefore not as easy to
abort as the first mentioned one. Don't forget for smooth use to disable the
timer if you enter its elapsed event and to enable it again if you leave
it.

I hope this helps,

Cor

"Giovanni" <Gi******@discussions.microsoft.com> schreef in bericht
news:0A**********************************@microsof t.com...

Hi All,

I need help with the following: Using VB.NET 2005, I am building a
custom class in a separate assembly. The purpose of this class is to poll
the internet to determine connectivity. I have that part functioning
properly using HTTPRequest and HTTPResponse.

The problem lies here: I'd like to execute this monitoring on an
interval (Ex.: every 5 minutes), to get an up-to-date status. This
updated
status would then be propagated to the class/service/app. that instanced
my
class, which in my case is a WinForms application, but it can be a Windows
Service, or console app. etc...

I am trying to use the System.Threading.Thread class as from what I
have
read, the other 2 types of timers are not really be usable in my
situation:
System.Timers.Timer and System.Forms.Timer. I may be wrong on the
System.Timers.Timer, but the System.Forms.Form one, I am sure of this.

What is the best approach to get status data out of my custom class to
the calling app. without cross threading issues (which I am currently
experiencing when I try to transfer info to my WinForms app.).
Furthermore,
should I be starting and stopping the timer while I actually perform the
polling, etc...?

Regards,

Giovanni P.

[dkode]

I would maybe try to put the thread to sleep instead, for 5 minutes.

When it awakens, perform the processing, then put it back to sleep.

This is probably a better way to handle this.

If you only have one thread then you might want to look at calling your
other assembly asynchronously with delegates, this way you can have a
callback method in your winforms app, otherwise to pass parameters back
to your winforms app, you will have to enforce thread safety and check
if InvokeRequired before modifying data on your winforms app. It
depends on how often and at what point you will be passing data back
and forth.

[Cor Ligthert [MVP]]

Dkode,

I would maybe try to put the thread to sleep instead, for 5 minutes.

When it awakens, perform the processing, then put it back to sleep.
What is the advantage from that in your opinion. I don't see it.

I see a disadvantage, AFAIK you cannot cancel the program because it does no
events.

Cor

This is probably a better way to handle this.

If you only have one thread then you might want to look at calling your
other assembly asynchronously with delegates, this way you can have a
callback method in your winforms app, otherwise to pass parameters back
to your winforms app, you will have to enforce thread safety and check
if InvokeRequired before modifying data on your winforms app. It
depends on how often and at what point you will be passing data back
and forth.