PlugIn can't load when a COM intf object exists

Using the v6.0.4 Plugin package in XE2: I have a COM object that controls industrial hardware, that I need to interface in my plugin.  I have extracted the client interface with component wrapper for that COM object via the IDE, and that interface works fine in a standalone testing program. The plugin is loaded in my main program's main form's FormCreate method.  Whenever this _TLB.pas file is in the plugin's uses clause, calling PluginManager.LoadPlugin to load the plugin in the main app throws a "Invalid component registration" exception on the call to GetPackageInfo.  That exception falls to the except clause in LoadPlugIn, which tosses a nested unhandled exception on the call to Application.MessageBox.  Removing the _TLB file from the uses clause allows the plugin to load normally, but of course it then doesn't do what I need.

I've tried loading the plugin later in the main app startup, which just causes the unhandled exception at that point.  If I comment out the "Register" call in the _TLB file, the plugin loads normally but I then can't create an instance of the COM interface object.  So there would seem to be some kind of circular reference or race condition in the package init structure of the plugin, but I have no clue how to track this further.  Is there some sort of restriction on using IDE-generated COM interface objects in plugins?  Or is this a known problem for which a workaround is already known?  I need to create 3 or 4 such plugins that interface different types of industrial control COM objects to integrate into a master HMI program, so I need to get this one figured out.

Thanks!

Steve Sneed
B&W Power Generation Group

We have retested this here with demo 2 where we added a COM control to the plugin frame and this worked without issues. Is there something specific  to the COM control you're using?

Bruno - Thanks for replying.

Further digging on my part has found this is two separate issues.  The first is something I mentioned some time back: a hard conflict between demand-load packages and the EurekaLog exception-logging package.  The JEDI JvPlugin code seems to have the same problem, so I'm inclined to think it's something the EurekaLog folks are going to have to track down, but whether your code or the JEDI code is in use, enabling EurekaLog in either the package, the main app or both causes an unhandled exception in the EurekaLog startup code that cascades.  If I remove EurekaLog from both the package and the host app, the exception does not occur and packages (that don't include a _TLB) load normally.

However, I'm still getting the "invalid component registration" error whenever I include a _TLB that defines a TOleServer descendent into the plugin package's contains clause.  I went back and created from scratch a new DLL with a minimal server (1 interfaced method, 1 event method), registered it, then used the XE2 IDE to import the type library and generate the _TLB with component wrapper.  I then added this _TLB to the contains clause in your Demo 1 "SamplePluginOne" BPL.  Whenever I attempt to load that plugin in the Demo 1 HostApp, I get the "invalid component registration" error during the plugin load and the load fails.  The SamplePluginTwo loads and operates normally.  This is all with XE2 update 4 on Win7 Enterprise SP1 32bit.  I have the test server and related code zipped up for you if you'd like me to email or upload it.

Steve Sneed
B&W Power Generation Group

Bruno -

Follow-up: Based on your msg yesterday, I tried your method - saving the _TLB into a package, then visually dropping the COM object component on the plugin's datamodule, rather than just adding the _TLB to the uses clause and manually creating an instance of the component in code.  Your way works, mine doesn't - I can live with that. :)  So I have my package working, but if you have some insight into why doing the "visual" route works while just using the unit and creating an instance of the object in code doesn't (and throws the error even before the code gets a chance to attempt to create the object), I'd appreciate hearing it.

Steve Sneed
B&W Power Generation Group

So far, I couldn't find why doing this programmatically would behave different from dropping it on the form. I'm wondering if this is specific to the control you use or if this is general for any COM object.

Also, did you ask Eurekalog about this?

Bruno - Sorry, I've been pulled away supporting customer issues for a few days.

It appears to be general for any COM object.  I created a new COM object (very simple, one method) and tried it in your Demo1 program; when I created the object in code, it blows up, but when I make it a visual object and drop it on the plugin, it works.

I have today sent the Eurekalog folks a message about this.  I'm waiting to get their response.  I have confirmed that Eurekalog chokes on plugins regardless of their complexity, using either your plugins or the JEDI JvPlugin tools.  I'll let you know what they say.

Other than this issue, the plugin mechanism is a wonderful way to accomplish what I need to do here.  Thanks for your hard work on this, and all your great products!

Thanks,

let us know if you get any info from Eurekalog