Try this nasty example (excuse the syntax etc )
function TMyObject. _Release: Integer; stdcall;
begin
If FMyInterface.RefCount > 1 then //Still plenty of references, just decrement
count
FMyInterface._Release // Assumes FMyInterface is declared in TMyObject as the
// delegation object with the required interface
else begin
FMyInterface._Release; // This will cause MyInterface to destroy itself
// or use FMyInterface := nil // This is better in D3/D4 - it also calls _release and
ensures you can test for nil to see if we still have a delegation object.
Destroy; // Get rid of myself as well.
end;
end;
If using D4 I tend to put stuff in BeforeDestruction to release/destroy the delegation
object just in case the reference counts have been stuffed up and I know it's no
longer required as the holder object is about to destory itself. This help stop AV's
and stackoverflows on destruction, especially if message handling/waiting can be
involved.
Myles.
-----Original Message-----
From: Aaron Scott-Boddendijk [SMTP:[EMAIL PROTECTED]]
Sent: Monday, April 12, 1999 2:21 PM
To: Multiple recipients of list delphi
Subject: Re: [DUG]: Interfaces Again ;)
>If you have done it right, there should not be a problem.
>In your example, when you create your delegation object -
>In your TMyOBject.Create you need to have a ._addref on
>your delegation object, ie >TMyOBject holds a reference to your object.
>
>When TMyObject is destroyed, in it's destructor you do a
>_release - actually with D3/D4 you assign nil to your reference
>which then calls >_release for you, hence you delegated
>object is then destroyed when it's holder object is destroyed -
>or you specifically destroy the delegation object - be careful
>here with AV's. So the problem then boils down to a normal
>lifecycle maintenance of your holder object.
>Your example X := TMyObject.Create; is not what I would recommend.
>You could perhaps fudge it in that when ITesting calls _release -
>when it goes out of scope in your simple example, in
>TMyObject._release you could check and see if it will cause
>the delegation object to be destroyed and then destroy yourself
>(Not very nice but can work).
>Does that all make sense??
It appears that it's not practical to add reference counting to a non-interfaced
object by creating a descendant with the iunknown interface delegated then
since the interface release only releases the delegated object. Is there some
trick I'm missing. Man, this could really use some detailed example code...
I'm still pretty sketchy on the management of reference counted instances
that delegate instances since you can't drop a parent reference after handing
the instance on to a reference of one of the delegated types since you then
cause the wrapper instance to be released. The frightening part is the delegated
portion keeps on trucking all on its lonesome.
--
Aaron Scott-Boddendijk
Jump Productions
(07) 838-3371 Voice
(07) 838-3372 Fax
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
application/ms-tnef
