The text at the end of this message is excerpted from a log file. It
documents calls to the CComObjectRootEx<BlahBlah>::OuterQueryInterface
function on the controlled part of the aggregate.
Both fragments are created during the script's call to get the subordinate
object from the parent object. The JavaScript call does some harmless
stuff, then QI's for IDispatch. This immediately navigates the interface
owned by the script from the controlled part (which was returned by the
ActiveX) back to the controlling part of the aggregate. The VBScript call
doesn't QI for IDispatch, and the interface owned by the script remains the
controlled part of the aggregate.
Questions:
Is it a bug in VBScript or JavaScript, that one does this and the other
doesn't?
Is this a failure of our aggregate object to live up to some part the rules
of COM? of Scripting?
Can anyone tell me what the mystery interfaces are? I can't track them
down.
We'll redesign or reimplement to work around the problem, but this was a bit
surprising, and I'd appreciate any information about this.
Thanks,
Bob Cram
rc...@siebel.com
START JAVASCRIPT
In ChildChild:OuterQueryInterface::Interface
{719C3050-F9D3-11CF-A493-00400523A8A0}
In ChildChild:OuterQueryInterface::Interface
{A6EF9860-C720-11D0-9337-00A0C90DCAA9}
In ChildChild:OuterQueryInterface::Interface
{A0AAC450-A77B-11CF-91D0-00AA00C14A7C}
In ChildChild:OuterQueryInterface::IID_IDispatch
END JAVASCRIPT
START VBSCRIPT
In ChildChild:OuterQueryInterface::Interface
{A6EF9860-C720-11D0-9337-00A0C90DCAA9}
In ChildChild:OuterQueryInterface::Interface
{A6EF9860-C720-11D0-9337-00A0C90DCAA9}
END VBSCRIPT