dual interface

[George_George]

I am also asking for this, about various ways to implement dual interface. regards, George

[CPallini]

SandipG wrote:

Do you know any?

Unfortunately, no. :sigh:

SandipG wrote:

If not i think George can write one side by side as he implements Dual Interface

Oh, he's writing the George's COM Bible! :-D

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]

modified on Friday, September 12, 2008 5:39 AM

[CPallini]

I think the standard way is just inheriting from IDispatch (since IDispatch in turn inherits from IUnknown) this way does not prevent IDispatch::Invoke to call the methods of the customized interface. :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]

[George_George]

I agree, but my implementation above is wrong and not dual interface, CPallini? regards, George

[George_George]

Just think of one more point to clarify -- we always mentioned of the dual interface access methods is -- invoke its methods through vtable. My confusion is what exactly mean "through vtable". I think it means using QueryInterface for customized interface for the coclass object, and invoke the exposed methods in the customized interface is through vtable of coclass object for the customized interface. Correct? regards, George

[CPallini]

Well, it depends on how do you implement the IDispatch interface (for instance, if your customized interface inherits both from IUnknown and IDispatch the you've a undesirable diamond inehritance path). :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]

[CPallini]

Yes, it means (1) get the IUnknown pointer (2) get the ICustomized pointer via IUnknown->QueryInterface (3) call ICustomized->WhateverMethod() (eventually perform cleanup...) on the other hand, access via IDispatch is quite different. :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]

[led mike]

SandipG :) wrote:

I think things shoudl be clear after this.

ROTFLMAO! This must be your first reply to George! :laugh::laugh::laugh:

led mike

[led mike]

Steve Echols wrote:

Been so long since I've done it, I'm a bit fuzzy on the details.

Yep, that's it, and that pretty much is the detail. ;)

led mike

[Scott Holt]

;) ;) Actually, "dual interface" refers to a COM class's ability to have its methods bound at compile time OR at run-time. Generally, all COM classes implement "custom" interfaces - after all, they do things that are specific to defined set of requirements, and are thus "custom". The COM class's methods are bound at compile time into a virtual function table, or VTABLE. For a program (client) to invoke the COM class's methods, it must have "knowledge" of the methods exported by the COM component at the time the client program itself is compiled into executable form. For applications where the COM object (server) and the client program are designed and built together, the client can easily have such "knowledge". I often develop COM servers and clients simultaneously, and my client programs have "intimate" knowledge of the names of the methods exported by the COM server. But what about client programs that want to use a COM server's methods at RUN TIME, but do not necessarily know the names and other properties of the methods exported by the COM server? This situation arises very often for scripting languages where the executable code is built "on the fly". The process whereby a client program "discovers" and uses the methods exported by a COM server is called "Run-time" binding, also known as "late" binding. This process allows scripting languages to identify what interfaces (methods) a COM class supports at run time, long AFTER the COM class has been compiled into executable code. This is done through QueryInterface and the IDispatch method. Thus, a COM class must support the IDispatch interface if it wants to allow client programs to bind to its methods at run-time. A COM class that supports IDispatch is thus said to be "dual interface" - a client program with "intimate" knowledge of its method's names and parameters can bind to it a compile time, OR the client can bind to its methods at run time via QueryInterface and IDispatch. Incidentally, "IDispatch" is aptly named because it is a method that "dispatches" a function call to the proper method within the COM server.

[George_George]

Thanks CPallini, I agree the solution you mentioned -- making my component implement a customized interface, and making the IDispatch interface should be the optimum solution. :-) regards, George

[George_George]

Thanks CPallini, Good answered. regards, George

[George_George]

Hi CPallini, Just through of another question, to implement dual interface is easy, i.e. making the component implement a customized interface, and making the customized interface inherits IDispatch. So, I think since it is easy, every COM component should implement it and be a dual interface. Why implementing dual interface is not mandatory -- i.e. for some other reasons, developer will not implement dual interface? regards, George

[George_George]

Thanks Scott, I like your long and comprehensive post. Two more comments, 1. To implement dual interface is easy, i.e. making the component implement a customized interface, and making the customized interface inherits IDispatch. So, I think since it is easy, every COM component should implement it and be a dual interface. Why implementing dual interface is not mandatory -- i.e. for some other reasons, developer will not implement dual interface? 2. For the compile time binding as you mentioned -- just clarify one point, I think COM consumer should not create and component and call its implementation method directly (call the component other than call the interface) -- but should use QueryInterface to get the interface which the COM component implements, then call the methods (using vtable) through the interface. Correct? regards, George

[George_George]

Thanks led mike, As you are here. Let me just rate your reply and ask you a question. :-) To implement dual interface is easy, i.e. making the component implement a customized interface, and making the customized interface inherits IDispatch. So, I think since it is easy, every COM component should implement it and be a dual interface. Why implementing dual interface is not mandatory -- i.e. for some other reasons, developer will not implement dual interface? regards, George

[CPallini]

George_George wrote:

Just through of another question, to implement dual interface is easy, i.e. making the component implement a customized interface, and making the customized interface inherits IDispatch. So, I think since it is easy

Most of COM components implement dual interface.

George_George wrote:

So, I think since it is easy, every COM component should implement it and be a dual interface.

(1) Is not that easy if you're doing it hand-crafting (without the help of a wizard or a framework such MFC or ATL) (2) Keeping COM requirements minimal is (IMHO) a good design approach.

George_George wrote:

i.e. for some other reasons, developer will not implement dual interface?

Because, for instance, all the clients (of the COM server they're building) are written in VTABLE binding language (like C++ or VB6 clients). AS you know VTABLE binding is more efficient than IDispatch mechanism. Final note: if you don't need a feature, why doing efforts to implement it? :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]

[CPallini]

George_George wrote:

Why implementing dual interface is not mandatory

Keeping COM requirements minimal is a good design approach IMHO (and building a dual interface is not that easy, without wizards or framework, like MFC or ATL, support).

George_George wrote:

i.e. for some other reasons, developer will not implement dual interface?

Because none of the intended clients need it (for instance C++ or VB6 clients don't need IDispatch). As you know IDispatch mechanism is less efficient than VTABLE binding. Anyway most of COM servers actually implement dual interface (by free choiche). :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]

[Scott Holt]

On point 1: I rarely implement dual interfaces because I develop COM servers and COM clients as part of a package application, and my client components always have "up front" knowledge of what the server can do. So, I typically do not implement the IDispatch interface. This results in a little less complexity in my application and improved performance. My belief is that you should only implement IDispatch if a) you are developing a COM component that you are going to make publicly available to other developers so that they might use it in their applications, or b) your COM component needs to be used by a scripting language, for example VBScript within a web page, in which case you must implement IDispatch so that the VBScript can bind to your COM component at run time (late binding). The application that I support is all written in C++ (no scripting languages) and contains no components that are intended to be available for use by other developers outside my company. On point 2: You are correct, the client should always call "QueryInterface" to get a pointer to the desired interface exported by a server, then call the methods of that interface via the pointer. Since the methods of the interface are all defined as virtual functions in C++, you are implicitly invoking the methods through the virtual function table. (Of course, virtual functions are intrinsic to the C++ language and existed long before COM was created.) :)

[George_George]

Cool, CPallini! have a good weekend, George

[George_George]

Hi CPallini, I further question. If we want to support IDispatch, all types in methods' parameter/return value must be auomtation compatible? If yes, why? :-) regards, George