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.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Anthony Boudouvas" <an******@mediatrel.com> wrote in message
news:OH**************@TK2MSFTNGP12.phx.gbl...

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

[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 computer:port and it last below of 2 seconds.



Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Anthony Boudouvas" <an******@mediatrel.com> wrote in message
news:OH**************@TK2MSFTNGP12.phx.gbl...

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]
- mv*@spam.guard.caspershouse.com

"anthonyb" <an******@mediatrel.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

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 computer:port and it last below of 2 seconds.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Anthony Boudouvas" <an******@mediatrel.com> wrote in message
news:OH**************@TK2MSFTNGP12.phx.gbl...

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]

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:Of**************@TK2MSFTNGP12.phx.gbl...

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