Timer blocking problems...

[Anthony Boudouvas]

Hi to all,

i have a form with 2 System.Windows.Forms.Timer objects.
One fire every 5 seconds and the other every 10 seconds,
the both take actions in two hashtables declared in same form.

When timers fire, main form is somewhat blocking until timers finish
their job, (socket operations). (Imagine to move the form by it's caption
bar and it somewhat freeze when timers fire...)

How i can design this so this blocking do not happen ?

Imagine that i am building an application like Sql Server's
Enterprise Manager, it continuously talks(in the background)
via sockets so it can display it's registered servers' status but it allows
you
to work smoothly with it in the foreground.

I tried to spawn a thread to accomplish that
(ThreadPool.QueueUserWorkItem(new WaitCallback(CheckPendingServants))

but the problem remains.

I also thought that because these 2 timer routines take actions on the
forms' hashtables,
the code running in these 2 threads will have problems to communicate with
form's main thread
and needs some delegate mechanism to do so.
I also build this too but problem remains...

My last thought is to create a second form with these 2 timers and hide it,
this form will do all work and just take actions on the -now- public
hashtables
on the main form.

Does any other idea comes to mind ?

Thanks a lot


anthonyb

 

[Nicholas Paldino [.NET/C# MVP]]

Anthony,

Using another thread is definitely the way to go. However, you don't
want to use System.Windows.Forms.Timer, as that will give you the
notifications on the UI thread, which is causing a problem.

The Timer class in the System.Timer namespace will help you. You can
create it on your UI thread, but the event notifications will come in on
another thread. You can then handle all of your processing in this event
handler. However, when updating the UI, you will have to use calls to
delegates through an Invoke method on a control in the UI so that the calls
to update the UI are on the UI thread. Otherwise, do all of the processing
on the other thread.

Also, I believe that the event is fired on a thread from the thread
pool. If your processing is long running, then you might want to throw the
processing in another thread (so that you don't tie up the thread pool).

Hope this helps.

 

[anthonyb]

The Timer class in the System.Timer namespace will help you. You can
create it on your UI thread, but the event notifications will come in on
another thread. You can then handle all of your processing in this event
handler. However, when updating the UI, you will have to use calls to
delegates through an Invoke method on a control in the UI so that the calls
to update the UI are on the UI thread. Otherwise, do all of the processing
on the other thread.

I did try that before my post here and i was facing the same problem.
I drop a Timer control in my form, not one of the Winforms controls but the
other in the component palette which is a System.Timer control
as you say.
Nothing changed. I do not know if you mean to create a System.Timer
programmatically and create and connect an event handler in it,
but i think that is the same as the System.Timer control on the form,
isn't it ?

As with the solution of the hidden secondary form, what is your opinion
in that?


Thanks a lot for the help!

anthonyb

Also, I believe that the event is fired on a thread from the thread
pool. If your processing is long running, then you might want to throw the
processing in another thread (so that you don't tie up the thread pool).

No it isn't a long running process, it is just a try/catch, creating a
TcpClient
on a apecified computerort and it last below of 2 seconds.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi to all,

i have a form with 2 System.Windows.Forms.Timer objects.
One fire every 5 seconds and the other every 10 seconds,
the both take actions in two hashtables declared in same form.

When timers fire, main form is somewhat blocking until timers finish
their job, (socket operations). (Imagine to move the form by it's caption
bar and it somewhat freeze when timers fire...)

How i can design this so this blocking do not happen ?

Imagine that i am building an application like Sql Server's
Enterprise Manager, it continuously talks(in the background)
via sockets so it can display it's registered servers' status but it allows
you
to work smoothly with it in the foreground.

I tried to spawn a thread to accomplish that
(ThreadPool.QueueUserWorkItem(new WaitCallback(CheckPendingServants))

but the problem remains.

I also thought that because these 2 timer routines take actions on the
forms' hashtables,
the code running in these 2 threads will have problems to communicate with
form's main thread
and needs some delegate mechanism to do so.
I also build this too but problem remains...

My last thought is to create a second form with these 2 timers and hide it,
this form will do all work and just take actions on the -now- public
hashtables
on the main form.

Does any other idea comes to mind ?

Thanks a lot


anthonyb

 

[Nicholas Paldino [.NET/C# MVP]]

Anthony,

You could always spawn your own thread and then call Sleep on it for the
specified amount of time. Does that work for you?


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

The Timer class in the System.Timer namespace will help you. You can
create it on your UI thread, but the event notifications will come in on
another thread. You can then handle all of your processing in this event
handler. However, when updating the UI, you will have to use calls to
delegates through an Invoke method on a control in the UI so that the calls
to update the UI are on the UI thread. Otherwise, do all of the processing
on the other thread.

I did try that before my post here and i was facing the same problem.
I drop a Timer control in my form, not one of the Winforms controls but the
other in the component palette which is a System.Timer control
as you say.
Nothing changed. I do not know if you mean to create a System.Timer
programmatically and create and connect an event handler in it,
but i think that is the same as the System.Timer control on the form,
isn't it ?

As with the solution of the hidden secondary form, what is your opinion
in that?


Thanks a lot for the help!

anthonyb

Also, I believe that the event is fired on a thread from the thread
pool. If your processing is long running, then you might want to throw the
processing in another thread (so that you don't tie up the thread pool).

No it isn't a long running process, it is just a try/catch, creating a
TcpClient
on a apecified computerort and it last below of 2 seconds.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi to all,

i have a form with 2 System.Windows.Forms.Timer objects.
One fire every 5 seconds and the other every 10 seconds,
the both take actions in two hashtables declared in same form.

When timers fire, main form is somewhat blocking until timers finish
their job, (socket operations). (Imagine to move the form by it's caption
bar and it somewhat freeze when timers fire...)

How i can design this so this blocking do not happen ?

Imagine that i am building an application like Sql Server's
Enterprise Manager, it continuously talks(in the background)
via sockets so it can display it's registered servers' status but it allows
you
to work smoothly with it in the foreground.

I tried to spawn a thread to accomplish that
(ThreadPool.QueueUserWorkItem(new WaitCallback(CheckPendingServants))

but the problem remains.

I also thought that because these 2 timer routines take actions on the
forms' hashtables,
the code running in these 2 threads will have problems to communicate with
form's main thread
and needs some delegate mechanism to do so.
I also build this too but problem remains...

My last thought is to create a second form with these 2 timers and

hide
it,

this form will do all work and just take actions on the -now- public
hashtables
on the main form.

Does any other idea comes to mind ?

Thanks a lot


anthonyb

 

[Anthony Boudouvas]

Anthony,

You could always spawn your own thread and then call Sleep on it for the
specified amount of time. Does that work for you?

Nicholas,

i have done a fair amount of work with threads, even with calling Invoke on
the main forms thread and all that stuff.

try the following code for yourself and you will see what i mean:

try
{
TrySocket = new TcpClient(ServantIP, this.ServantListenPort);
}
catch
{
//do something here...
}


Even if you spawn this code in a separet thread, you will see that the main
form is blocking


anthonyb