none
please explain this C# code snippet RRS feed

  • Question

  • I found the following code snippet at http://www.sparxeng.com/blog/software/must-use-net-system-io-ports-serialport

    byte[] buffer = new byte[blockLimit];
    Action kickoffRead = null;
    kickoffRead = delegate {
        port.BaseStream.BeginRead(buffer, 0, buffer.Length, delegate (IAsyncResult ar) {
            try {
                int actualLength = port.BaseStream.EndRead(ar);
                byte[] received = new byte[actualLength];
                Buffer.BlockCopy(buffer, 0, received, 0, actualLength);
                raiseAppSerialDataEvent(received);
            }
            catch (IOException exc) {
                handleAppSerialError(exc);
            }
            kickoffRead();
        }, null);
    };
    kickoffRead();

    I mainly program poorly in VB.NET

    Would someone explain why:

    1.  kickoffRead is declared to be an Action but then set to be a delegate ?

    2. the delegate is calling kickoffRead ?

    I would like to attempt to convert to VB.NET, but the code is way over my level of understanding.

    Any clarification would be appreciated. Thank you.

    Thursday, February 14, 2019 2:57 PM

Answers

  • A delegate is just a reference to a method that has a particular set of arguments and return type.

    So an Action is a delegate. Specifically, it is a reference to a method that takes no arguments and doesn't return anything. See here.

    Your code example defines kickoffRead as an Action. It then sets it to an anonymous method:

    kickoffRead = delegate {
        port.BaseStream.BeginRead(buffer, 0, buffer.Length, delegate (IAsyncResult ar) {
            try {
                int actualLength = port.BaseStream.EndRead(ar);
                byte[] received = new byte[actualLength];
                Buffer.BlockCopy(buffer, 0, received, 0, actualLength);
                raiseAppSerialDataEvent(received);
            }
            catch (IOException exc) {
                handleAppSerialError(exc);
            }
            kickoffRead();
        }, null);
    };

    So the Action kickoffRead now 'points' to this method.

    It then calls that method:

    kickoffRead();

    • Marked as answer by ieee488 Sunday, February 17, 2019 3:27 PM
    Thursday, February 14, 2019 4:29 PM
  • I believe this is a kind of recursion (sort of). The delegate is calling itself, so that it is continuously reading from the port and raising events with the next buffer of data.

    • Marked as answer by ieee488 Sunday, February 17, 2019 3:27 PM
    Thursday, February 14, 2019 5:16 PM
  • Hi ieee488

    Thank you for posting here.

    For your question, you want know the code that you provided more clearly.

    >>1.  kickoffRead is declared to be an Action but then set to be a delegate ?

    Action is actually a delegate, but it is a special delegate. If you want to know more about it, you could refer to the following link.

    https://docs.microsoft.com/en-us/dotnet/api/system.action?view=netframework-4.7.2

    >>2. the delegate is calling kickoffRead ?  But why is there another kickoffRead( ) inside the anonymous method ?

    I agree the suggestion provide by the RJP1973.

    Hope my explanation could be helpful.

    Best regards,

    Jack


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    • Marked as answer by ieee488 Sunday, February 17, 2019 3:27 PM
    Friday, February 15, 2019 6:10 AM
    Moderator

All replies

  • A delegate is just a reference to a method that has a particular set of arguments and return type.

    So an Action is a delegate. Specifically, it is a reference to a method that takes no arguments and doesn't return anything. See here.

    Your code example defines kickoffRead as an Action. It then sets it to an anonymous method:

    kickoffRead = delegate {
        port.BaseStream.BeginRead(buffer, 0, buffer.Length, delegate (IAsyncResult ar) {
            try {
                int actualLength = port.BaseStream.EndRead(ar);
                byte[] received = new byte[actualLength];
                Buffer.BlockCopy(buffer, 0, received, 0, actualLength);
                raiseAppSerialDataEvent(received);
            }
            catch (IOException exc) {
                handleAppSerialError(exc);
            }
            kickoffRead();
        }, null);
    };

    So the Action kickoffRead now 'points' to this method.

    It then calls that method:

    kickoffRead();

    • Marked as answer by ieee488 Sunday, February 17, 2019 3:27 PM
    Thursday, February 14, 2019 4:29 PM
  • Thank you.

    But why is there another kickoffRead( ) inside the anonymous method ?

    Thursday, February 14, 2019 5:02 PM
  • I believe this is a kind of recursion (sort of). The delegate is calling itself, so that it is continuously reading from the port and raising events with the next buffer of data.

    • Marked as answer by ieee488 Sunday, February 17, 2019 3:27 PM
    Thursday, February 14, 2019 5:16 PM
  • Hi ieee488

    Thank you for posting here.

    For your question, you want know the code that you provided more clearly.

    >>1.  kickoffRead is declared to be an Action but then set to be a delegate ?

    Action is actually a delegate, but it is a special delegate. If you want to know more about it, you could refer to the following link.

    https://docs.microsoft.com/en-us/dotnet/api/system.action?view=netframework-4.7.2

    >>2. the delegate is calling kickoffRead ?  But why is there another kickoffRead( ) inside the anonymous method ?

    I agree the suggestion provide by the RJP1973.

    Hope my explanation could be helpful.

    Best regards,

    Jack


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    • Marked as answer by ieee488 Sunday, February 17, 2019 3:27 PM
    Friday, February 15, 2019 6:10 AM
    Moderator