views:

141

answers:

2

I have a stream of data coming in from an external source which I currently collect in a BackgroundWorker. Each time it gets another chunk of data, it presents that data to a GUI using a ReportProgress() call.

I get the impression that the ProgressChanged function is just a synchronisation mechanism though so when my worker thread calls that, both threads are locked while the GUI thread processes the change. So I think the problem is that while the background thread is updating the GUI, it can't receive any data which means we lose a few packets. Is that right or is my packet dropping more likely coming frorm elsewhere?

If that is the cause, then would adding a second thread to do the GUI updating be a reasonable solution or are there better / more thorough ways of solving these problems which I ought to delve into?

Any thoughts and suggestions would be very welcome.

A: 

You may have to create a SynchronizationContext object in your GUI thread to be able to use its Post method to send messages asyncrhonously from your BackgroundWorker.

jmservera
A: 

The worker thread just sends an async message to the gui thread, which will result in an event firing in the GUI. It shouldn't halt your background thread.(and that shouldn't matter anyway. Your GUI program could halt for a long time if the user decided to start another program, etc.)

You don't talk about what kind of stream you're using. So unless you're receiving UDP datagrams, which are unreliable anyway, there should be no loss of data here. A stream is continuous .

nos
Are those events buffered in any way? Could it be that the GUI hasn't processed the first event before another is added, replacing the first? Or is this part of the standard windows message pump?
Jon Cage
The 'stream' is a TCP connection which should be buffered, so it's starting to look more likely that the source of the problems lies elsewhere.
Jon Cage