On 5/28/07, Luiz Americo Pereira Camara [EMAIL PROTECTED] wrote:
Graeme Geldenhuys wrote:
The virtual treeview has already been ported twice by two different
people. Any particular reason you are doing it again?
See the link for one of the ports...
http://tinyurl.com/2uxewm
The other one
Cesar Romero wrote:
Luiz Americo,
This was my first idea. And now gains force again. The problem is
that the bug can not be isolated easily.
Another option is that there's a mem leak in delphi also. Does some
one know how to trace a mem leak in delphi?
Use FastMM with FullDebugOptions
I
On 5/26/07, Luiz Americo Pereira Camara [EMAIL PROTECTED] wrote:
I don't have any experience with interfaces but is quite possible that
this is the case. The component i'm porting is the TVirtualTreeView that
uses extensively interfaces/COM and this part of the code is a bit complex.
The
Marc Weustink wrote:
Luiz Americo Pereira Camara wrote:
Cesar Romero wrote:
Luiz Americo,
Anyway, calling manually _Release avoid the leak and i will stay
with it for now (I hope did not break anything).
It can work for that case, but I think that is not a good ideia.
If you are using a
Luiz Americo,
This was my first idea. And now gains force again. The problem is that
the bug can not be isolated easily.
Another option is that there's a mem leak in delphi also. Does some
one know how to trace a mem leak in delphi?
Use FastMM with FullDebugOptions
[]s
Cesar Romero
I'm tracing a memory leak in a Delphi ported component and found that
the culprit was a TInterfacedObject descendant that was not being freed.
I found that if i directly call Free or _Release the memory leak
vanishes (Delphi code does not call these).
My question is: is TInterfacedObject
var
Manager: TVTDragManager;
It should be Interface.
like
var
Manager: IDropSource;
or other implemented interface
[]s
Cesar Romero
Luiz Americo Pereira Camara escreveu:
I'm tracing a memory leak in a Delphi ported component and found that
the culprit was a TInterfacedObject descendant
Cesar Romero wrote:
var
Manager: TVTDragManager;
It should be Interface.
like
var
Manager: IDropSource;
or other implemented interface
Thanks. You are right. Using Manager as IDropSource there's no leak in
the test program.
Unfortunately in the original code Manager is already an
Luiz Americo Pereira Camara wrote:
Unfortunately in the original code Manager is already an interface but
still leaking memory. It seems that is a more complex bug.
If you have two or more interfaces whose members point each other in a
circular reference scenario, without using weak
Joao Morais wrote:
Luiz Americo Pereira Camara wrote:
Unfortunately in the original code Manager is already an interface
but still leaking memory. It seems that is a more complex bug.
If you have two or more interfaces whose members point each other in a
circular reference scenario, without
Luiz Americo,
Anyway, calling manually _Release avoid the leak and i will stay with
it for now (I hope did not break anything).
It can work for that case, but I think that is not a good ideia.
If you are using a TInterfacedObject descendant, it will call the
_Release when out of context, so
Cesar Romero wrote:
- Create a Finalization method that will set one of the references to nil
Is this mandatory? I thought the compiler creates this code for global
vars as well as it creates for local vars.
--
Joao Morais
___
fpc-pascal maillist
Cesar Romero wrote:
Luiz Americo,
Anyway, calling manually _Release avoid the leak and i will stay with
it for now (I hope did not break anything).
It can work for that case, but I think that is not a good ideia.
If you are using a TInterfacedObject descendant, it will call the
_Release
Cesar Romero wrote:
Luiz Americo,
Anyway, calling manually _Release avoid the leak and i will stay with
it for now (I hope did not break anything).
It can work for that case, but I think that is not a good ideia.
If you are using a TInterfacedObject descendant, it will call the
_Release
Joao Morais escreveu:
Cesar Romero wrote:
- Create a Finalization method that will set one of the references to
nil
Is this mandatory? I thought the compiler creates this code for global
vars as well as it creates for local vars.
Just a workaround to resolve circular references issues.
Luiz Americo Pereira Camara wrote:
Cesar Romero wrote:
Luiz Americo,
Anyway, calling manually _Release avoid the leak and i will stay with
it for now (I hope did not break anything).
It can work for that case, but I think that is not a good ideia.
If you are using a TInterfacedObject
16 matches
Mail list logo
