Hi Erik,
if you look at the Microsoft documentation for the SerialPort DataReceived
event
http://msdn2.microsoft.com/en-us/library/system.io.ports.serialport.datareceived.aspx (watch the wrapping) it says that the DataReceived event will be raised on a
secondary thread:
"The DataReceived event is raised on a secondary thread when data is
received from the SerialPort object. Because this event is raised on a
secondary thread, and not the main thread, attempting to modify some elements
in the main thread, such as UI elements, could raise a threading exception.
If it is necessary to modify elements in the main Form or Control, post
change requests back using Invoke, which will do the work on the proper
thread."
Internally inside the SerialPort object, multiple threads are being
utilized, that is why even though you are not explicitly creating a new
thread, it is being done behind the scenes. This is a common pattern for
receiving data, there should be one thread whos job it is to receive data and
it should not spend much time processing the data, so that it can go back to
receive more data, so normally another thread is utilized to handle the data
received on the first thread.
Hope that helps
Mark Dawson
http://www.markdawson.org [quoted text, click to view] "Erik" wrote:
> Mark, that does help - I can probably solve it now.
>
> But the basic question I'm grappling with is: why is my serial port
> listener running on a separate thread in the first place? I never created a
> new thread explicitly. The only thing I did as part of a method in
> DeviceController is:
>
> // create SerialPort, open COM port, add Serial Port event handler.
> theSerialPort.DataReceived += new
> SerialDataReceivedEventHandler(SerialDataParser);
>
> SerialDataParser() just parses the serial port data and fires my
> DeviceDataEventHandler() event. I don't understand see how this code is
> running on a separate thread. I should mention this is with VS2005 and the
> ..NET framework 2.0.
>
> Erik