CarMa 2011 (public beta) [updated 14-04-2011] *old thread*

[jsn]

You should only really care about the interfaces you defined (e.g. the ITuner interface in my example above). You then need to CreateInstance an object that implements that interface (e.g. MySamplePlugins.SampleTuner). You shouldn't need to actually load the assemblies yourself, let COM interop handle that for you as I did in the Win32 example above:

HRESULT hresult = pTuner.CreateInstance("MySamplePlugins.SampleTuner");

Yeah, and thats the reason I need some XML file to be around to tell the host which
class to instantiate, because CM can't guess the name by itself.
Ofcourse, the filename could be a hint about this information (namespace.class.dll)

[Enforcer]

Yeah, and thats the reason I need some XML file to be around to tell the host which
class to instantiate, because CM can't guess the name by itself.
Ofcourse, the filename could be a hint about this information (namespace.class.dll)

With Centrafuse the namespace has to be the same name as the dll name.


So, that would be the way to go I think.

[jsn]

Ah, that explains.. And CF plugins use a fixed classname for the plugins?


(Admitted, I still have to look through the SDK of it)

[Enforcer]

Each Plugin has it's own classname, which the same as it's dll name.

ie

gas.dll would have a classname of gas

Trafficcams.dll would have a classname of trafficcams

etc.

Oh also the folder name has to match the DLL name as well, I think, with CF, although this may not be necessary just makes it easier probably.

Basically CF goes through the folders in the plugin folder, looks for the DLL matching the folder name and loads the plugin accordingly.

[jsn]

Alright.. May I suggest a somewhat simpler loading mechanism?

(plugins in their own folder is okay, not forced but optional.
CM just searches through all of them)

Why not just namespace.classname.dll, like MyPlugin.TunerClass.dll ?
It eliminates the need for another folder, and the CoCreate-string is
directly readable from the filename.

I'll try if this works, maybe I get it running in a few minutes :P


Everyone thanks for the help and suggestions!

[jsn]

Almost got it running!

CM needs a couple of minor adjustments.. Right now I'm wondering why I can't use
the interface after a successful QueryInterface. The app terminates right after the
first method. If I'm using late-binding, everything is okay?! Weird..

[gaoes]

well i just ordered my hard drive, so as soon as i find a suitable touchscreen, ill just hook it up to my home computer and wait for my mobo to come out lol.

its been a whole three days with no new posts

[jsn]

Yeah, but don't worry!

I'm still very experimenting with the .NET plugin stuff..
I have the framework a bit too much Delphi I think, not really language independant.
I was trying to convert parts of the framework, but now I'm thinking to just add
another entry for it, or a plugin which can do the translation.. I haven't solved it yet..

Anyway. I'm still working on it, but since it's all internal plumbing code now,
there's no new published build yet too.. I'll post some more tomorrow and maybe I'll just
continue working on other parts, and try this .NET-plugin thing again next week or so...

I'm determined to get it working, but I want some visible progression for you guys too :P

[jsn]

I've decided to roll-back the changes since the last stable version.
It's not quite working out as I expected. I'm thinking of putting in a separate
COM interface, instead of modifying the current Delphi-interface framework.

So, I'm going to go continue on other, more visible, parts of the application.

Expect an update somewhere the next few days!

[jsn]

btw; what are your ideas for plugins,
I ask this so I can implement the hooks you need!