[insanepenguin]

Hi guys,

I've followed a brief tutorial Here to read serial port data (I have an Arduino that intercepts a data feed from a home weather station) and whoever wrote it doesn't seem to provide a way to start the program, how would I start the process from the main method? Would it be easier in a Windows form text block or something?

Many thanks
Mike

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO.Ports;

namespace SerialPortReader
{
    class Program
    {
         SerialPort serialP = new SerialPort("COM4", 38400);
        
            
        static void Main(string[] args)
        {
            Console.Read();
           
            
        }
        private Program()
        {
            serialP.DataReceived +=new SerialDataReceivedEventHandler(serialP_DataReceived);
            serialP.Open();
            Console.Read();
        }

        void serialP_DataReceived(object sender, SerialDataReceivedEventArgs e)
        {
            Console.WriteLine(serialP.ReadExisting());
        }
    }
}

[Skydiver]

That is just bad programming style... he has the constructor for the class do all the work. And he assumes that the instance constructor will be called when the static Main() in invoked. *sigh*

This will get you going, but be warned that it is demo code. It is not even close to production code. The documentation in MSDN for SerialPort() has a much better structure by having a separate thread running to poll for data.

using System;
using System.IO.Ports;

namespace SerialPortReader
{
    class Program
    {
        static void serialPort_DataReceived(object sender, SerialDataReceivedEventArgs e)
        {
            SerialPort serialPort = (SerialPort) sender;
            Console.WriteLine(serialPort.ReadExisting());
        }

        static void Main(string[] args)
        {
            using(SerialPort serialPort = new SerialPort("COM4", 38400))
            {
                serialPort.DataReceived += new SerialDataReceivedEventHandler(serialPort_DataReceived);
                serialPort.Open();
                Console.Read();
            }
        }
    }
}

[insanepenguin]

Thanks a lot Skydiver,

Can you clarify something for someone new to events?

The using statement in the main method (SerialPort serialPort) is this being sent to the serialPort_DataReceived method? specifically via the 'object sender'? So the serialPort_DataReceived is an event handler for the SerialPort in the Main method? I've included an image with arrows in case I'm making no sense!

Thanks again

Attached image(s)

• 

[JackOfAllTrades]

Yes, the SerialPort object is the sender, which is why you see

SerialPort serialPort = (SerialPort) sender

inside the event handler. It must be cast to its type because event handlers mus be generic to handle whatever is sending the event.

[eclipsed4utoo]

Here is a quick run-through of the events. In .Net, objects can have events. Specifically, the SerialPort class has the DataReceived event(and more). When the event is fired by the SerialPort class(under the covers), it uses an instance of iteself as the object sender. This is how most events in .Net work. In just about any .Net event, the object sender is the instance of the object that executed the event.

So in the event handler, you can cast the object sender to the type(like Skydiver did). This gives you access to the instance of the SerialPort class that executed the event.

[insanepenguin]

It makes more sense to me now - So, the DataReceived event when triggered generates an instance of itself (and any data to output) which can be accessed by the handler via 'object sender' and then displayed (serialPort.ReadExisting())

Thanks guys!

[Curtis Rutland]

Quote

generates an instance of itself

Not quite. The DataRecieved event is a special type of Delegate, an event. You don't normally think of them like this, but methods can be stored in variables just like data can. Delegates can hold references to methods. Events are a special kind of delegate, to make it easier to use.

So, what actually happens is that when you do this:

serialPort.DataReceived += new SerialDataReceivedEventHandler(serialPort_DataReceived);

You're storing a reference to the serialPort_DataReceived) method in the DataReceived event. Then, when the SerialPort triggers the event, it reads the method (or methods, Events can store more than one reference) out of its event, and calls it (or each) with the correct parameters. It uses a reference to itself as the first parameter, and creates a SerialDataReceivedEventArgs variable for the second.

Hope that clears things up. There's no creating instances, it's all done by reference.

[insanepenguin]

Ah, that helps a lot. I have briefly looked at delegates in the past - they're kinda like pointers to a method so that when the DataReceived event is triggered it sends a reference to itself to the event handler which can then access it and do whatever?

Have I got it now?

I was making good ground in C# until the most boring University semester ever: Professional Issues, Systems Development Tools & Techniques and Network management!

Thanks for your time

[Skydiver]

Yup, that is a good way to think of delegates.

[insanepenguin]

I have one last question on this subject; how do I keep reading the serial port using a windows forms application? In the console version Console.Read(); in the Main method keeps reading the data but I'm not sure what the equivalent is for Win forms, maybe a timer or something?

Many thanks

[Curtis Rutland]

I haven't worked w/ Serial Ports, but the event should trigger every time the SerialPort object receives data.

[eclipsed4utoo]

You don't necessarily "keep reading" from the serial port. When the serial port sends data to PC, the event will fire. You just sit around waiting for it to fire. Once the event fires, you need to make sure you get all of the data though.