dual interface
-
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] -
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:
Why implementing dual interface is not mandatory
Keeping
COMrequirements minimal is a good design approach IMHO (and building a dual interface is not that easy, without wizards or framework, likeMFCorATL, 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++orVB6clients don't need IDispatch). As you knowIDispatchmechanism is less efficient thanVTABLEbinding. Anyway most ofCOMservers 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] -
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
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 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]Cool, CPallini! have a good weekend, George
-
George_George wrote:
Why implementing dual interface is not mandatory
Keeping
COMrequirements minimal is a good design approach IMHO (and building a dual interface is not that easy, without wizards or framework, likeMFCorATL, 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++orVB6clients don't need IDispatch). As you knowIDispatchmechanism is less efficient thanVTABLEbinding. Anyway most ofCOMservers 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]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
-
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.) :)
Thanks Scott, 1. Why "you are developing a COM component that you are going to make publicly available to other developers" as you mentioned, I must expose IDisaptch? I could expose vtable only and let them use C++. :-) Any comments or any important points which I missed in my above statements? 2. 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
-
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
Because automation clients have no clue of other types. :)
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] -
Because automation clients have no clue of other types. :)
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, But can't we include the complex type definition in IDL and build the IDL into typelib and let client use the typelib? regards, George
-
Thanks CPallini, But can't we include the complex type definition in IDL and build the IDL into typelib and let client use the typelib? regards, George
AFAIK automation clients don't use
typelibs. :)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] -
AFAIK automation clients don't use
typelibs. :)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]Sorry my bad, CPallini. I always write C++ native client actually. :-) If the automation client (I think you mean client like VB or JScript) does not use typelib, what will they use to invoke? Just read some document about interface/coclass/methods signature information and use GUID or ProgID, then call IDispatch.invoke? regards, George
-
Sorry my bad, CPallini. I always write C++ native client actually. :-) If the automation client (I think you mean client like VB or JScript) does not use typelib, what will they use to invoke? Just read some document about interface/coclass/methods signature information and use GUID or ProgID, then call IDispatch.invoke? regards, George
Yes,
VBScriptclients, for instance, do something like this. :)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] -
Yes,
VBScriptclients, for instance, do something like this. :)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, Sorry we are talking about two things. :-) I mean VB -- Visual Basic. Any way, here are my questions, let us talk VB and script language (VB Script or JScript) separately. 1. Could VB client use TLB file? 2. Could script client use TLB file? 3. If I define customized type (e.g. a structure) in IDL file, use such customized type as input parameter or return type for some methods, and generate related TLB. Could VB client use such methods? 4. If I define customized type (e.g. a structure) in IDL file, use such customized type as input parameter or return type for some methods, and generate related TLB. Could script client use such methods? regards, George
-
Thanks CPallini, Sorry we are talking about two things. :-) I mean VB -- Visual Basic. Any way, here are my questions, let us talk VB and script language (VB Script or JScript) separately. 1. Could VB client use TLB file? 2. Could script client use TLB file? 3. If I define customized type (e.g. a structure) in IDL file, use such customized type as input parameter or return type for some methods, and generate related TLB. Could VB client use such methods? 4. If I define customized type (e.g. a structure) in IDL file, use such customized type as input parameter or return type for some methods, and generate related TLB. Could script client use such methods? regards, George
George_George wrote:
I mean VB -- Visual Basic. Any way, here are my questions, let us talk VB and script language (VB Script or JScript) separately.
I suppose
'VB'standing for'Visual Basic 6'.George_George wrote:
1. Could VB client use TLB file?
AFAIK Yes.
George_George wrote:
2. Could script client use TLB file?
Nope.
George_George wrote:
3. If I define customized type (e.g. a structure) in IDL file, use such customized type as input parameter or return type for some methods, and generate related TLB. Could VB client use such methods?
I don't know. :-O :-D
George_George wrote:
4. If I define customized type (e.g. a structure) in IDL file, use such customized type as input parameter or return type for some methods, and generate related TLB. Could script client use such methods?
Nope. :)
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 wrote:
I mean VB -- Visual Basic. Any way, here are my questions, let us talk VB and script language (VB Script or JScript) separately.
I suppose
'VB'standing for'Visual Basic 6'.George_George wrote:
1. Could VB client use TLB file?
AFAIK Yes.
George_George wrote:
2. Could script client use TLB file?
Nope.
George_George wrote:
3. If I define customized type (e.g. a structure) in IDL file, use such customized type as input parameter or return type for some methods, and generate related TLB. Could VB client use such methods?
I don't know. :-O :-D
George_George wrote:
4. If I define customized type (e.g. a structure) in IDL file, use such customized type as input parameter or return type for some methods, and generate related TLB. Could script client use such methods?
Nope. :)
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! For item 4, you mean for script client, if I define customized type (e.g. a structure) in IDL file, use such customized type as input parameter or return type for some methods, and generate related TLB. Script client can not use such methods? I feel surprised so confirm here again. :-) regards, George
-
Thanks CPallini! For item 4, you mean for script client, if I define customized type (e.g. a structure) in IDL file, use such customized type as input parameter or return type for some methods, and generate related TLB. Script client can not use such methods? I feel surprised so confirm here again. :-) regards, George
Scripts client use only
VARIANTdatatype only viaIDispatch. Of course, you know, this is going on my arrogant... :)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] -
Scripts client use only
VARIANTdatatype only viaIDispatch. Of course, you know, this is going on my arrogant... :)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 did some search but find no results. Do you have any documents referrals which describes whether script language could use TLB or not? regards, George
-
Thanks CPallini, I did some search but find no results. Do you have any documents referrals which describes whether script language could use TLB or not? regards, George
Oh, well no. But I'm pretty sure: VBScript & JScript (I'm not talkingt about the
.NETone) have onlyVARIANTdatatype and can only accessCOMcomponents viaIDispatch. You may have a look toVBScriptorJScriptreference documentation onMSDN. :)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] -
Oh, well no. But I'm pretty sure: VBScript & JScript (I'm not talkingt about the
.NETone) have onlyVARIANTdatatype and can only accessCOMcomponents viaIDispatch. You may have a look toVBScriptorJScriptreference documentation onMSDN. :)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 for your long help, CPallini! Let us continue to discuss here. :-) http://www.codeproject.com/script/Forums/View.aspx?fid=1647&msg=2725088[^] regards, George
-
Thanks Scott, 1. Why "you are developing a COM component that you are going to make publicly available to other developers" as you mentioned, I must expose IDisaptch? I could expose vtable only and let them use C++. :-) Any comments or any important points which I missed in my above statements? 2. 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
Yes, on point number 1...You ONLY have to support IDispatch if you want scripting languages or other languages that use late binding to be able to use to your COM server component. Of course, this is very often the case these days with so many COM components being written to plug into web sites and be called from VB script, Java script, etc. I'm sorry I should have made this more clear. So, you CAN have a COM component publicly available that does NOT support IDispatch, but it will need to be linked with the client program at compile (build) time. On point 2: YES, all parameter/return values MUST be automation compatible. Basically, this means that everything must be VARIANT, BSTR, long integer, etc. Why? Because COM is a defined standard that all programming languages that wish to be COM compliant must adhere to if they wish to interface with each other, and IDispatch is a defined interface within the standard. If you wish to use much of the automation linkage already put into place by Microsoft, and the COM subsystem (also implemented by Microsoft via Windows), you'll have to adhere to the standards of the subsystem components. For example, of you try to pass a "C-style" string from a C++ program to a VB program through a COM interface, the VB program will probably crash because it doesn't "understand" the structure of a C-style string. Incidentally, I had to read two or three books on COM and diligently work the examples before I got it figured out. I tried using ATL and the Visual Studio wizards to create my COM components, but quickly gave up on this because it was very inflexible when I wanted to make additions or changes to my COM classes. I ended up hand-building, from scratch, all of my COM components, but now I have a library of components for use in my applications. Scott :)