Re: [Lazarus] Maybe a bug: click on TImage behind another control with SetShape
Here is it: http://bugs.freepascal.org/view.php?id=20381 2014-11-21 22:24 GMT-02:00 Fabio Luis Girardi fluisgira...@gmail.com: I found this bug on bug tracker. I followed your idea and send a patch that solves this. I'll try another approach tomorrow. Thank you very much! Em 21/11/2014 20:48, Frederic Da Vitoria davito...@gmail.com escreveu: 2014-11-21 16:01 GMT+01:00 Frederic Da Vitoria davito...@gmail.com: 2014-11-20 19:21 GMT+01:00 Fabio Luis Girardi fluisgira...@gmail.com: I don't know if this is a bug or not. I created a control from a TCustomControl that draws a polyline with a transparent background. The transparent effect has been using SetShape procedure using a bitmap of 1 bit color depth. The bug (I don't know if this is a bug) is that a TImage behind of a instance of my polyline control don't receive the click messages, but a TButton instance receives. So, I don't know if this is a bug or I have to do something in my control to send these messages to TImage behind. I had once a similar issue with a tPanel behind another control, in Delphi. IIRC, I indeed had to forward the messages in some way to the tPanel. I can check in my archives, if you want, but I won't be able to do it before tomorrow. I just checked. Sorry, my memory was wrong, I did use TButtons. But it makes sense that the uppermost control would prevent any deeper control from receiving clicks, even if the uppermost control is visually transparent. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- The best regards, Fabio Luis Girardi PascalSCADA Project http://sourceforge.net/projects/pascalscada http://www.pascalscada.com -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Maybe a bug: click on TImage behind another control with SetShape
I may be wrong, but this seems different from the problem you are describing: in the bugtracker issue, the click triggers the Form handler instead of being sent to a Control. In your problem, from your description, I thought the click triggered the polyline control while you would have wanted it to be handled by the TImage which is behind the polyline. In a way, your problem is not enough transparency (in terms of who gets to handle the click event) while the bugtracker bug is too much transparency. Or did I misunderstand you? 2014-11-22 10:01 GMT+01:00 Fabio Luis Girardi fluisgira...@gmail.com: Here is it: http://bugs.freepascal.org/view.php?id=20381 2014-11-21 22:24 GMT-02:00 Fabio Luis Girardi fluisgira...@gmail.com: I found this bug on bug tracker. I followed your idea and send a patch that solves this. I'll try another approach tomorrow. Thank you very much! Em 21/11/2014 20:48, Frederic Da Vitoria davito...@gmail.com escreveu: 2014-11-21 16:01 GMT+01:00 Frederic Da Vitoria davito...@gmail.com: 2014-11-20 19:21 GMT+01:00 Fabio Luis Girardi fluisgira...@gmail.com: I don't know if this is a bug or not. I created a control from a TCustomControl that draws a polyline with a transparent background. The transparent effect has been using SetShape procedure using a bitmap of 1 bit color depth. The bug (I don't know if this is a bug) is that a TImage behind of a instance of my polyline control don't receive the click messages, but a TButton instance receives. So, I don't know if this is a bug or I have to do something in my control to send these messages to TImage behind. I had once a similar issue with a tPanel behind another control, in Delphi. IIRC, I indeed had to forward the messages in some way to the tPanel. I can check in my archives, if you want, but I won't be able to do it before tomorrow. I just checked. Sorry, my memory was wrong, I did use TButtons. But it makes sense that the uppermost control would prevent any deeper control from receiving clicks, even if the uppermost control is visually transparent. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On Sat, 22 Nov 2014 03:14:39 -0300 Flávio Etrusco flavio.etru...@gmail.com wrote: On Fri, Nov 21, 2014 at 10:33 PM, Mattias Gaertner nc-gaert...@netcologne.de wrote: On Fri, 21 Nov 2014 23:51:13 +0100 Mattias Gaertner nc-gaert...@netcologne.de wrote: (...) Without the AVs you can see the mem leaks. I fixed the three mem leaks. Here's a patch to change the Append method, just in case ;-) That is a design decision. That is up to Joost and Martin to decide. You may want to create a bug report. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Need suggestion about html text in Hint window
Hello, How to show html text in TPopupNotifier component or THintwindow? Thank you. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
Why do you want to pass the record instead of the pointer? The pointer is valid during the entire call (inside Append). Append does not store the pointer, but a copy of the data. So this is save. Passing the pointer saves the need to pass the entire record by value (or in other word, to make a mem copy (or registers) of the entire record) when passing to the function. Which would meant that the data would be copied twice, as it is once copied in inside the Append function anyway. The param could be const/constref instead of pointer. But as the argument is already pointer, why? Please mail how to get the mem leak, and why this fixes it. On 22/11/2014 06:14, Flávio Etrusco wrote: On Fri, Nov 21, 2014 at 10:33 PM, Mattias Gaertner nc-gaert...@netcologne.de wrote: On Fri, 21 Nov 2014 23:51:13 +0100 Mattias Gaertner nc-gaert...@netcologne.de wrote: (...) Without the AVs you can see the mem leaks. I fixed the three mem leaks. Here's a patch to change the Append method, just in case ;-) Best regards, Flávio -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On Sat, 22 Nov 2014 11:27:30 + Martin Frb laza...@mfriebe.de wrote: Why do you want to pass the record instead of the pointer? [...] The param could be const/constref instead of pointer. The patch passes the parameter as const. But as the argument is already pointer, why? Someone may be too lazy to read Append and think Append stores the pointer instead of copying the content. There was such a case in the code, creating a mem leak. I fixed that yesterday. With a const record parameter this could not happen. Psychology. ;) Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On 22/11/2014 01:33, Mattias Gaertner wrote: On Fri, 21 Nov 2014 23:51:13 +0100 Mattias Gaertner nc-gaert...@netcologne.de wrote: On Fri, 21 Nov 2014 16:31:26 +0100 Reimar Grabowski reimg...@web.de wrote: [...] Create new project - run - stop - AV. The Assembler window initialized only if it was not docked. I fixed that. The AV is gone. Then I got an AV when closing the IDE. The destructor didn't clean up the queued async calls. I fixed that. Without the AVs you can see the mem leaks. I fixed the three mem leaks. I have no idea what the code is doing. Hopefully I didn't break anything. Look ok to me. In fact I had seen a mem leak in the disassembler before, but never been able to reproduce (or find). Might have been the one fixed in Revision: 46954 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need suggestion about html text in Hint window
On Sat, 22 Nov 2014 12:47:56 +0200 FreeMan freema...@delphiturkiye.com wrote: Hello, How to show html text in TPopupNotifier component or THintwindow? Create a THinWindow and insert a html control. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
I have been switching back and forth between gdb and the new one - both have some issues. The one I noticed most recently with the new one is with a multi threaded application - a break set in the thread seem to cause the debugger to become lost. Is the debugger set up to cope in this situation? (I will often turn off the multi threading for debugging, but this is not always possible.) Colin -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Compilation of .../test/testresult-db/importtestresults.lpi
Compilation of .../test/testresult-db/importtestresults.lpi is giving Error: Error while linking Error reason is as follows : /usr/bin/ld: warning: link.res contains output sections; did you forget -T? /usr/bin/ld: cannot find -lmysqlclient Error: Error while linking ERROR: failed compiling of project /home/s/Testing_Lazarus/test/testresult-db/importtestresults.lpi Some Linux distributions are not supplying MySQL any more . Therefore there is no any mysqlclient . Thank you very much . Mehmet Erol Sanliturk -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Maybe a bug: click on TImage behind another control with SetShape
I think that we aren't talking about the same thing. I think that a transparent control must retain clicks to another controls if it is uppermost and in front of these controls. I think that this is correct. Polyline is a different control. The area of line is the area of the control, other area will be full transparent and must pass the events to controls behind. If you click on line, the click must be fired on Polyline object, otherwise, it must be fired on the first control behind of polyline. The bug here is: I have two TImages and one polyline. The uppermost is TImage is positioned in a removed area (transparent) of polyline and the other TImage is the background. When I click on uppermost TImage click isn't fired on it nor on background TImage. It's fired on TForm! The same behavior happens if polyline is the uppermost control. Using SetShape make the click ignore TImages and TSpeedButtons (in front or behind) positioned in a removed area of a Shaped control. Since the click messages are processed on parent, I made the message redirection. Now I'm studing a way to check if the click is on a control area or not, to make a TControl.CMHitTest fix. 2014-11-22 7:57 GMT-02:00 Frederic Da Vitoria davito...@gmail.com: I may be wrong, but this seems different from the problem you are describing: in the bugtracker issue, the click triggers the Form handler instead of being sent to a Control. In your problem, from your description, I thought the click triggered the polyline control while you would have wanted it to be handled by the TImage which is behind the polyline. In a way, your problem is not enough transparency (in terms of who gets to handle the click event) while the bugtracker bug is too much transparency. Or did I misunderstand you? 2014-11-22 10:01 GMT+01:00 Fabio Luis Girardi fluisgira...@gmail.com: Here is it: http://bugs.freepascal.org/view.php?id=20381 2014-11-21 22:24 GMT-02:00 Fabio Luis Girardi fluisgira...@gmail.com: I found this bug on bug tracker. I followed your idea and send a patch that solves this. I'll try another approach tomorrow. Thank you very much! Em 21/11/2014 20:48, Frederic Da Vitoria davito...@gmail.com escreveu: 2014-11-21 16:01 GMT+01:00 Frederic Da Vitoria davito...@gmail.com: 2014-11-20 19:21 GMT+01:00 Fabio Luis Girardi fluisgira...@gmail.com : I don't know if this is a bug or not. I created a control from a TCustomControl that draws a polyline with a transparent background. The transparent effect has been using SetShape procedure using a bitmap of 1 bit color depth. The bug (I don't know if this is a bug) is that a TImage behind of a instance of my polyline control don't receive the click messages, but a TButton instance receives. So, I don't know if this is a bug or I have to do something in my control to send these messages to TImage behind. I had once a similar issue with a tPanel behind another control, in Delphi. IIRC, I indeed had to forward the messages in some way to the tPanel. I can check in my archives, if you want, but I won't be able to do it before tomorrow. I just checked. Sorry, my memory was wrong, I did use TButtons. But it makes sense that the uppermost control would prevent any deeper control from receiving clicks, even if the uppermost control is visually transparent. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- The best regards, Fabio Luis Girardi PascalSCADA Project http://sourceforge.net/projects/pascalscada http://www.pascalscada.com -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Maybe a bug: click on TImage behind another control with SetShape
The problem is the concept of transparent. 2014-11-22 10:40 GMT-02:00 Fabio Luis Girardi fluisgira...@gmail.com: I think that we aren't talking about the same thing. I think that a transparent control must retain clicks to another controls if it is uppermost and in front of these controls. I think that this is correct. Polyline is a different control. The area of line is the area of the control, other area will be full transparent and must pass the events to controls behind. If you click on line, the click must be fired on Polyline object, otherwise, it must be fired on the first control behind of polyline. The bug here is: I have two TImages and one polyline. The uppermost is TImage is positioned in a removed area (transparent) of polyline and the other TImage is the background. When I click on uppermost TImage click isn't fired on it nor on background TImage. It's fired on TForm! The same behavior happens if polyline is the uppermost control. Using SetShape make the click ignore TImages and TSpeedButtons (in front or behind) positioned in a removed area of a Shaped control. Since the click messages are processed on parent, I made the message redirection. Now I'm studing a way to check if the click is on a control area or not, to make a TControl.CMHitTest fix. 2014-11-22 7:57 GMT-02:00 Frederic Da Vitoria davito...@gmail.com: I may be wrong, but this seems different from the problem you are describing: in the bugtracker issue, the click triggers the Form handler instead of being sent to a Control. In your problem, from your description, I thought the click triggered the polyline control while you would have wanted it to be handled by the TImage which is behind the polyline. In a way, your problem is not enough transparency (in terms of who gets to handle the click event) while the bugtracker bug is too much transparency. Or did I misunderstand you? 2014-11-22 10:01 GMT+01:00 Fabio Luis Girardi fluisgira...@gmail.com: Here is it: http://bugs.freepascal.org/view.php?id=20381 2014-11-21 22:24 GMT-02:00 Fabio Luis Girardi fluisgira...@gmail.com: I found this bug on bug tracker. I followed your idea and send a patch that solves this. I'll try another approach tomorrow. Thank you very much! Em 21/11/2014 20:48, Frederic Da Vitoria davito...@gmail.com escreveu: 2014-11-21 16:01 GMT+01:00 Frederic Da Vitoria davito...@gmail.com: 2014-11-20 19:21 GMT+01:00 Fabio Luis Girardi fluisgira...@gmail.com : I don't know if this is a bug or not. I created a control from a TCustomControl that draws a polyline with a transparent background. The transparent effect has been using SetShape procedure using a bitmap of 1 bit color depth. The bug (I don't know if this is a bug) is that a TImage behind of a instance of my polyline control don't receive the click messages, but a TButton instance receives. So, I don't know if this is a bug or I have to do something in my control to send these messages to TImage behind. I had once a similar issue with a tPanel behind another control, in Delphi. IIRC, I indeed had to forward the messages in some way to the tPanel. I can check in my archives, if you want, but I won't be able to do it before tomorrow. I just checked. Sorry, my memory was wrong, I did use TButtons. But it makes sense that the uppermost control would prevent any deeper control from receiving clicks, even if the uppermost control is visually transparent. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- The best regards, Fabio Luis Girardi PascalSCADA Project http://sourceforge.net/projects/pascalscada http://www.pascalscada.com -- The best regards, Fabio Luis Girardi PascalSCADA Project http://sourceforge.net/projects/pascalscada http://www.pascalscada.com -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Compilation of .../test/testresult-db/importtestresults.lpi
On Sat, 22 Nov 2014 04:27:40 -0800 Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote: [...] .../test/testresult-db/importtestresults.lpi [...] /usr/bin/ld: cannot find -lmysqlclient Error: Error while linking [...] Looks like by design to me. If you want to test the db stuff you have to install the db stuff. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8 RTL for Windows
Am 2014-11-20 um 17:21 schrieb Mattias Gaertner: The development version of FPC 2.7.1 has extended Strings and many RTL functions now work for codepages other than the system codepage. 2. The new mode: The LCL, FCL and RTL treat all String as UTF-8 encoded. ... When accessing the WinAPI you must use the W functions or use UTF8ToWinCP and WinCPToUTF8. Is this correct? The W functions of the WinAPI expect UTF16 so a conversion needs to be done in both cases, either to System code page or to UTF16. Or can we use STRING with WinAPI W functions directly? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8 RTL for Windows
On Sat, 22 Nov 2014 14:37:00 +0100 Jürgen Hestermann juergen.hesterm...@gmx.de wrote: Am 2014-11-20 um 17:21 schrieb Mattias Gaertner: The development version of FPC 2.7.1 has extended Strings and many RTL functions now work for codepages other than the system codepage. 2. The new mode: The LCL, FCL and RTL treat all String as UTF-8 encoded. ... When accessing the WinAPI you must use the W functions or use UTF8ToWinCP and WinCPToUTF8. Is this correct? The W functions of the WinAPI expect UTF16 so a conversion needs to be done in both cases, either to System code page or to UTF16. Or can we use STRING with WinAPI W functions directly? You can use them directly. For example: procedure TForm1.FormCreate(Sender: TObject); var s: string; // String = AnsiString because of $H+ begin s:=GetCommandLineW; // GetCommandLineW returns a UTF-16 PWideChar // the compiler adds code to convert this to the // default system codepage (CP_ACP = CP_UTF8) // the resulting string has StringCodePage CP_ACP // and is encoded in UTF-8. // therefore you can simply use it with the LCL Memo1.Lines.Add(s); end; You will get a compiler warning (id 4105), that WideString to Ansistring might loose data. The warning is right if the default string codepage is not UTF-8. If your code only runs with the RTL in UTF-8 mode, you can disable this warning. As alternative you can use: s:=UTF8Encode(GetCommandLineW); You must also use UTF8Encode if your code should run with both FPC 2.6.4 and 2.7.1. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8 RTL for Windows
Am 2014-11-22 um 15:06 schrieb Mattias Gaertner: procedure TForm1.FormCreate(Sender: TObject); var s: string; // String = AnsiString because of $H+ begin s:=GetCommandLineW; // GetCommandLineW returns a UTF-16 PWideChar // the compiler adds code to convert this to the // default system codepage (CP_ACP = CP_UTF8) // the resulting string has StringCodePage CP_ACP // and is encoded in UTF-8. // therefore you can simply use it with the LCL Okay. Does that mean that the compiler *always* assumes that String=UTF-8 encoded AnsiString and converts to other (known) encoded string types if needed? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TFMTBCDField problem
i just hope i did it correctly thanks for all the help :) On Friday, November 21, 2014 11:05 AM, Joost van der Sluis jo...@cnoc.nl wrote: On 11/18/2014 06:02 PM, Chris Rempas wrote: I guess i was wrong, the best solution is the first one, atr least in my tests can someone help me put a bug report with the fix? Just visit bugs.freepascal.org, add an account and fill in the bug-report form. Don't forget to send in your patch. You can use subversion to create the patch. (On the command-line: svn diff) Regards, Joost. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8 RTL for Windows
On Sat, 22 Nov 2014 16:18:09 +0100 Jürgen Hestermann juergen.hesterm...@gmx.de wrote: Am 2014-11-22 um 15:06 schrieb Mattias Gaertner: procedure TForm1.FormCreate(Sender: TObject); var s: string; // String = AnsiString because of $H+ begin s:=GetCommandLineW; // GetCommandLineW returns a UTF-16 PWideChar // the compiler adds code to convert this to the // default system codepage (CP_ACP = CP_UTF8) // the resulting string has StringCodePage CP_ACP // and is encoded in UTF-8. // therefore you can simply use it with the LCL Okay. Does that mean that the compiler *always* assumes that String=UTF-8 encoded AnsiString Yes, with the UTF8 RTL. The default RTL uses system codepage. and converts to other (known) encoded string types if needed? Yes. That's the new feature of FPC 2.7.1. What other encoded string types do you have in mind? Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8 RTL for Windows
On Sat, 22 Nov 2014, Mattias Gaertner wrote: On Sat, 22 Nov 2014 16:18:09 +0100 Jürgen Hestermann juergen.hesterm...@gmx.de wrote: Am 2014-11-22 um 15:06 schrieb Mattias Gaertner: procedure TForm1.FormCreate(Sender: TObject); var s: string; // String = AnsiString because of $H+ begin s:=GetCommandLineW; // GetCommandLineW returns a UTF-16 PWideChar // the compiler adds code to convert this to the // default system codepage (CP_ACP = CP_UTF8) // the resulting string has StringCodePage CP_ACP // and is encoded in UTF-8. // therefore you can simply use it with the LCL Okay. Does that mean that the compiler *always* assumes that String=UTF-8 encoded AnsiString Yes, with the UTF8 RTL. The default RTL uses system codepage. Careful, there is no such thing as the UTF8 RTL. There is now a Unicode and CodePage-aware RTL. That means it has: - Codepage aware single-byte strings. The codepage of a string may, or may not, be UTF8 (i.e. Unicode). - Widestrings (unicode). The compiler handles conversion of codepages transparantly. The codepage aware single-byte strings are not automatically UTF-8. On linux, this is probably so. But on windows, this is not necessarily so, Additionally, most basic File I/O routines now correctly call the underlying OS-es file routines with the codepage the OS expects (which is WideString on Windows). The exact behaviour of the RTL is controlled by a couple of variables: DefaultSystemCodePage, DefaultFileSystemCodePage , DefaultRTLFileSystemCodePage. See http://wiki.freepascal.org/FPC_Unicode_support. Michael.-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
I've seen this for try...finally blocks when I implemented the initial debugger. It was to do with line info generated for these bloks Marc Original Message From:Mattias Gaertner nc-gaert...@netcologne.de Sent:Fri, 21 Nov 2014 16:23:54 +0100 To:lazarus@lists.lazarus.freepascal.org Subject:Re: [Lazarus] Need testers for the a new debugger On Fri, 21 Nov 2014 15:12:48 + Martin Frb laza...@mfriebe.de wrote: On 21/11/2014 14:03, Mattias Gaertner wrote: On Mon, 14 Jul 2014 23:13:14 +0200 Joost van der Sluis jo...@cnoc.nl wrote: [...] The debugger has been improved a lot and I could need some help testing the thing. On single stepping the debugger always jumps into a proc, then to the end of the proc and then to the first line. Actually it does not do it for every procedure. Maybe only for those with implicit try..finally. Bug or design? Without looking at it, I have seen that with gdb too, though only for certain complier help procs (iirc chek object stuff) Can you reproduce it? Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8 RTL for Windows
Mattias Gaertner schrieb: // GetCommandLineW returns a UTF-16 PWideChar // the compiler adds code to convert this to the // default system codepage (CP_ACP = CP_UTF8) // the resulting string has StringCodePage CP_ACP // and is encoded in UTF-8. Does this mean that Lazarus (new mode) ignores the OS system codepage setting? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] OI Checkboxes
On Fri, Nov 21, 2014 at 4:31 PM, FreeMan freema...@delphiturkiye.com wrote: Thank you, uncommenting resolve my problem. Without those lines indeed Lazarus built with QT crashes when Color combobox list is opened. Why does it happen? I returned the code in r46966. Juha -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] lresources.pp(3089, 67) Error: Identifier not found RT_RCDATA
fpc trunk r29110 lazarus trunk r46966 vista 32-bit i just updated fpc trunk and lazarus trunk... fpc compiled ok... lazarus fails with lresources.pp(3089,67) Error: Identifier not found RT_RCDATA *** * TASK: build lazbuild, startlazarus and necessary tools... * CMND: make OPT=-gl -gh -dHEAPTRC_WINDOW lazbuild lcl basecomponents starter bigidecomponents lhelp * [...] c:/freepascal/binutils/i386-win32/cp.exe -f Makefile.compiled units/i386-win32/CodeTools.compiled make[1]: Leaving directory `c:/freepascal/laz/components/codetools' make -C lcl LCL_PLATFORM=nogui make[1]: Entering directory `c:/freepascal/laz/lcl' c:/freepascal/binutils/i386-win32/rm.exe -f units/i386-win32/alllclunits.ppu c:/freepascal/binutils/i386-win32/gmkdir.exe -p units/i386-win32 c:/freepascal/fpc/trunk/bin/i386-win32/ppc386.exe -gl -Fu../packager/units/i386-win32 -Fu../components/lazutils/lib/i386-win32 -Fu. -Fuforms -Fuwidgetset -Fiinclude -FE. -FUunits/i386-win32 -gl -gh -dHEAPTRC_WINDOW -di386 alllclunits.pp Free Pascal Compiler version 2.7.1 [2014/11/22] for i386 Copyright (c) 1993-2014 by Florian Klaempfl and others Target OS: Win32 for i386 Compiling alllclunits.pp Compiling checklst.pas Compiling lclproc.pas Compiling lclstrconsts.pas Writing Resource String Table file: lclstrconsts.rsj Compiling lcltype.pp Compiling .\widgetset\wsreferences.pp Compiling graphtype.pp Compiling graphics.pp Compiling lclversion.pas Compiling intfgraphics.pas Compiling icnstypes.pas Compiling graphics.pp Compiling lmessages.pp Compiling lresources.pp Compiling dynqueue.pas lresources.pp(3089,67) Error: Identifier not found RT_RCDATA lresources.pp(5781) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted make[1]: *** [alllclunits.ppu] Error 1 make[1]: Leaving directory `c:/freepascal/laz/lcl' make: *** [lazbuild] Error 2 -- NOTE: No off-list assistance is given without prior approval. Please *keep mailing list traffic on the list* unless private contact is specifically requested and granted. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] lresources.pp(3089, 67) Error: Identifier not found RT_RCDATA
On 11/22/2014 08:30 PM, waldo kitty wrote: fpc trunk r29110 lazarus trunk r46966 vista 32-bit i just updated fpc trunk and lazarus trunk... fpc compiled ok... lazarus fails with lresources.pp(3089,67) Error: Identifier not found RT_RCDATA Add the windows-unit to the uses section of lresources as a quick fix. Joost. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] lresources.pp(3089, 67) Error: Identifier not found RT_RCDATA
On 11/22/14, Joost van der Sluis jo...@cnoc.nl wrote: Add the windows-unit to the uses section of lresources as a quick fix. And what to do on non-windows systems? Maybe better copy the RT_RCDATA definition and ifdef it for 2.7.1? As a side note: FPResource := FindResource(HInstance, PChar(ResName), PChar(RT_RCDATA)); The cast to PChar seems a little redundant given the definition of RT_RCDATA? Bart -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8 RTL for Windows
On Sat, 22 Nov 2014 17:18:35 +0100 Hans-Peter Diettrich drdiettri...@aol.com wrote: Mattias Gaertner schrieb: // GetCommandLineW returns a UTF-16 PWideChar // the compiler adds code to convert this to the // default system codepage (CP_ACP = CP_UTF8) // the resulting string has StringCodePage CP_ACP // and is encoded in UTF-8. Does this mean that Lazarus (new mode) ignores the OS system codepage setting? To be exact: Lazarus unit fpcadds sets the default string encoding (DefaultSystemCodePage) to CP_UTF8. The OS system codepage of Windows is not changed. All non W (e.g. A) functions still return and expect strings in the Windows system codepage. You can convert between UTF8 and Windows system codepage with UTF8ToWinCP and WinCPToUTF8. So, yes, a LCL application can now mostly ignore the system codepage. Finding the exceptions and traps is the goal of this mail thread. Please test and report what you find out. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8 RTL for Windows
On Sat, 22 Nov 2014 17:38:33 +0100 (CET) Michael Van Canneyt mich...@freepascal.org wrote: [...] Yes, with the UTF8 RTL. The default RTL uses system codepage. Careful, there is no such thing as the UTF8 RTL. There is now a Unicode and CodePage-aware RTL. Well, yes, you are right of course. But Unicode and CodePage-aware RTL set to UTF-8 is an awkwardly long title. Also many users think that the new string types will break all their code and add lots of overhead. I want to advertise, that this is not so. On the contrary, it is very compatible, you get cross platform Unicode and the overhead is pretty small. And last but not least: Programming Unicode has become easier, because string encoding is now more consistent. That means it has: - Codepage aware single-byte strings. The codepage of a string may, or may not, be UTF8 (i.e. Unicode). - Widestrings (unicode). The compiler handles conversion of codepages transparantly. The codepage aware single-byte strings are not automatically UTF-8. On linux, this is probably so. But on windows, this is not necessarily so, True. Although many programmers misunderstand what this means. It is not as scary as it sounds. Additionally, most basic File I/O routines now correctly call the underlying OS-es file routines with the codepage the OS expects (which is WideString on Windows). Is it safe to say UTF-16? Or are there still UCS-2 Windows? The exact behaviour of the RTL is controlled by a couple of variables: DefaultSystemCodePage, DefaultFileSystemCodePage , DefaultRTLFileSystemCodePage. Yes, that's the important bit that FPC made better than Delphi. :) See http://wiki.freepascal.org/FPC_Unicode_support. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] lresources.pp(3089, 67) Error: Identifier not found RT_RCDATA
On Sat, 22 Nov 2014 23:27:30 +0100 Bart bartjun...@gmail.com wrote: On 11/22/14, Joost van der Sluis jo...@cnoc.nl wrote: Add the windows-unit to the uses section of lresources as a quick fix. Done. And what to do on non-windows systems? That compiles unchanged. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] lresources.pp(3089, 67) Error: Identifier not found RT_RCDATA
On 11/22/2014 4:27 PM, Joost van der Sluis wrote: On 11/22/2014 08:30 PM, waldo kitty wrote: fpc trunk r29110 lazarus trunk r46966 vista 32-bit i just updated fpc trunk and lazarus trunk... fpc compiled ok... lazarus fails with lresources.pp(3089,67) Error: Identifier not found RT_RCDATA Add the windows-unit to the uses section of lresources as a quick fix. i hesitate to do that for several reasons... but i'm also interested in what changed elsewhere to break this... the lresources.pp file that i have is dated 2014 Mar 17 10:02... i've looked through the svn log of the last few days since my last update and haven't found anything obvious but i've also not dug in very deeply... thanks for your reply! -- NOTE: No off-list assistance is given without prior approval. Please *keep mailing list traffic on the list* unless private contact is specifically requested and granted. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
