5

is it possible to access a static property of a COM object without creating an instance of the object?

my situation is this: i have an unmanaged application (written in delphi). this application exposes a COM-based plugininterface. until now i only wrote managed plugins in c#. plugins provide their info (name, author, ..) via a static property that returns an instance of PluginInfo (which implements IPluginInfo). this static property i can access on the managed plugins using http://managedvcl.com.

now i want to write unmanaged plugins on the same interface. i can load them using:

plug := CreateComObject(TGuid) as IMyPlugInterface;

and they run, but i don't know how to read out their PluginInfo.

so the question again is: is there another way than implementing IPluginInfo in the plugin-class and only accessing the info after i have created an instance of the plugin?

joreg
  • 247
  • 1
  • 2
  • 13
  • 3
    I'm pretty sure COM has no such concept as "static property of a COM object," so your entire premise is flawed. You can't access things that don't exist. If you access static properties on C# classes, that's fine, but it ain't COM. – Rob Kennedy Mar 11 '10 at 22:15
  • Possible duplicate of [How can I invoke a static method on a .NET object over COM interop?](https://stackoverflow.com/questions/1395897/how-can-i-invoke-a-static-method-on-a-net-object-over-com-interop) – StayOnTarget May 04 '18 at 15:14

2 Answers2

2

It may not be as "elegant" as the static property provided by the C# plug-in architectures you are used to, but you could provide an exported function in the COM DLL that returns an IPluginInfo. By convention this exported function would have the same name in every plug-in DLL designed to operate in your architecture.

The host application would obtain the proc address for the exported function dynamically at runtime then call it to obtain the IPluginInfo interfaced object for that specific plug-in DLL. The mechanics for this could all be encapsulated in a class for your plug-in architecture, hiding the implementation details.

It would take very little work to reach a point where your plug-in architecture would be just as convenient to use and code against as the C# infrastructure you are more used to.

Deltics
  • 22,162
  • 2
  • 42
  • 70
1

No. Delphi's interfaces are implemented as virtual methods (basically) on an object instance, and AFAIK can't accept static members. That would probably make a useful enhancement, though.

Mason Wheeler
  • 82,511
  • 50
  • 270
  • 477
  • 2
    The limiting factor here surely isn't Delphi interfaces per se, but **COM**. To that extent, Delphi interfaces are designed primarily for use with COM and so reflect the characteristics of COM, but comparing C# plug-in architectures with *any* COM plug-in architecture is going to throw up any number of similar differences. – Deltics Mar 11 '10 at 21:10