IDL question and VB behavior 
Author Message
 IDL question and VB behavior

Hi
My IDL file looks like this
interface ITF0 : IUnknown
{
methodA
methodB
Quote:
}

interface ITF1 : IUnknown
{
method1
method2
Quote:
}

interface ITF2 :IDispatch  //this one is marked as dual and the default
interface
{
method1 //same as the ones in itf1
method2// same as the one in itf1

Quote:
}

coclass xyz
{
[default] interface ITF1;
interface ITF0;
Quote:
}

Does it make sense to do something like this to expose the same methods
through different interfaces?

Another question is theonce  control that is developed using the above
mechanismand used in vb as following
1)Drop the control on a form and get a instance of the coclass  xyz
variable1;.
2) in the form code I do a
 dim abc as ITF0
 set  abc = variable1
The above line fails , is there any reason why I cannot set the interface to
an object as above.

When I don't drop the control and handcode like
dim variable1 as xyz;
 dim abc as ITF0
set variable1 = new xyz
 set  abc = variable1
This works....
The code may not be syntactically correct but the idea is what I am trying
to get through is what I am doing...

Any help is appreciated
Thanx murtza



Wed, 08 Oct 2003 23:08:09 GMT  
 IDL question and VB behavior
Is it possible to use the interfaces which is derived from IUnknown and not
from IDisptach  in VB.. I think we can't


Hi
My IDL file looks like this
interface ITF0 : IUnknown
{
methodA
methodB

Quote:
}

interface ITF1 : IUnknown
{
method1
method2
Quote:
}

interface ITF2 :IDispatch  //this one is marked as dual and the default
interface
{
method1 //same as the ones in itf1
method2// same as the one in itf1

Quote:
}

coclass xyz
{
[default] interface ITF1;
interface ITF0;
Quote:
}

Does it make sense to do something like this to expose the same methods
through different interfaces?

Another question is theonce  control that is developed using the above
mechanismand used in vb as following
1)Drop the control on a form and get a instance of the coclass  xyz
variable1;.
2) in the form code I do a
 dim abc as ITF0
 set  abc = variable1
The above line fails , is there any reason why I cannot set the interface to
an object as above.

When I don't drop the control and handcode like
dim variable1 as xyz;
 dim abc as ITF0
set variable1 = new xyz
 set  abc = variable1
This works....
The code may not be syntactically correct but the idea is what I am trying
to get through is what I am doing...

Any help is appreciated
Thanx murtza



Fri, 10 Oct 2003 16:17:24 GMT  
 IDL question and VB behavior
A slight error in typing :-(..... the default is ITF2 which implements the
IDispatch
 coclass xyz
 {
 [default] interface ITF2;
 interface ITF0;
 }

Thanx Murtuza


Quote:
> Is it possible to use the interfaces which is derived from IUnknown and
not
> from IDisptach  in VB.. I think we can't



> Hi
> My IDL file looks like this
> interface ITF0 : IUnknown
> {
> methodA
> methodB
> }
> interface ITF1 : IUnknown
> {
> method1
> method2
> }
> interface ITF2 :IDispatch  //this one is marked as dual and the default
> interface
> {
> method1 //same as the ones in itf1
> method2// same as the one in itf1
> }

> coclass xyz
> {
> [default] interface ITF1;
> interface ITF0;
> }
> Does it make sense to do something like this to expose the same methods
> through different interfaces?

> Another question is theonce  control that is developed using the above
> mechanismand used in vb as following
> 1)Drop the control on a form and get a instance of the coclass  xyz
> variable1;.
> 2) in the form code I do a
>  dim abc as ITF0
>  set  abc = variable1
> The above line fails , is there any reason why I cannot set the interface
to
> an object as above.

> When I don't drop the control and handcode like
> dim variable1 as xyz;
>  dim abc as ITF0
> set variable1 = new xyz
>  set  abc = variable1
> This works....
> The code may not be syntactically correct but the idea is what I am trying
> to get through is what I am doing...

> Any help is appreciated
> Thanx murtza



Fri, 10 Oct 2003 20:44:10 GMT  
 IDL question and VB behavior
Why would you want to do that? I'd picture it like this:

dispinterface ITF2
{
    interface ITF1;

Quote:
}

Then you have a COM interface and a dispinterface, but not a
dual interface. In the presense of a dual interface, your ITF1
interface is unnecessary...

For the second question: this is a quirk of VB. What you have is
in fact a pointer to the extended control VB wraps your control
in. I vaguely remember there's a method to get the real ActiveX
control from the extended control, but I'm not a VB developer...
Ask in the VB groups on how to do this.

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD

MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================


Quote:
> Hi
> My IDL file looks like this
> interface ITF0 : IUnknown
> {
> methodA
> methodB
> }
> interface ITF1 : IUnknown
> {
> method1
> method2
> }
> interface ITF2 :IDispatch  //this one is marked as dual and the default
> interface
> {
> method1 //same as the ones in itf1
> method2// same as the one in itf1
> }

> coclass xyz
> {
> [default] interface ITF1;
> interface ITF0;
> }
> Does it make sense to do something like this to expose the same methods
> through different interfaces?

> Another question is theonce  control that is developed using the above
> mechanismand used in vb as following
> 1)Drop the control on a form and get a instance of the coclass  xyz
> variable1;.
> 2) in the form code I do a
>  dim abc as ITF0
>  set  abc = variable1
> The above line fails , is there any reason why I cannot set the interface
to
> an object as above.

> When I don't drop the control and handcode like
> dim variable1 as xyz;
>  dim abc as ITF0
> set variable1 = new xyz
>  set  abc = variable1
> This works....
> The code may not be syntactically correct but the idea is what I am trying
> to get through is what I am doing...

> Any help is appreciated
> Thanx murtza



Sat, 11 Oct 2003 04:57:16 GMT  
 IDL question and VB behavior
I guess the answer to your first is,
The way the spec defines it, the spec says something like this the class has
a default dual interface [and does not specify the methods on this dual
interface] and a devicespecific interface. I figured it makes sense that the
default interface expose the devicespecific methods too.
A part of the spec.....Should the methods for IXFSCardReader be speced [the
spec does not mention a single method on this] out or am I missing the whole
point here ?

CoClass Name :
XFSCardReader
Custom  Interfaces Supported
IXFSDevice
IXFSDeviceManagement
IXFSCardReaderSpecific
IXFSCardReaderManagement
Dual  Interfaces Supported
IXFSCardReader (main incoming)
Dispinterface   Supported
(main outgoing)
_IXFSCardReaderEvents
 VersionIndependent ProgID
ActiveXFS.CardReader

As for the second comment I am glad I did not mess my interface definitions
and it is more of a VB thing :-)
Thanx again ........and again :-)
Murtuza


Quote:
> Why would you want to do that? I'd picture it like this:

> dispinterface ITF2
> {
>     interface ITF1;
> }

> Then you have a COM interface and a dispinterface, but not a
> dual interface. In the presense of a dual interface, your ITF1
> interface is unnecessary...

> For the second question: this is a quirk of VB. What you have is
> in fact a pointer to the extended control VB wraps your control
> in. I vaguely remember there's a method to get the real ActiveX
> control from the extended control, but I'm not a VB developer...
> Ask in the VB groups on how to do this.

> --
> =====================================
> Alexander Nickolov
> Microsoft MVP [VC], MCSD

> MVP VC FAQ: http://www.mvps.org/vcfaq
> =====================================



> > Hi
> > My IDL file looks like this
> > interface ITF0 : IUnknown
> > {
> > methodA
> > methodB
> > }
> > interface ITF1 : IUnknown
> > {
> > method1
> > method2
> > }
> > interface ITF2 :IDispatch  //this one is marked as dual and the default
> > interface
> > {
> > method1 //same as the ones in itf1
> > method2// same as the one in itf1
> > }

> > coclass xyz
> > {
> > [default] interface ITF1;
> > interface ITF0;
> > }
> > Does it make sense to do something like this to expose the same methods
> > through different interfaces?

> > Another question is theonce  control that is developed using the above
> > mechanismand used in vb as following
> > 1)Drop the control on a form and get a instance of the coclass  xyz
> > variable1;.
> > 2) in the form code I do a
> >  dim abc as ITF0
> >  set  abc = variable1
> > The above line fails , is there any reason why I cannot set the
interface
> to
> > an object as above.

> > When I don't drop the control and handcode like
> > dim variable1 as xyz;
> >  dim abc as ITF0
> > set variable1 = new xyz
> >  set  abc = variable1
> > This works....
> > The code may not be syntactically correct but the idea is what I am
trying
> > to get through is what I am doing...

> > Any help is appreciated
> > Thanx murtza



Sat, 11 Oct 2003 21:19:53 GMT  
 IDL question and VB behavior
I suppose that means the decision is left up to you. A dual interface
is also a COM interface, you don't have to add a custom interface
duplicating the functionality available through the dual interface.
However, in many cases an IUnknown-derived  COM interface can
be much easier to use for low-level communication than a dual
interface (which is limited to Automation types). So the documentation
advises you to implement an inefficient, but generic dual interface
and a convenient and efficient interface for C/C++ clients. BTW,
the main difference is in passing arrays, but other differences
exist too (passing interfaces for example).

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD

MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================


Quote:
> I guess the answer to your first is,
> The way the spec defines it, the spec says something like this the class
has
> a default dual interface [and does not specify the methods on this dual
> interface] and a devicespecific interface. I figured it makes sense that
the
> default interface expose the devicespecific methods too.
> A part of the spec.....Should the methods for IXFSCardReader be speced
[the
> spec does not mention a single method on this] out or am I missing the
whole
> point here ?

> CoClass Name :
> XFSCardReader
> Custom  Interfaces Supported
> IXFSDevice
> IXFSDeviceManagement
> IXFSCardReaderSpecific
> IXFSCardReaderManagement
> Dual  Interfaces Supported
> IXFSCardReader (main incoming)
> Dispinterface   Supported
> (main outgoing)
> _IXFSCardReaderEvents
>  VersionIndependent ProgID
> ActiveXFS.CardReader

> As for the second comment I am glad I did not mess my interface
definitions
> and it is more of a VB thing :-)
> Thanx again ........and again :-)
> Murtuza



> > Why would you want to do that? I'd picture it like this:

> > dispinterface ITF2
> > {
> >     interface ITF1;
> > }

> > Then you have a COM interface and a dispinterface, but not a
> > dual interface. In the presense of a dual interface, your ITF1
> > interface is unnecessary...

> > For the second question: this is a quirk of VB. What you have is
> > in fact a pointer to the extended control VB wraps your control
> > in. I vaguely remember there's a method to get the real ActiveX
> > control from the extended control, but I'm not a VB developer...
> > Ask in the VB groups on how to do this.

> > --
> > =====================================
> > Alexander Nickolov
> > Microsoft MVP [VC], MCSD

> > MVP VC FAQ: http://www.mvps.org/vcfaq
> > =====================================



> > > Hi
> > > My IDL file looks like this
> > > interface ITF0 : IUnknown
> > > {
> > > methodA
> > > methodB
> > > }
> > > interface ITF1 : IUnknown
> > > {
> > > method1
> > > method2
> > > }
> > > interface ITF2 :IDispatch  //this one is marked as dual and the
default
> > > interface
> > > {
> > > method1 //same as the ones in itf1
> > > method2// same as the one in itf1
> > > }

> > > coclass xyz
> > > {
> > > [default] interface ITF1;
> > > interface ITF0;
> > > }
> > > Does it make sense to do something like this to expose the same
methods
> > > through different interfaces?

> > > Another question is theonce  control that is developed using the above
> > > mechanismand used in vb as following
> > > 1)Drop the control on a form and get a instance of the coclass  xyz
> > > variable1;.
> > > 2) in the form code I do a
> > >  dim abc as ITF0
> > >  set  abc = variable1
> > > The above line fails , is there any reason why I cannot set the
> interface
> > to
> > > an object as above.

> > > When I don't drop the control and handcode like
> > > dim variable1 as xyz;
> > >  dim abc as ITF0
> > > set variable1 = new xyz
> > >  set  abc = variable1
> > > This works....
> > > The code may not be syntactically correct but the idea is what I am
> trying
> > > to get through is what I am doing...

> > > Any help is appreciated
> > > Thanx murtza



Sun, 12 Oct 2003 04:00:04 GMT  
 IDL question and VB behavior
Thanx

Murtuza
p.s. apologies for the direct post

Quote:
> I suppose that means the decision is left up to you. A dual interface
> is also a COM interface, you don't have to add a custom interface
> duplicating the functionality available through the dual interface.
> However, in many cases an IUnknown-derived  COM interface can
> be much easier to use for low-level communication than a dual
> interface (which is limited to Automation types). So the documentation
> advises you to implement an inefficient, but generic dual interface
> and a convenient and efficient interface for C/C++ clients. BTW,
> the main difference is in passing arrays, but other differences
> exist too (passing interfaces for example).

> --
> =====================================
> Alexander Nickolov
> Microsoft MVP [VC], MCSD

> MVP VC FAQ: http://www.mvps.org/vcfaq
> =====================================



> > I guess the answer to your first is,
> > The way the spec defines it, the spec says something like this the class
> has
> > a default dual interface [and does not specify the methods on this dual
> > interface] and a devicespecific interface. I figured it makes sense that
> the
> > default interface expose the devicespecific methods too.
> > A part of the spec.....Should the methods for IXFSCardReader be speced
> [the
> > spec does not mention a single method on this] out or am I missing the
> whole
> > point here ?

> > CoClass Name :
> > XFSCardReader
> > Custom  Interfaces Supported
> > IXFSDevice
> > IXFSDeviceManagement
> > IXFSCardReaderSpecific
> > IXFSCardReaderManagement
> > Dual  Interfaces Supported
> > IXFSCardReader (main incoming)
> > Dispinterface   Supported
> > (main outgoing)
> > _IXFSCardReaderEvents
> >  VersionIndependent ProgID
> > ActiveXFS.CardReader

> > As for the second comment I am glad I did not mess my interface
> definitions
> > and it is more of a VB thing :-)
> > Thanx again ........and again :-)
> > Murtuza



> > > Why would you want to do that? I'd picture it like this:

> > > dispinterface ITF2
> > > {
> > >     interface ITF1;
> > > }

> > > Then you have a COM interface and a dispinterface, but not a
> > > dual interface. In the presense of a dual interface, your ITF1
> > > interface is unnecessary...

> > > For the second question: this is a quirk of VB. What you have is
> > > in fact a pointer to the extended control VB wraps your control
> > > in. I vaguely remember there's a method to get the real ActiveX
> > > control from the extended control, but I'm not a VB developer...
> > > Ask in the VB groups on how to do this.

> > > --
> > > =====================================
> > > Alexander Nickolov
> > > Microsoft MVP [VC], MCSD

> > > MVP VC FAQ: http://www.mvps.org/vcfaq
> > > =====================================



> > > > Hi
> > > > My IDL file looks like this
> > > > interface ITF0 : IUnknown
> > > > {
> > > > methodA
> > > > methodB
> > > > }
> > > > interface ITF1 : IUnknown
> > > > {
> > > > method1
> > > > method2
> > > > }
> > > > interface ITF2 :IDispatch  //this one is marked as dual and the
> default
> > > > interface
> > > > {
> > > > method1 //same as the ones in itf1
> > > > method2// same as the one in itf1
> > > > }

> > > > coclass xyz
> > > > {
> > > > [default] interface ITF1;
> > > > interface ITF0;
> > > > }
> > > > Does it make sense to do something like this to expose the same
> methods
> > > > through different interfaces?

> > > > Another question is theonce  control that is developed using the
above
> > > > mechanismand used in vb as following
> > > > 1)Drop the control on a form and get a instance of the coclass  xyz
> > > > variable1;.
> > > > 2) in the form code I do a
> > > >  dim abc as ITF0
> > > >  set  abc = variable1
> > > > The above line fails , is there any reason why I cannot set the
> > interface
> > > to
> > > > an object as above.

> > > > When I don't drop the control and handcode like
> > > > dim variable1 as xyz;
> > > >  dim abc as ITF0
> > > > set variable1 = new xyz
> > > >  set  abc = variable1
> > > > This works....
> > > > The code may not be syntactically correct but the idea is what I am
> > trying
> > > > to get through is what I am doing...

> > > > Any help is appreciated
> > > > Thanx murtza



Sun, 12 Oct 2003 04:33:32 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. IDL question - import "msxml2.idl";

2. IDL Version number changes and VB

3. Pass an ATL class to VB and IDL definition

4. Union in IDL file - client in VB - possible ?

5. SAFEARRAY and IDL defined structure to VB

6. Using VB ActiveX DLL Class in IDL

7. BOOL in VC++ IDL shows as Long in VB

8. IDL to VB

9. Should VB be able to recognize this IDL?

10. VB boolean type in IDL

11. Urgent: Weird behavior with VC++ DLL when called from a VB Custom Object

 

 
Powered by phpBB® Forum Software