views:

127

answers:

3

Hi All

I am building a WinForms application reading from a socket data and charting lines. I am using System.Windows.Forms.Timer to trigger each second the event that

  • gets data from a queue filled by a socket
  • redraws lines on the chart

My Question is about the Timer object: I have one Timer object for each WinForm having a chart to redraws; so suppose I have 20 chart, I will have 20 forms with a total of 20 Timers.

Is this a good approach? I decided this based on the following(please correct me if I am wrong )

  • Forms.Timer instance doesn't create a Thread on my application, but just triggers the event on receiving a WM_TIMER event from the message pump of the Form.
  • it lives in the same thread of the GUI so I can directly access each element of my forms without worrying too much.

Are too much timers a good approach or could I have drawback? Thanks AFG

+1  A: 

This is a good approach, although you might want to reuse the timers instead of making a separate timer for each form.
For example, you could make a static Timer object and add a Tick handler in the form constructor. Remember to unsubscribe from the event when the form closes (in Dispose or OnClose), or your forms will never die.

SLaks
Hi SLaks! I hope you are still around!Since each Forms.Timer for process the WM_TIMER event coming from the same queue ( can you confirm this ) I think that you are right. I didn't go for this because of 2 reasons:-the final effect (I have to try) I hope it is better since 1 redraw of 30 charts using a single timer is split in 30 smaller redraw.-since the redraw routine is inside the timer, the unique timer must know about information regarding 30 forms. I decided a design choice that is "its form has its own timer to redraw on itself"..encapsulation. Please give me your thoughs about it.
Abruzzo Forte e Gentile
You misunderstood me. Each form can add its own `Tick` handler to a single Timer instance. The code would be exactly the same, but having fewer timers might reduce overhead.
SLaks
Thanks! I will try this approach to see how it is the result.
Abruzzo Forte e Gentile
+1  A: 

maybe better approach is to use a worker thread to receive data and use event fired from that worker thread to notify the UI to redraw itself.

Benny
I believe he is already doing that. (`from a queue filled by a socket`)
SLaks
Hi Benny!Thanks SLaks! Yes it is correct. The socket is read in a while loop in a separate thread. The read is blocking so data is read when it is available. After data is read I ENqueue it into a synchronized queue contained by each form. Then each second the Form.Timer of each form DEqueue it to redraw a chart.
Abruzzo Forte e Gentile
A: 

Why not redraw the line straight away when the data is received by the socket?

LnDCobra
Hi LnDCobra. The reason I didn't do that is that since data I am receiving from the socket is huge, the application will probably spend all the time in redrawing the chart lines. If I have a lot of charts I expect some slowness or worst the CPU of my application going up dramatically stucked only in 1 while loop.
Abruzzo Forte e Gentile