Hello,
I use Microsoft Device emulator standalone, which emule pocket Pc , it is
very easy. But is not a new emulator ?
I test with this one on windows xp.
But all the controls don't work correctly on Wince.
2007/5/25, Felipe Monteiro de Carvalho [EMAIL PROTECTED]:
Hi,
Is anyone using the
On 5/25/07, patrick feillant [EMAIL PROTECTED] wrote:
I use Microsoft Device emulator standalone, which emule pocket Pc , it is
very easy.
How do you run your apps on the emulator?
But is not a new emulator ?
Yes, it' s the same emulator as before, but what I ment is that they
updated the
I copied the code for socksrv.pp on pages 1056-1057 into FPC, and got a
compilation error. I double checked the code, and it is the same as
what's in the manual.
My system:
Windows XP
FreePascal IDE for Win32 for i386
Target CPU: i386
Version 1.0.8 2006/08/21
(Compiler Version
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
14 matches
Mail list logo
