Re: [fpc-pascal] Re: Windows CE emulator and console
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 new emulator? And if so, how do you test your apps? thanks, -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Windows CE emulator and console
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 operating system, and on the new one the consoles don' t work. -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] RTL Manual pages 1056-1057 code listing question
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 2.0.4) (Debugger GDB 6.2.1) The error I get on Run/Compile is: socksrv.pp(34,26) Error: Call by var parameters have to match exactly: Got ShortString expected TInetSockAddr The error I get is on the following line: if not Accept(S,FromName,Sin,Sout) then I looked in the manual, and it defines Accept as follows: function Accept(Sock: LongInt;var Addr;var Addrlen: LongInt) : LongInt function Accept(Sock: LongInt;var addr: TInetSockAddr;var SockIn: File of ;var SockOut: File of ) : Boolean function Accept(Sock: LongInt;var addr: TInetSockAddr;var SockIn: text;var SockOut: text) : Boolean function Accept(Sock: LongInt;var addr: String;var SockIn: text;var SockOut: text) : Boolean function Accept(Sock: LongInt;var addr: String;var SockIn: File of ;var SockOut: File of ) : Boolean Based on the code, it appears that the example code is trying to use fourth definition, but the compiler appears to be expecting the third definition. I have experience with Delphi, and have used it in the past to write socket based code. I just don't have experience with FPC. Any help you can give as to why the code from the manual isn't working would be appreciated. Thanks in advance Rick PS: I searched the archives before posting. If this is a repost, please accept my apologies. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Usage of TInterfacedObject. Automatic release?
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 descendants supposed to be freed
automatically or should i call Free directly?
See attached example.
Using fpc 2.1.4 under win32 XP SP2.
Luiz
program interfaceleak2;
{$mode delphi}
uses
Heaptrc, Windows, Activex, Classes, SysUtils;
type
TVTDragManager = class(TInterfacedObject, IDropSource)
public
constructor Create(AOwner: TComponent); virtual;
destructor Destroy; override;
function GiveFeedback(Effect: Integer): HResult; stdcall;
function QueryContinueDrag(EscapePressed: BOOL; KeyState: Integer): HResult; stdcall;
end;
constructor TVTDragManager.Create(AOwner: TComponent);
begin
inherited Create;
end;
destructor TVTDragManager.Destroy;
begin
WriteLn('Destroy');
inherited Destroy;
end;
function TVTDragManager.GiveFeedback(Effect: Integer): HResult;
begin
end;
function TVTDragManager.QueryContinueDrag(EscapePressed: BOOL; KeyState: Integer
): HResult;
begin
end;
var
Manager: TVTDragManager;
begin
Manager := TVTDragManager.Create(nil);
WriteLn('Start');
//Manager.Free;
end.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Usage of TInterfacedObject. Automatic release?
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 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 descendants supposed to be freed automatically or should i call Free directly? See attached example. Using fpc 2.1.4 under win32 XP SP2. Luiz ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Usage of TInterfacedObject. Automatic release?
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 interface but still leaking memory. It seems that is a more complex bug. Thanks anyway. If i find how to isolate this bug i will report it. For now using _Release. Luiz ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Usage of TInterfacedObject. Automatic release?
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 reference, you will have memory leakage. -- Joao Morais ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Usage of TInterfacedObject. Automatic release?
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 using weak reference, you will have memory leakage. Thanks. 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. Anyway, calling manually _Release avoid the leak and i will stay with it for now (I hope did not break anything). Luiz ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Usage of TInterfacedObject. Automatic release?
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 in that especific case seems to never go out of context, and then you _realease call works, but in other place it can go out of context before, and the you will have others AV. - As Joao suggest, the best way is create a weak reference, where when 2 objects need to reference each other one should use Pointer to hold one reference - Avoid circular reference - Create a Finalization method that will set one of the references to nil []s Cesar Romero ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Usage of TInterfacedObject. Automatic release?
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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Usage of TInterfacedObject. Automatic 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 when out of context, so in that especific case seems to never go out of context, and then you _realease call works, but in other place it can go out of context before, and the you will have others AV. - As Joao suggest, the best way is create a weak reference, where when 2 objects need to reference each other one should use Pointer to hold one reference - Avoid circular reference The problem here is that i'm using a third party design. And the code complexity allied with my inexperience with interfaces/COM makes the chance of breaking things big. Anyway i did not find, with my limitations, any circular references between interfaces. Exists a circular reference but is between an Interface (IVTDragManager) and a TVirtualTreeView(TCustomControl) already used as a weak reference (TObject). The design is more or less the following: TBaseVirtualTree holds a reference to a IVTDragManager. TVTDragManager (IVTDragManager) holds a reference to TBaseVirtualTree stored in a TObject field TVTDragManager also holds reference for IDataObject (TVTDataObject) and IDropTargetHelper (returned by a win32 call) TVTDataObject holds a reference to TBaseVirtualTree as a TObject There are two circular references: TVTDragManager - TBaseVirtualTree TBaseVirtualTree - TVTDragManager TVTDataObject TBaseVirtualTree if someone is interested. the code is here: http://lazarus-ccr.svn.sourceforge.net/viewvc/lazarus-ccr/components/virtualtreeview-unstable/units/win32/virtualdragmanager.pas?view=log - Create a Finalization method that will set one of the references to nil Its already done. But the problem is that this finalization code is not called (is inside the Interface Destroy). And setting the interface reference to nil inside TBaseVirtualTree.Destroy does not help. Luiz ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Usage of TInterfacedObject. Automatic 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 when out of context, so in that especific case seems to never go out of context, and then you _realease call works, but in other place it can go out of context before, and the you will have others AV. I just realized that the current design is relatively safe. If the interface goes out of context before the call to _Release, the referenced object will be set to nil. This will prevent a second call to _Release. Is not the ideal but i'll stay with it for now. Thanks for Cesar and Joao for all that info. Luiz ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Usage of TInterfacedObject. Automatic 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. []s Cesar ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Usage of TInterfacedObject. Automatic release?
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 descendant, it will call the _Release when out of context, so in that especific case seems to never go out of context, and then you _realease call works, but in other place it can go out of context before, and the you will have others AV. - As Joao suggest, the best way is create a weak reference, where when 2 objects need to reference each other one should use Pointer to hold one reference - Avoid circular reference The problem here is that i'm using a third party design. And the code complexity allied with my inexperience with interfaces/COM makes the chance of breaking things big. Anyway i did not find, with my limitations, any circular references between interfaces. Exists a circular reference but is between an Interface (IVTDragManager) and a TVirtualTreeView(TCustomControl) already used as a weak reference (TObject). The design is more or less the following: TBaseVirtualTree holds a reference to a IVTDragManager. TVTDragManager (IVTDragManager) holds a reference to TBaseVirtualTree stored in a TObject field TVTDragManager also holds reference for IDataObject (TVTDataObject) and IDropTargetHelper (returned by a win32 call) TVTDataObject holds a reference to TBaseVirtualTree as a TObject There are two circular references: TVTDragManager - TBaseVirtualTree TBaseVirtualTree - TVTDragManager TVTDataObject TBaseVirtualTree Circular references of object is not the problem, you should look at circular references of interfaces. However, I don't expect that this is the case for the virtualtree. THat you need a _release for fpc and not for delphi sounds like a bug in fpc. (only where) Normally you never ever have to call _release yourself (unless you called _addref yourself) Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
