>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
