I have number of C++ ATL COM controls that I have on a VBA form. I noticed
that in excel (and maybe office in general) the default interface of the COM
component has been augmented with what looks like methods and properties from
MSForms.Control. At least that's how the intellisense makes it look.
1) Can someone explain exactly what's going on here? I assume excel (or VBA)
has dynamically shimmed up some new IDispatch implementation based on the
IDispatch of my COM object and forwards calls that belong to the 'real'
IDispatch onto the COM instance itself. But this is a guess...
2) I have a problem with *one* of these controls, that the others don't seem
to suffer. I can't QI (or Set I guess in VB parlance) to the default
interface of the underlying COM component. I always get type mismatch errors.
For example, I have some interface IFoo implemented by some coclass Foo. Foo
also supports all the other COM control interfaces - or enough to be a
'control' at least. I drop a Foo onto my excel VBA form and call it XFoo.
In some code on the Form I do
Dim LFoo As Foo
Set LFoo = XFoo
and the second line results in a type-mismatch.
|
Similar Threads
