Background worker & Serial Comms

Question

Hi All I am on the make it work quicker portion on a project to upload and download sets of values from a device via a USB comm port. The hard parts are all done now on to the clean up. I was wondering if the backgroundWorker component could be used to remove the need I have for an Application.DoEvents(); I have used the VB6 version in the past to mixed results from it works! to its broken !!. Is there any benefit to operating the interrupt handler (which is on a seperate thread I believe) on the backgroundWorker or all the Serial Comms on the background thread. Using invokes to get the data from the Worker. Glenn

Vulpes · Answer

You can use a BackgroundWorker to keep the UI responsive whilst you're carrying out a long running task. This then avoids the need to call Application.DoEvents(). However it may not be an ideal solution for a serial comms application because the SerialPort's DataReceived ErrorReceived and PinChanged events are all called on a secondary thread anyway - different from the thread used by the BackgroundWorker - so you might have the additional problem of synchronizing between these two threads as well as the UI thread.

Glenn Patton · Answer

Hi Thanks for that just got to persuade people to pay for VS2010!! Glenn

Sam Hobbs · Answer

Serial communications need to be done with threads. DoEvents is a solution developed for unmanaged VB since unmanaged VB does not do threads. DoEvents is not the ideal solution. One way of explaining that DoEvents is not the ideal solution is to say that it executes when your program executes not when the device needs attention. DoEvents can work when the UI needs attention occasionally but a serial device needs your program to be more responsive. I am not sure if a background worker is good for that. I would use the threading API directly instead. I admit however that I am not familiar with the manged API for serial communications; does it include a separate thread as a part of the library? I assume not but if I am wrong then some of what I am saying would not be relevant. A reasonable design would include two threads; one each for input and output. You could use a background worker to manage them and interface with the UI. You should make the serial IO independent of the UI. If you can write code that depends on .Net version 4 there is a new set of classes (Tasks) that can make multithreading easier.