Board index » delphi » COM Plus straight COM interfaces don't work

COM Plus straight COM interfaces don't work

I am sorry to have to ask for this, but could I please get a working example
of a non dispatchable (TTypedComObject derived) COM Plus component? I am
very familair with COM, but for whatever reason I can't get a component
(CoClass) instance using the ComObj routines CreateComObject and
CreateRemoteComObject (or CoCreateInstance for that matter) to sucessfully
query (return S_OK) for my custom interface anytime after it has been
registered in the "Component Services" applet under Windows 2000 (both
professional and server with and without service packs). Before the
component is registered with the "Component Services" applet I am able to
create instances of my interface easily. As soon as I register the component
with the "Component Services" applet I receive the dreaded "No such
interface supported" error message.

Example:

var
  Unknown: IUnknown;
  MyInterface: IMyInterface;
begin
  Unknown := CreateComObject(CLSID_MyInterface); // success
  MyInterface := Unknown as IMyInterface; // generates the "No such
interface supported" error
  ...

I have tried it on both local and remote systems, with every concievable
combination of configurations for both properties in the "Component
Services" applet and settings in the dcomcnfg.exe utility. Also, I tried
have manually adding registry keys under HKEY_CLASSES_ROOT/AppID,
HKEY_CLASSES_ROOT/CLSID, HKEY_CLASSES_ROOT/Typelib as per described in the
Microsoft Press book COM+ Base Services.

How does my registry need to be configured to create non-dispatchable COM
plus interfaces?

To summarize:

I can get a dispatchable COM Plus component to work.
I can get a non-dispatchable component class interface to work.
I CANNOT get a non-dispatchable COM Plus component work.

What am I doing wrong? Is there more information I can provide in a followup
posting to better describe my problem?

Finally, I have a question about somthing that REALLY annoys me about
Delphi, and am hoping someone can tell me how to circumvent this "feature"
Delphi seems to exhibit. In any project after having removing the "Borland
standard VCL type library" from the uses tab of the type library editor, the
friggin code generator for the type library editor will always add the
following units to a few pascal files anytime I add-to or refresh the
implementation:

  Classes, Graphics, OleServer, OleCtrls, StdVCL

I do not want these units included (all I want is Windows and ActiveX
included in the XXX_TLB file), and am constantly forced to manually remove
them each time the implementation is refreshed. How do I prevent this from
happening?!

Anthony Walter
sys...@hotmail.com

 

Re:COM Plus straight COM interfaces don't work


I assume this is a local client calling a local COM+ component. If yes, this
should work fine. When you created your COM component, make sure that you
checked the "Include Type Library" and "Mark interface as Ole Automation"
options.

Yeah, the StdVcl, OleCtrls, OleServer, etc option is very annoying and has
been there since D3. I guess some of the Borland engineers simply don't have
this as a priority. For now, you'll need to manually modify the _TLB file
once you do a final build.

--
have fun

Binh Ly
www.techvanguards.com

Quote
"Anthon Walter" <sys...@hotmail.com> wrote in message

news:98bne9$i0i2@bornews.inprise.com...
Quote
> I can get a dispatchable COM Plus component to work.
> I can get a non-dispatchable component class interface to work.
> I CANNOT get a non-dispatchable COM Plus component work.

> What am I doing wrong? Is there more information I can provide in a
followup
> posting to better describe my problem?

> Finally, I have a question about somthing that REALLY annoys me about
> Delphi, and am hoping someone can tell me how to circumvent this "feature"
> Delphi seems to exhibit. In any project after having removing the "Borland
> standard VCL type library" from the uses tab of the type library editor,
the
> friggin code generator for the type library editor will always add the
> following units to a few pascal files anytime I add-to or refresh the
> implementation:

>   Classes, Graphics, OleServer, OleCtrls, StdVCL

> I do not want these units included (all I want is Windows and ActiveX
> included in the XXX_TLB file), and am constantly forced to manually remove
> them each time the implementation is refreshed. How do I prevent this from
> happening?!

> Anthony Walter
> sys...@hotmail.com

Re:COM Plus straight COM interfaces don't work


Binh,

I wanted to build a set of COM Plus components that used straight
(non-automation) COM interfaces with type libraries (TTypedComObject
derived). In your response you indicated that I should "Mark interface as
Ole Automation". I was hoping to use a plain COM object and not an
automation object as a COM Plus component.
I believe in the MS press book "Inside COM Plus Base Services" there are
several examples that discuss what seem to be v-table bound COM Plus
components. Is it possible to do this?

Yes, I have been trying this on both local and remote computers, but it
fails both ways as soon as the component is registered with COM Plus using
the "Component Services" applet under Windows 2000. The error I receive is
"Interface not supported". I have tried all kinds of security settings, and
even have tried manually adding many registry keys as per described in the
MS Press book for HKEY_CLASSES_ROOT under AppID, CLSID, and Typelib (with
the proper subkeys with and without a dllsurrogate). What are the exact
seeting I need to get this to work?

Anyhow, I have tried all kinds of configurations, and different computers
both local and remote and I have yet to successfully query for a
non-automation interface from a COM Plus component. I guess the question I
need to ask is:

Is it possible to successfully query for a non-automation interface from a
COM Plus component? If so, how?

Anthony Walter
sys...@hotmail.com

Re:COM Plus straight COM interfaces don't work


I think you're just confused between an "automation object" and the
"[oleautomation]" IDL tag (set by the "Mark interface as Ole Automation"
option in Delphi). An automation object is one that supports IDispatch and
is scriptable. The [oleautomation] IDL tag simply enables your interfaces to
be marshaled using the universal COM TLB marshaler - it has nothing to do
with whether your component supports IDispatch or not. The reason you have
to check that option for MTS/COM+ to work is because the COM+ runtime needs
to be able to emulate (for interception purposes) how your interfaces are
marshaled. This is not a Delphi-specific thing. Even if you create your
components in say C++, you'll still need to either enable the
[oleautomation] flag or include a PS dll that does the marshaling for your
interfaces for COM+ to work.

--
have fun

Binh Ly
www.techvanguards.com

Quote
"Anthon Walter" <sys...@hotmail.com> wrote in message

news:98ilqp$dhu5@bornews.inprise.com...
Quote
> Binh,

> I wanted to build a set of COM Plus components that used straight
> (non-automation) COM interfaces with type libraries (TTypedComObject
> derived). In your response you indicated that I should "Mark interface as
> Ole Automation". I was hoping to use a plain COM object and not an
> automation object as a COM Plus component.

Re:COM Plus straight COM interfaces don't work


Binh,

You are dead on right. I was confused between an "automation object" and the
"[oleautomation]" IDL tag. After I marked the interface "[oleautomation]"
everything worked fine. I didn't know about COM Plus's default marshalling
requirements.

Explaining (attempting to save face) ... I don't think most Delphi
programmers look at IDL in depth, and the type library editor that ships
with Delphi is pretty much a visual tool. I believe the type library editor
provides a layer (for some people) of insulation between the actual IDL
code, and the IDL structure (the treeview of the code).

Thanks

Anthony Walter
sys...@hotmail.com

Re:COM Plus straight COM interfaces don't work


A few years ago, it also took me quite a while to understand what
[oleautomation] really means. This is just a marshaling issue - not
something specific to COM+ components. If you had created your server as an
EXE server, you'd have gotten the same error.

--
have fun
Binh Ly
http://www.techvanguards.com

Quote
"Anthon Walter" <sys...@hotmail.com> wrote in message

news:98jbhs$1ku5@bornews.inprise.com...
Quote
> Binh,

> You are dead on right. I was confused between an "automation object" and
the
> "[oleautomation]" IDL tag. After I marked the interface "[oleautomation]"
> everything worked fine. I didn't know about COM Plus's default marshalling
> requirements.

> Explaining (attempting to save face) ... I don't think most Delphi
> programmers look at IDL in depth, and the type library editor that ships
> with Delphi is pretty much a visual tool. I believe the type library
editor
> provides a layer (for some people) of insulation between the actual IDL
> code, and the IDL structure (the treeview of the code).

> Thanks

> Anthony Walter
> sys...@hotmail.com

Other Threads