Re: dual interface - C / C++ / MFC Discussion Boards

I agree, Scott!

One more question, long integer you mean what data type? Could you write the related name in source codes (C++ and IDL) please?

regards,
George

In C/C++, a long integer is a four-byte integer value. If you study the valid values for the 'vt' member of a VARIANT (type of variant), you'll notice that the values for four-byte integer are 'VT_I4' (signed four-byte integer) and 'VT_UI4' (unsigned four-byte integer). I'm not sure how VB and C# let you set the variant type, but C++ has a '_variant_t' class that wraps VARIANT and has assignment operators that set it for you, or you can simply set it yourself.

In C++, a long integer variable is declared as:

long lMyVariable = 0 ;

In IDL, you use the "long" keyword, as in these examples:

[id(65), helpstring("Load an account from the database for a specific EMS/ambulance run.")]
HRESULT LoadForRun(
[in] long lAmbRunID,
[out] long* plAccountID) ;

[id(43), helpstring("Get the first condition indicator for an EMS/ambulance run.")]
HRESULT GetFirstConditionIndicator(
[out, string] BSTR* pbstrConditionIndicator,
[out] long* plConditionIndicatorID) ;

Notice that the parameters are of type "BSTR" and "long" (the asterisk, of course, means that a given parameter is actually a pointer to a BSTR or a long).

Scott
Smile | :)

Thanks Scott,

What do you want to express by the below statements? C# and VB does not support 4-byte integer or??

--------------------
In C/C++, a long integer is a four-byte integer value. If you study the valid values for the 'vt' member of a VARIANT (type of variant), you'll notice that the values for four-byte integer are 'VT_I4' (signed four-byte integer) and 'VT_UI4' (unsigned four-byte integer). I'm not sure how VB and C# let you set the variant type,
--------------------

regards,
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

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.
Smile | :)

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

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 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?
Smile | :)

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 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).
Smile | :)

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? Smile | :)

regards,
George

Because automation clients have no clue of other types.
Smile | :)

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

AFAIK automation clients don't use typelibs.
Smile | :)

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. Smile | :)

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, VBScript clients, for instance, do something like this.
Smile | :)

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. Smile | :)

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. Blush | :O

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. Smile | :)

regards,
George

Scripts client use only VARIANT datatype only via IDispatch.

Of course, you know, this is going on my arrogant...
Smile | :)

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

Oh, well no. But I'm pretty sure: VBScript & JScript (I'm not talkingt about the .NET one) have only VARIANT datatype and can only access COM components via IDispatch.
You may have a look to VBScript or JScript reference documentation on MSDN.
Smile | :)

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. Smile | :)

http://www.codeproject.com/script/Forums/View.aspx?fid=1647&msg=2725088[^]

regards,
George

Thanks Sandip,

I am a little losting the context you are talking about. Do you 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

SandipG wrote:
I think things shoudl be clear after this.

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

led mike