Is it possible to decide at run-time which interface a coclass supports?   

Hello,

I want to write a coclass that always supports a certain interface (called 
ICamera) but may also support additional interfaces (like 
ILiveimageSupport, IExternalTriggerSupport, ...). Because my camera may be 
connected to framegrabber boards of different manufacturers my objects 
cannot tell which interfaces they support at compile time. 
So what I'm asking is: Is it legal to support more interfaces than the 
coclass-section in the IDL-file suggests? And can these additional 
interfaces be used by environments other than C++, especially Visual 
Basic?

date: 15 Nov 2005 14:05:06 GMT   author:   unknown

Re: Is it possible to decide at run-time which interface a coclass supports?   

wrote in message news:dlcpui$iig$1@news.dtag.de
> So what I'm asking is: Is it legal to support more interfaces than the
> coclass-section in the IDL-file suggests?

Perfectly legal.

> And can these additional
> interfaces be used by environments other than C++, especially Visual
> Basic?

Sure, as long as they are automation compatible. The interfaces 
themselves must be described in the type library, but do not have to be 
listed in a coclass.

In VB, you can declare a variable of interface type. Simply assigning an 
object reference to such a variable performs a QueryInterface call 
internally.
-- 
With best wishes,
    Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not 
necessarily a good idea. It is hard to be sure where they are going to 
land, and it could be dangerous sitting under them as they fly 
overhead. -- RFC 1925

date: Tue, 15 Nov 2005 08:19:15 -0500   author:   Igor Tandetnik

Re: Is it possible to decide at run-time which interface a coclass supports?   

Quote from IUnknown::QueryInterface documentation:
<<
The set of interfaces accessible on an object through 
IUnknown::QueryInterface must be static, not dynamic. This means that if a 
call to QueryInterface for a pointer to a specified interface succeeds the 
first time, it must succeed again, and if it fails the first time, it must 
fail on all subsequent queries.
>>
I would suggest to add GetLiveImage and GetExternalTriggerSuppot functions 
or respective properties to Camera interface. If you want to support Visual 
Basic clients it is better to return S_OK and respective object (interface) 
= Nothing (null) .

 wrote in message news:dlcpui$iig$1@news.dtag.de...
> Hello,
>
> I want to write a coclass that always supports a certain interface (called
> ICamera) but may also support additional interfaces (like
> ILiveimageSupport, IExternalTriggerSupport, ...). Because my camera may be
> connected to framegrabber boards of different manufacturers my objects
> cannot tell which interfaces they support at compile time.
> So what I'm asking is: Is it legal to support more interfaces than the
> coclass-section in the IDL-file suggests? And can these additional
> interfaces be used by environments other than C++, especially Visual
> Basic?

date: Wed, 16 Nov 2005 15:50:24 +0200   author:   Max please@newsgroup

Re: Is it possible to decide at run-time which interface a coclass supports?   

Max wrote:
> 
> The set of interfaces accessible on an object through
> IUnknown::QueryInterface must be static, not dynamic. This means that if a
> call to QueryInterface for a pointer to a specified interface succeeds the
> first time, it must succeed again, and if it fails the first time, it must
> fail on all subsequent queries.

Perhaps my posting was a bit confusing: I want that instances from my
coclass can decide at run-time which interfaces to export. That means
when asked by QueryInterface each instance will perform some checks (for
example if the camera is connected to the right kind of framegrabber)
and reject or satisfy the interface request. Once it has decided to give
out one sort of interface pointers it will do so in future requests.
Another instance of the same coclass my decide never to export this
interface.

date: Wed, 16 Nov 2005 16:25:26 +0100   author:   Stefan Ensslen

Re: Is it possible to decide at run-time which interface a coclass supports?   

If I understand correct, Microsoft discourage such implementation, but, 
certainly, if the client application is awair of such behaviour it might be 
Ok.

Additional point in my message was that usually Visual Basic clients do not 
handle HRESULT values other then S_OK. It requires  On Error GoTo ... 
handling. That is why if you want to design something for use in Visual 
Basic it is better to implement functions that always return S_OK and 
provide error information in other ways.

And one more thing. If I remember correct, Visual Basic does not use 
IUnknown::QueryInterface. It uses IDispatch::Invoke to call methods and 
properties.

"Stefan Ensslen"  wrote in message 
news:437B4F66.30249223@web.de...
> Max wrote:
>>
>> The set of interfaces accessible on an object through
>> IUnknown::QueryInterface must be static, not dynamic. This means that if 
>> a
>> call to QueryInterface for a pointer to a specified interface succeeds 
>> the
>> first time, it must succeed again, and if it fails the first time, it 
>> must
>> fail on all subsequent queries.
>
> Perhaps my posting was a bit confusing: I want that instances from my
> coclass can decide at run-time which interfaces to export. That means
> when asked by QueryInterface each instance will perform some checks (for
> example if the camera is connected to the right kind of framegrabber)
> and reject or satisfy the interface request. Once it has decided to give
> out one sort of interface pointers it will do so in future requests.
> Another instance of the same coclass my decide never to export this
> interface.

date: Thu, 17 Nov 2005 11:40:11 +0200   author:   Max please@newsgroup

Re: Is it possible to decide at run-time which interface a coclass supports?   

"Max" <please@newsgroup> wrote in message
news:uAYLor16FHA.1484@tk2msftngp13.phx.gbl
> And one more thing. If I remember correct, Visual Basic does not use
> IUnknown::QueryInterface. It uses IDispatch::Invoke to call methods
> and properties.

VB supports both early and late binding. In the former case, it does use 
QueryInterface and does call methods via vtable.
-- 
With best wishes,
    Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not 
necessarily a good idea. It is hard to be sure where they are going to 
land, and it could be dangerous sitting under them as they fly 
overhead. -- RFC 1925

date: Thu, 17 Nov 2005 07:54:14 -0500   author:   Igor Tandetnik