C# plugin - is this the way to go?

[wolf5]

Since C# not being able to expose its interface as a plugin for TC to use I came to this solution:

I create a wrapper DLL for the interface that exports all the interface members.

ListLoad will read it's ini file, which points to the .Net EXE and starts this.
ListLoad then waits for the EXE to start up and "hook in".
The EXE sends a list of callback handlers for the interface functons.
Once this is done, the ListLoad continues and returns a handle to TC.

From now on all calls to the DLL will just call the callback handlers in .Net and return whatever these returns.

Does this seem like the right way? I am a bit rusty on my C++.

[majkinetor !]

We already elaborated here that C# is not very smart choice today for writing TC plugins. Search the forum to find out.

Of course, your method will work.

[Lefteous]

http://www.c-plusplus.de/body_write_in_c.htm

[wolf5]

Hehe.

I like a challenge. Been through most of the languages from Assembly then onto C and then C++ and then VB6/.Net and finally on C#.

At the moment I like to create my stuff in C#, but I am not afraid to touch the other languages to get what I want.

This would also be a new learning experience. To "wrap" a DLL that in turn fires up an EXE file which in turn hooks into the "same" DLL.

In reality there are 1 instance of the DLL loaded into TCs memory that will start a .Net program that loads its own instance of the same DLL. So I would have to use shared memory on the DLL so the 2 instances can communicate with each other. Callbacks wont work as a DLL in one process space can not call a function in another, so I would have to use SendMessage to a window handler on the EXE file to fire any events. The EXE would then turn to its own DLL for the data it wants that the TCs DLL would present in the shared memory.

Sounds like fun to me

If I get it to work, I'll wrap it up nicely and post the solution here.

I have allready done most of that work, but I'm not familiar yet on how TC calls the exposed functions on the DLL/WLX. Ie is it when installing that it checks the "EXT"-string function and only then?

[djorge]

http://www.c-plusplus.de/body_write_in_c.htm

[majkinetor !]

It is not fun. It is pain.

U have simpler method then to use shared memory. U have some Win API message that exists to share information between processes. I don't remember what is the name of the message but I have Delph example at home so I can inform you if you are interested. Then you just do something like:

SendMessage(hwnd, WM_COPYDATA, size, data_pointer)

and you have your communication. That is much easier then keeping comm engine using shared memory.

[wolf5]

That'd be a nicer way, yes.

Didnt know of that one. How large amount of data can be put there?

[SanskritFritz]

How large amount of data can be put there?

As much your (virtual) memory can hold. A pointer can point to whatever buffer, you provide the size in the 3rd param.

[Lefteous]

ou provide the size in the 3rd param

... which is a DWORD (2^32).

msdn.microsoft.com...

[shocquer]

If you're C++ freak, you can try using managed extension in C++ and do the bridge between win32 and .NET - the rest of your classes can be in C#, IronPython, whatever you want.
But you have to know, that your plugin must be in a subdirectory of running application, of course there are some techniques to solve this problem, too - like GAC etc.