Today, I was playing around a bit. I created a Dynamic DLL file then tested it in Native Win32 Application. It was just a simple MessageBox pop up. I couldn't use the Dynamic DLL file in Managed C#, so I created a Managed Assembly using the Dynamic DLL file I created. Once this was done then I was able to transition to C# to use the Managed DLL file.

What have I learned besides Double Wrapping is this:

Different Pointers but same in reference in Dynamic DLL inside a CLR C++.

I can use both in Dynamic and CLR C++

Silly *sillyBoy = new Silly();
sillyBoy->SillySay("Sily Rabbit Tricks Are For Kids!");



However in C# I noticed:



SillyApp SillyBoyApp;
SillyBoyApp = new SillyBoyApp();
SillyBoyApp.SillyRabbit("Tricks Are For Kids!");



On additional notes, I noticed the need to convert a LPCWSTR to System.String from Native to CLR C++. For instance I had to pin_invoke the Dynamic Libray Say function:


void Say(String ^ What) {
pin_ptr msg = PtrToStringChars(What);

...
}



Where as from Dynamic DLL to Native Win32 C++ it's the same LPCWSTR because Managed .NET uses String.

Final conclusion:

The game's engine can use Dynamic DLL file but it would be a little bit over productive on my part to constantly convert to Native to CLR to C#. On the Editor's side - I can create a CLR C++ then bring it over to C#. This is how I've been doing it. However, as I discussed in my other threads - the transitional phase should be a bit more easier.

As some would say to work on the Game Engine first, I find that working with the Editor side first, allows me to at least to memorize and experience a lot more! It also keens my ability to be more diversed in language programming. Additionally, I've noticed I've been able to blaze through the coding process of CLR because now I'm Modulating all the Game Engine's Editor's functions. I think through repeatation - I learn more effectively.

Well, good night and everyone have a great night!