A simple coding blog for new graduates

Some days you just have to work with old methods to get the job done. I am working on a project that needs to be in native C++ for legacy reasons, but would prefer to bring it to the modern era of programming by using C#. I wanted a way to get data from the native classes to the managed classes so the entire program could be extended easier in the future and made more simple for someone to use (the original program was very linear and very tightly integrated that the user was required to be a programmer to use it). Using Microsoft’s Common Language Infrastructure (CLI) as a bridge between native C++ and managed C#, it is possible to make the two play together nicely. I’m going to assume that you have a basic knowledge of Microsoft Visual Studio 2008 and basic C#/C++/CLR coding skills.

If you want to follow along, the complete code for the demo program is available at:

http://phamous-apps.com/wordpress/NativeCallbackDemo.zip

I first create a new C++/CLR Class Library and a new C# Windows Form application in Visual Studio:

My solution looks like the following image. CEventTest is the CLI bridge between native and managed classes while NativeClass is a class written in pure C++. I keep all the code in the header file so there is nothing in the CPP file except for a #include for the associated header file so the compiler will compile the program.

The C# project (EventTest) is just a windows form with a multi-line textbox and some buttons like the following image.

In NativeClass.h, I have the following code:

#pragma once

#include
using namespace std;

typedef void (__stdcall *CallbackType)(unsigned char*, int);

class NativeClass
{
public:

    NativeClass(void);
    ~NativeClass(void);

    void CreateByteArray(CallbackType callback)
    {
        int size = 64;
        int byteSize = size * sizeof(float);

        unsigned char* byteArray = new unsigned char[byteSize];
        float* myFloatArray = new float[size];

        for(int i=0; i<size; i++)
        {
            myFloatArray[i] = (float)i * 2;
        }

        memcpy(byteArray, myFloatArray, byteSize);

        callback(byteArray, byteSize);
    }
};

Ok, this seems like very advanced code, but keep calm and I’ll explain what’s going on. The line:

typedef void (__stdcall *CallbackType)(unsigned char*, int);

declares the callback function prototype. CallbackType is a type that I made up. You can call it FooBarType if you want. The next part is the parameter list of the function that is going to be passed. The function I’m sending will have a byte array (unsigned char pointer) and an integer (to define the size of the array). The rest is standard boilerplate code for a function pointer. Just accept that it is magic and change the parts that I mentioned.

The rest of the file is a standard C++ class. The function CreateByteArray takes in the function pointer, so “callback” contains the pointer to the function. We can use “callback” like any other function now. The rest of the code of this function creates a byte array and fills the array with sequential float values. At the end of the function I use “callback” like a normal function. So, that’s one step and the native code is done for now.

Let’s turn to the CEventTest class now. CEventTest will bridge the native code with the managed code. The code is as follows (the comments will explain the code):

// CEventTest.h

#pragma once

#include
using namespace std;

#include "NativeClass.h"

namespace CEventTest {

	// must be outside of class so other classes can use them
	public delegate void NumberSender(int x);

	// delegate used for native C++ callback function
	public delegate void NativeDelegate(unsigned char* buffer, int bufferSize);

	public ref class Processor
	{
	private:
        // native C++ class to use. it must be a pointer.
        static NativeClass* nativeC;

        // must be declared outside of method or else garbage collector will delete!
        static NativeDelegate^ callback;

	public:

		/*
		events must be static in order to be accessed by thread
		and is public so other class can register the event handler
		*/
		static event NumberSender^ SendNumber;

		/*
		This function starts the C++ native class and passes our managed method to it as a callback funtion.
		*/
		static void StartNative()
		{
			using System::IntPtr;
			using System::Runtime::InteropServices::Marshal;

			// get a pointer to the delegate
			IntPtr cbPtr = Marshal::GetFunctionPointerForDelegate(callback);

			// call the native C++ function with our delegate pointer
			nativeC->CreateByteArray(static_cast(cbPtr.ToPointer()));
		}

		// constructor
		Processor()
		{
			nativeC = new NativeClass();

			// cast our managed method to a delegate
			callback = gcnew NativeDelegate(&Processor::NativeByteReceiver);
		}

		// destructor
		~Processor()
		{
			delete nativeC;
		}

		/*
		Our managed method which is to be used as native C++ callback function
		*/

		static void NativeByteReceiver(unsigned char* byteArray, int byteSize)
		{
			int size = byteSize / sizeof(float);

			float* myFloatArray = new float[size];

			memcpy(myFloatArray, byteArray, byteSize);

			for(int i=0; i<size; i++)
			{
				// signal an event
				SendNumber((int)myFloatArray[i]);
			}
		}

		void RunNativeDemo()
		{
			StartNative();
		}
   };
}

Delegates are the equivalent of callback functions in CLI. They must be declared outside of the class like the callback function declaration in C++. I’ve declared two delegates here:

public delegate void NumberSender(int x);
public delegate void NativeDelegate(unsigned char* buffer, int bufferSize);

The first delegate “NumberSender” is used to send an integer value to managed code (ie- the C# class). The other delegate “NativeDelegate” is used to magically take the managed C++ function and get a function pointer for the native C++ class. Remember the managed function and the delegate must have the same argument list (an unsigned char pointer and an integer).

In the class, the native C++ code must be in an object so a pointer can be used. Just accept that it has to be a pointer in order for it to work so that is why it is a static pointer:

// native C++ class to use. it must be a native pointer.
static NativeClass* nativeC;

I also have a public event so that the event can be registered with managed classes:

// managed CLI pointer for the event
static event NumberSender^ SendNumber;

The function for starting the native code has to be static. We need to use the IntPtr type and the Marshal class to get the pointer. A new NativeDelegate is created and is told the function in this class to use. Pass the memory address to the delegate constructor. Then a memory pointer is derived via marshalling. Then we call the function in the native class like normal, but we need to cast the delegate pointer to the callback function type that was declared in native class. Just change the following code to suit your needs.

/*
This function starts the C++ native class and passes our managed
method to it as a callback funtion.
*/

static void StartNative()
{
    using System::IntPtr;
    using System::Runtime::InteropServices::Marshal;

    // cast our managed method to a delegate
    NativeDelegate^ callback = gcnew NativeDelegate(&Processor::NativeByteReceiver);

    // get a pointer to the delegate
    IntPtr cbPtr = Marshal::GetFunctionPointerForDelegate(callback);

    // call the native C++ function with our delegate pointer
    nativeC->CreateByteArray(static_cast(cbPtr.ToPointer()));
}

When the function is called in the native code, the order of events shift back to the CLR class:

/*
Our managed method which is to be used as native C++ callback function
*/

static void NativeByteReceiver(unsigned char* byteArray, int byteSize)
{
    int size = byteSize / sizeof(float);

    float* myFloatArray = new float[size];

    memcpy(myFloatArray, byteArray, byteSize);

    for(int i=0; i<size; i++)
    {
        // signal an event
        SendNumber((int)myFloatArray[i]);
     }
}

It does the reverse of the native class function where it takes the byte array and puts the data into a float array. Each value in the float array is then sent to the C# code via the SendNumber event.

The last function in the class (“RunNativeDemo”) just starts the entire process.

Go to the EventTest project in the Solution Explorer, right click on the project name, and click “Add Reference”. Find the project CEventTest and add the reference. Now the CLR library can be used by the C# windows form project!

In the C# designer view, double-click on the “Native Demo” button and it will generate the method stub. Create the object for the CLR class library (I name the class “Processor” and the object “countThread”). Inside the button’s method stub, I just called the function that runs the native code via CLR.

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;

// remember to include the reference to the CLR class library
using CEventTest;

namespace EventTest
{
	public partial class Form1 : Form
	{
		// declare the CLR object
		private Processor countThread;

		public Form1()
		{
			InitializeComponent();

			// initialize the CLR object
			countThread = new Processor();

			// link the event for the number sending to a function in this class
			Processor.SendNumber += new NumberSender(Processor_SendNumber);
		}

		/// <summary>
		/// Given an integer, display the number in the textbox
		/// </summary>
		///The integer value sent from the caller
		void Processor_SendNumber(int x)
		{
			// Invoking is required for accessing GUI components
			if (this.InvokeRequired)
			{
				Invoke(new NumberSender(Processor_SendNumber), new object[] { x });
			}
			else
			{
				// Create a string with the number to display in the textbox
				textBox1.AppendText(string.Format("Received Value: {0}\r\n", x));
			}
		}

		/// <summary>
		/// Starts the process to run native code
		/// </summary>
		private void uxNative_Click(object sender, EventArgs e)
		{
			countThread.RunNativeDemo();
		}
	}
}

The callback function in the form requires invoking the delegate. The subject matter is somewhat advanced to explain here so if you want to know more then read up on MSDN and Google. We’ll just accept it as magic here. As long as you have the if-else statement like the above code, swap out the delegate for your own delegate, put your argument list in the object array, and put the GUI-related code in the else block, then you are fine.

Compile the project and run. If everything is working correctly, when the “Native Demo” button is pressed, it should show a list of numbers in the textbox.

There we go! It’s magic! I’m sorry if I skipped a lot of conceptual details because I know I did but I just wanted to throw some code out there for those who want to see the concept in action. It seems there are a lot of write-ups out on the web that explain the theory and have a very basic example, but nothing to show a practical use of the concept.

I also want to note that even though my example uses a byte array, you can use any type you want for the callbacks. Floats, integers, doubles, arrays, etc. I just chose to use a byte array because that is what my project required. I could have just sent the original float array as-is if I wanted to. All I would have to do is change the type to float* instead of unsigned char* and remove the mempy step.

Also it may seem a bit much too just return a byte array from native C++ to C# in this way, but the original code in my project had the callback in a C++ thread (to separate it from the C# GUI thread), which would have complicated the example. I did not want to confuse you so the threading code was removed.

Hopefully this tutorial helped someone and didn’t bore anyone to sleep. For further reading, these links were the ones I used to piece this project together:

http://stackoverflow.com/questions/6507705/callbacks-from-c-back-to-c-sharp

http://stackoverflow.com/questions/2298242/callback-functions-in-c

http://forums.asp.net/t/571841.aspx