On 18/08/16 10:53, Graeme Geldenhuys wrote:
I think you are getting confused between TObject and TInterfaceObject
instances, and what is required from both.
No, the problem is that I could not find a way of achieving what I
wanted to achieve. That is ensuring that an interfaced object that used
On 2016-08-10 16:47, Tony Whyman wrote:
> You are explicitly freeing MyClass. My point is that with reference
> counted interfaces and in the example I posted, you shouldn't have to
> explicitly free the delegated interface. It should be freed
> automatically as soon as it goes out of scope.
Le
On Wed, Aug 17, 2016 at 1:03 PM, Tony Whyman
wrote:
> I think that I have now found why the test program below (originally posted
> a couple of weeks ago) did not work. It seems that when an interface is
> delegated, the compiler may take a reference directly on the delegated part
> of the interfa
I think that I have now found why the test program below (originally
posted a couple of weeks ago) did not work. It seems that when an
interface is delegated, the compiler may take a reference directly on
the delegated part of the interface and not to the object doing the
delegation.
In my or
Graeme,
You are explicitly freeing MyClass. My point is that with reference
counted interfaces and in the example I posted, you shouldn't have to
explicitly free the delegated interface. It should be freed
automatically as soon as it goes out of scope.
Tony Whyman
MWA
On 10/08/16 16:43, Gr
On 2016-08-10 13:42, Tony Whyman wrote:
> In the example, TMyClass is the interface class doing the delegation and
> while TDelegateClass is being destroyed when it goes out of scope,
> TMyClass is not.
Maybe I'm missing something, but here is a quick example I put together.
Testing with FPC 2.6
On Wed, Aug 10, 2016 at 11:08 AM, Tony Whyman
wrote:
> On 10/08/16 15:05, Marco van de Voort wrote:
>>
>> The way how Tony passes owner is wrong and that messes up reference
>> counting.
>>
>> If in the test he would do TMyclass.Create(Tsomeclass.create); it
>> probably
>> would be ok.
>
>
> But
On 10/08/16 15:05, Marco van de Voort wrote:
The way how Tony passes owner is wrong and that messes up reference
counting.
If in the test he would do TMyclass.Create(Tsomeclass.create); it probably
would be ok.
But in my test, the code reads:
Intf := TMyClass.Create(TDelegateClass.Create)
In our previous episode, Marcos Douglas said:
> On Wed, Aug 10, 2016 at 10:04 AM, Tony Whyman
> > Destroying FMyInterface in the destructor does not make a difference -
> > mainly because the TMyClass destructor is not being called anyway.
>
> It should be called, but is not. Strange.
> I tried to
On Wed, Aug 10, 2016 at 10:04 AM, Tony Whyman
wrote:
>
> ...
>
> Destroying FMyInterface in the destructor does not make a difference -
> mainly because the TMyClass destructor is not being called anyway.
It should be called, but is not. Strange.
I tried to change the code to not using Applicatio
On 10/08/16 13:57, Marcos Douglas wrote:
Hi,
See the "problem" bellow:
TMyClass = class(TInterfacedObject, IMyInterface)
private
FMyInterface: TDelegateClass; <<< HERE >>>
property MyInterface: TDelegateClass
read FMyInterface implements IMyInterface;
public
co
Marcos,
Thanks for the suggestions, but I had already tried the first variation:
TMyClass = class(TInterfacedObject, IMyInterface)
private
FMyInterface: IMyInterface; // class type
property MyInterface: IMyInterface
read FMyInterface implements IMyInterface;
public
Hi,
See the "problem" bellow:
TMyClass = class(TInterfacedObject, IMyInterface)
private
FMyInterface: TDelegateClass; <<< HERE >>>
property MyInterface: TDelegateClass
read FMyInterface implements IMyInterface;
public
constructor Create(obj: TDelegateClass);
destr
I'm using fpc 3.0.0 and trying to debug a program using COM interfaces.
While reference counting seems to be working fine, there is one
exception, that is when an interface is being used by delegation. In
this case, the object doing the delegation does not seem to be reference
counted. Is this
14 matches
Mail list logo
