dual interface
-
Thanks CPallini, I am a little losing the context and my English is not very good. Do you guys mean in order to implement a dual interface, - we need an additional customized interface, which implements IDispatch? - or we need implement both an additional customized interface (and the customized interface inherits from IUnknown) and also implement IDispatch? - or both the above two ways are fine? regards, George
We need a customized interface that implements (also)
IDispatch(Usually it inherits fromIDispatch, that in turn, inherits fromIUnknown). :)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] -
When you say a component implements IDispatch or IUnknown im assuming that you have an interface IX that is derived from either of those interfaces (IDispatch or IUnknown)and you are implementing those intrefaces in a coclass. 1. Any COM interface has to be derived from IUnknown. So when you implement IDispatch you also have to implement IUnknown, because IDispatch is also derived from IUnknown. Any interface,say IX, that is derived from IDispatch is a dual interface. Because IX methods can be invoked through IDispatch methods as well as vtable. 2. You can also derive your interface IX from IUnknown and invoke its methods through vtable. 3,4. Don't know what you mean by customized interface. May i suggest that you go through "Inside COM" by Dale Rogerson. It is a very good book it will help you in understanding COM much better.
Thanks sw@thi, 1. You mentioned twice about "invoke its methods through vtable". My confusion is what exactly mean "through vtable". I think you mean QueryInterface for interface IX for the coclass object, and invoke the exposed methods in IX is through vtable of coclass object for interface IX. Correct? 2.
sw@thi wrote:
3,4. Don't know what you mean by customized interface.
Customized interface I mean any C++ eligible interface which is not IDispatch and IUnknown, and in 3 the customized interface inherits IUnknown and in 4 the customized interface inherits IDispatch. From my description, do you think my points for 3 and 4 are both correct? regards, George
-
We need a customized interface that implements (also)
IDispatch(Usually it inherits fromIDispatch, that in turn, inherits fromIUnknown). :)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] -
We need a customized interface that implements (also)
IDispatch(Usually it inherits fromIDispatch, that in turn, inherits fromIUnknown). :)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]Thanks CPallini, I have one more comment, at first I agree with what you mean above. I think there is another way to implement dual interface, which is we need implement both an additional customized interface (and the customized interface inherits from IUnknown) and also implement IDispatch (in IDispatch's Invoke implementation we can call the methods from the customized interface methods' implementation)? Is that also dual interface? regards, George
-
Hi CPallini, I didn't find any simple article or example to do this on CP, which will explain steps. Do you know any? If not i think George can write one side by side as he implements Dual Interface :)
Regards, Sandip.
I am also asking for this, about various ways to implement dual interface. regards, George
-
Hi CPallini, I didn't find any simple article or example to do this on CP, which will explain steps. Do you know any? If not i think George can write one side by side as he implements Dual Interface :)
Regards, Sandip.
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
-
Thanks CPallini, I have one more comment, at first I agree with what you mean above. I think there is another way to implement dual interface, which is we need implement both an additional customized interface (and the customized interface inherits from IUnknown) and also implement IDispatch (in IDispatch's Invoke implementation we can call the methods from the customized interface methods' implementation)? Is that also dual interface? regards, George
I think the standard way is just inheriting from
IDispatch(sinceIDispatchin turn inherits fromIUnknown) this way does not preventIDispatch::Invoketo 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] -
I think the standard way is just inheriting from
IDispatch(sinceIDispatchin turn inherits fromIUnknown) this way does not preventIDispatch::Invoketo 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]I agree, but my implementation above is wrong and not dual interface, CPallini? regards, George
-
I think the standard way is just inheriting from
IDispatch(sinceIDispatchin turn inherits fromIUnknown) this way does not preventIDispatch::Invoketo 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]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
-
I agree, but my implementation above is wrong and not dual interface, CPallini? regards, George
Well, it depends on how do you implement the
IDispatchinterface (for instance, if your customized interface inherits both fromIUnknownandIDispatchthe 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] -
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
Yes, it means (1) get the
IUnknownpointer (2) get theICustomizedpointer viaIUnknown->QueryInterface(3) callICustomized->WhateverMethod()(eventually perform cleanup...) on the other hand, access viaIDispatchis 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] -
Hi George, Read this link about implementing Dual interfaces. I think things shoudl be clear after this. Dual Interface[^]
George_George wrote:
My confusion is dual means (IDispatch/IUnknown) or (IDispatch/customized interface)?
I think dual interface does not mean two interfaces its about the ways you can access methods. I hope it helps..
Regards, Sandip.
-
Dual interface refers to supporting both IDispatch and a VTBL, which means you can call it through COM using QueryInterface or from C++ directly. Been so long since I've done it, I'm a bit fuzzy on the details.
- S 50 cups of coffee and you know it's on! A post a day, keeps the white coats away!
-
I agree, but my implementation above is wrong and not dual interface, CPallini? regards, George
;) ;) 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.
-
Well, it depends on how do you implement the
IDispatchinterface (for instance, if your customized interface inherits both fromIUnknownandIDispatchthe 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]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
-
Yes, it means (1) get the
IUnknownpointer (2) get theICustomizedpointer viaIUnknown->QueryInterface(3) callICustomized->WhateverMethod()(eventually perform cleanup...) on the other hand, access viaIDispatchis 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]Thanks CPallini, Good answered. regards, George
-
;) ;) 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.
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
-
Yes, it means (1) get the
IUnknownpointer (2) get theICustomizedpointer viaIUnknown->QueryInterface(3) callICustomized->WhateverMethod()(eventually perform cleanup...) on the other hand, access viaIDispatchis 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]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
-
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
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
-
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 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
MFCorATL) (2) KeepingCOMrequirements 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
COMserver they're building) are written inVTABLEbinding language (likeC++orVB6clients). AS you knowVTABLEbinding is more efficient thanIDispatchmechanism. 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]
