Max wrote:
> In certian situation you may not want IFirstDescendant to be available
> if ISecondDescendant is available, and so Delphi's behaviour is
> actually to your benefit as it allow comlpete control over exactly
> what interfaces an object makes available to QueryInterface. It is
> always better to have this sort of thing declarative tather then
> implicit.
Hmmm. I'd like to hear of a situation where you wouldn't want an ancestor
interface to be available where the descendant is. I think it was a mistake
of Borland not to include ancestor interfaces automatically. After all, you
can still obtain an ancestor interface by querying its descendant.
For example, you can obtain an IFirstDescendant of NewObject as follows:
var Descendant: IFirstDescendant;
NewObject.QueryInterface(ISecondDescendant, Descendant);
But that's a pain when you're trying to do it generically.
if NewObject.QueryInterface(IFirstDescendant, Descendant) <> 0 then
if NewObject.QueryInterface(ISecondDescendant, Descendant) <> 0 then
// Repeat for all descendants of IFirstDescendant, and descendants of
those descendants, ad nauseum
Descendant = nil;
// And don't forget to update this code every time you create a new
interface descendant
So the best workaround, as discussed, is still to include IFirstInterface in
your object definition (if you can).
Trevor wrote:
> Have you tried
>
> if Supports(aObject, IFirstInterface,oFirstInterface)
Supports just indirectly calls QueryInterface. It can be convenient, but be
careful when combining Supports with TInterfacedObject. The following code,
similar to that above, does NOT work if NewObject does not explicitly
support IFirstDescendant:
if not Supports(NewObject, IFirstDescendant, Descendant) then
if not Supports(NewObject, ISecondDescendant, Descendant) then
Descendant = nil;
because if there are no other interfaces on NewObject, and no other AddRefs,
then NewObject is freed when the first call fails. That's because Supports
internally grabs an IUnknown interface to the object, which falls out of
scope at the end of the function. So the reference count is incremented,
then decremented, and the object is destroyed.
Cheers,
Carl
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED]
with body of "unsubscribe delphi"
Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/
