From florian at freepascal.org Tue Nov 1 10:40:17 2016 From: florian at freepascal.org (=?UTF-8?Q?Florian_Kl=c3=a4mpfl?=) Date: Tue, 1 Nov 2016 10:40:17 +0100 Subject: [Lazarus] FPC on Rpi3 executable module sizes In-Reply-To: <1477848722999-4050129.post@n3.nabble.com> References: <1477811102597-4050126.post@n3.nabble.com> <1477848722999-4050129.post@n3.nabble.com> Message-ID: <92c58158-b287-80cc-717d-2c489ef619b9@freepascal.org> Am 30.10.2016 um 18:32 schrieb Ken Kashmarek via Lazarus: > > This is clearly an error where each addition adds 200k (or more) the the > executable file. Those units contain initialization sections which drag in a lot of code. You might want to try to strip explicitly unused symbols by compiling with -Xs. > I do note however, that all 3 uses entries on Windows 7, > brings the executable up to more than 240K (significantly smaller than the > RPi3 install of FCP produces). > I guess the reason is that you are using the variants unit. On windows, most of the variants stuff can be handled by the OS. On unix style systems, everything is handled by FPC libraries which emulate how windows handles variants. > uses sysutils; // , variants, classes; > type ptr2Byte = ^Byte; > comp = int64; > var i,j: integer; > > begin > writeln; > i := 4096; > writeln('Value of i = ',i:8); > writeln('--> Execution of (nearly) null program ended.'); > writeln; > end. From aaa5500 at ya.ru Tue Nov 1 10:44:06 2016 From: aaa5500 at ya.ru (Alexey) Date: Tue, 1 Nov 2016 12:44:06 +0300 Subject: [Lazarus] Non UTF8 func in LCL In-Reply-To: <44251212-6631-427E-B52A-2D05E99ED706@gmail.com> References: <1477753198878-4050121.post@n3.nabble.com> <44251212-6631-427E-B52A-2D05E99ED706@gmail.com> Message-ID: <38c1d0c1-9688-5ad3-a480-42b91cacda41@ya.ru> hi I found (CudaText finder, 16 matches) of non UTF8 func GetEnvironmentVariable (no suffix UTF8) in lcl. Consider to replace with GetEnvironmentVariableUTF8. Img of found lines https://postimg.org/image/julazv1h7/ Alex From Sascha.Hestermann at gmx.de Tue Nov 1 13:06:52 2016 From: Sascha.Hestermann at gmx.de (Sascha Hestermann) Date: Tue, 1 Nov 2016 13:06:52 +0100 Subject: [Lazarus] FPC on Rpi3 executable module sizes In-Reply-To: <1477848722999-4050129.post@n3.nabble.com> References: <1477811102597-4050126.post@n3.nabble.com> <1477848722999-4050129.post@n3.nabble.com> Message-ID: <91015172-a669-a00f-75af-8180dc3f3467@gmx.de> Am 30.10.2016 um 18:32 schrieb Ken Kashmarek via Lazarus: > On the RPi3, goes up to over 400K in size. If 3 items are in the uses line, > the RPi3 executable exceeds 800K. > > This is clearly an error where each addition adds 200k (or more) the the > executable file. I do note however, that all 3 uses entries on Windows 7, > brings the executable up to more than 240K (significantly smaller than the > RPi3 install of FCP produces). It seems that you are using Linux on your RPi3 and when I compile any project on my Linux desktop box I get the following compiler message: "Note: DWARF debug information cannot be used with smart linking on this target, switching to static linking" So even after stripping the debug symbols the size is significantly larger because of the deactivated smart linking. As far as I remember this happens with all of the possible debug formats I can choose from. So to allow smart linking you probably have to disable the generation of debug symbols completely. (Though I have never used the RPi3 target, so I can only guess from using x86 Linux.) By the way if you are using Lazarus, the compiler note is hidden by default: Right click in the message window -> "Filter Hints without Source Position" From parkingspace26 at yahoo.com Wed Nov 2 00:48:10 2016 From: parkingspace26 at yahoo.com (Bob B.) Date: Tue, 1 Nov 2016 23:48:10 +0000 (UTC) Subject: [Lazarus] Suggestion for Object Inspector References: <593333079.2570108.1478044090864.ref@mail.yahoo.com> Message-ID: <593333079.2570108.1478044090864@mail.yahoo.com> There are tabs for Properties and for Events, how about one for Methods?  Clicking on on one could put the prototype for the function or procedure at the current Editor cursor position.   Since not all components are well documented, such a list could be really helpful. Bob B. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vojtech.cihak at atlas.cz Wed Nov 2 01:51:43 2016 From: vojtech.cihak at atlas.cz (=?utf-8?q?Vojt=C4=9Bch_=C4=8Cih=C3=A1k?=) Date: Wed, 02 Nov 2016 01:51:43 +0100 Subject: [Lazarus] =?utf-8?q?Suggestion_for_Object_Inspector?= In-Reply-To: 0000000066cf0000cfec00f350ef References: <593333079.2570108.1478044090864.ref@mail.yahoo.com> 0000000066cf0000cfec00f350ef Message-ID: <20161102015143.92D6E11E@atlas.cz> It is impossible since methods are not part of RTTI. Maybe Code Explerer would be better place for it.   V. ______________________________________________________________ > Od: "Bob B. via Lazarus" > Komu: Lazarus Mailing List > Datum: 02.11.2016 00:48 > Předmět: [Lazarus] Suggestion for Object Inspector > There are tabs for Properties and for Events, how about one for Methods?  Clicking on on one could put the prototype for the function or procedure at the current Editor cursor position.  Since not all components are well documented, such a list could be really helpful.Bob B. ---------- -- _______________________________________________ Lazarus mailing list Lazarus at lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus -------------- next part -------------- An HTML attachment was scrubbed... URL: From vojtech.cihak at atlas.cz Wed Nov 2 01:58:06 2016 From: vojtech.cihak at atlas.cz (=?utf-8?q?Vojt=C4=9Bch_=C4=8Cih=C3=A1k?=) Date: Wed, 02 Nov 2016 01:58:06 +0100 Subject: [Lazarus] =?utf-8?q?Suggestion_for_Object_Inspector?= In-Reply-To: 0000000066d00000d1ec00f35086 References: <593333079.2570108.1478044090864.ref@mail.yahoo.com> 0000000066d00000d1ec00f35086 Message-ID: <20161102015806.13552762@atlas.cz> I guess we are talking about virtual (abstrat) methods which can be overridden.   V. ______________________________________________________________ > Od: Vojtěch Čihák via Lazarus > Komu: Bob B. , > Datum: 02.11.2016 01:51 > Předmět: Re: [Lazarus] Suggestion for Object Inspector > It is impossible since methods are not part of RTTI. Maybe Code Explerer would be better place for it.   V. ______________________________________________________________ > Od: "Bob B. via Lazarus" > Komu: Lazarus Mailing List > Datum: 02.11.2016 00:48 > Předmět: [Lazarus] Suggestion for Object Inspector > There are tabs for Properties and for Events, how about one for Methods?  Clicking on on one could put the prototype for the function or procedure at the current Editor cursor position.  Since not all components are well documented, such a list could be really helpful.Bob B. ---------- -- _______________________________________________ Lazarus mailing list Lazarus at lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus ---------- -- _______________________________________________ Lazarus mailing list Lazarus at lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvioprog at gmail.com Wed Nov 2 03:50:07 2016 From: silvioprog at gmail.com (silvioprog) Date: Tue, 1 Nov 2016 23:50:07 -0300 Subject: [Lazarus] Question about TRichMemo In-Reply-To: References: Message-ID: Hello, First, thanks for this great component ! :-) So, what do you think about distributing it on Lazarus components directory and it cames installed by default in the IDE? Anyway, I'm going to send some patches to improve this component ... Thank you! -- Silvio Clécio -------------- next part -------------- An HTML attachment was scrubbed... URL: From skalogryz.lists at gmail.com Wed Nov 2 04:38:16 2016 From: skalogryz.lists at gmail.com (Dmitry Boyarintsev) Date: Tue, 1 Nov 2016 23:38:16 -0400 Subject: [Lazarus] Question about TRichMemo In-Reply-To: References: Message-ID: On Tue, Nov 1, 2016 at 10:50 PM, silvioprog via Lazarus < lazarus at lists.lazarus-ide.org> wrote: > Anyway, I'm going to send some patches to improve this component ... > Thank you! Looking forward! Pure Delphi-compatibility patches are likely to be rejected. (unless they're implemented in the form of helpers) Keeping in mind cross-platform compatibility is greatly appreciated (thus Windows only features are likely to be rejected as well... or could be added in a form of functions/helpers, rather than a part of TCustomRichMemo interface) thanks, Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: From ptrg at freemail.hu Wed Nov 2 07:59:52 2016 From: ptrg at freemail.hu (=?UTF-8?B?UMOpdGVyIEfDoWJvcg==?=) Date: Wed, 2 Nov 2016 07:59:52 +0100 Subject: [Lazarus] Suggestion for Object Inspector In-Reply-To: <593333079.2570108.1478044090864@mail.yahoo.com> References: <593333079.2570108.1478044090864.ref@mail.yahoo.com> <593333079.2570108.1478044090864@mail.yahoo.com> Message-ID: <7e382842-5054-7007-8ca2-cb258f302b1a@freemail.hu> There are a lot of completion related settings in the IDE, some for the identifiers. You can see them if you type the word "completion" in the filter field of the IDE options. I think that the Editor can do what you need: 1.: Tools / Options / Editor / Completion and Hints 2.: Tools / Options / Codetools / Class Completion 3.: Tools / Options / Codetools / Code Completion 4.: Tools / Options / Codetools / Identifier Completion 2016-11-02 00:48 keltezéssel, Bob B. via Lazarus írta: > There are tabs for Properties and for Events, how about one for Methods? > Clicking on on one could put the prototype for the function or > procedure at the current Editor cursor position. > > Since not all components are well documented, such a list could be > really helpful. > > Bob B. -- Péter Gábor ptrg at freemail.hu From nc-gaertnma at netcologne.de Wed Nov 2 12:17:28 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Wed, 2 Nov 2016 12:17:28 +0100 (CET) Subject: [Lazarus] Non UTF8 func in LCL In-Reply-To: <38c1d0c1-9688-5ad3-a480-42b91cacda41@ya.ru> References: <1477753198878-4050121.post@n3.nabble.com> <44251212-6631-427E-B52A-2D05E99ED706@gmail.com> <38c1d0c1-9688-5ad3-a480-42b91cacda41@ya.ru> Message-ID: <1131927012.82316.1478085448483@comcenter.netcologne.de> > Alexey via Lazarus hat am 1. November 2016 um 10:44 geschrieben: > > hi > I found (CudaText finder, 16 matches) of non UTF8 func Lazarus Find-in-Files found the same. > GetEnvironmentVariable (no suffix UTF8) in lcl. > Consider to replace with GetEnvironmentVariableUTF8. > Img of found lines https://postimg.org/image/julazv1h7/ I fixed three places, where UTF-8 could be useful. Mattias Mattias From mueller.b at gmx.net Wed Nov 2 13:27:04 2016 From: mueller.b at gmx.net (Bernd Mueller) Date: Wed, 2 Nov 2016 13:27:04 +0100 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 Message-ID: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> Hello, with Lazarus 1.6 (FPC 3.0.0 i386-linux-gtk 2) filling a Memo with 10000 lines takes about 18 seconds on my system. Doing the same with Lazarus 1.4.0 (FPC 2.6.4 i386-linux-gtk 2) takes about 193 ms. I cannot believe, that Lazarus 1.6 should be nearly 90 times slower than 1.4.0. I am wondering, if this is a bug or by design? Regards, Bernd. unit Unit1; {$mode objfpc}{$H+} interface uses Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, StdCtrls, LCLIntf; type { TForm1 } TForm1 = class(TForm) Button1: TButton; Memo1: TMemo; procedure Button1Click(Sender: TObject); private { private declarations } public { public declarations } end; var Form1: TForm1; implementation {$R *.lfm} { TForm1 } procedure TForm1.Button1Click(Sender: TObject); var i: Integer; s: String; Start, Stop: DWord; begin s:= '01234567890123456789012345678901234567890123456789012345678901234567890123456789'; Memo1.Clear; Start:= GetTickCount; Memo1.Lines.BeginUpdate; for i:= 1 to 10000 do begin Memo1.Lines.Add(s); end; Stop:= GetTickCount - Start; Memo1.Lines.EndUpdate; ShowMessage(IntToStr(Stop) + ' ms'); end; end. From mailinglists at geldenhuys.co.uk Wed Nov 2 14:04:05 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 2 Nov 2016 13:04:05 +0000 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> Message-ID: On 2016-11-02 12:27, Bernd Mueller via Lazarus wrote: > with Lazarus 1.6 (FPC 3.0.0 i386-linux-gtk 2) filling a Memo with 10000 > lines takes about 18 seconds on my system. I can confirm that. Using 64-bit Lazarus (trunk from a week ago) with FPC 3.0.0 and LCL-GTK2. On my Intel i7-3550K CPU @ 3.50Ghz system it takes 9100ms to complete. In comparison, with fpGUI it took 1ms. Regards, Graeme From luca at wetron.es Wed Nov 2 14:36:32 2016 From: luca at wetron.es (Luca Olivetti) Date: Wed, 2 Nov 2016 14:36:32 +0100 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> Message-ID: <2ada1f21-279c-d2cf-6105-0058932237fe@wetron.es> El 02/11/16 a les 13:27, Bernd Mueller via Lazarus ha escrit: > Hello, > > with Lazarus 1.6 (FPC 3.0.0 i386-linux-gtk 2) filling a Memo with 10000 > lines takes about 18 seconds on my system. Doing the same with Lazarus > 1.4.0 (FPC 2.6.4 i386-linux-gtk 2) takes about 193 ms. I cannot believe, > that Lazarus 1.6 should be nearly 90 times slower than 1.4.0. Try using a TSynEdit instead of a TMemo. I did not try with lazarus 1.6, but with 1.4.4 it is 9ms vs 143 ms for a tmemo. On windows tmemo is even slower, while TSynEdit isn't. Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From mueller.b at gmx.net Wed Nov 2 14:44:50 2016 From: mueller.b at gmx.net (Bernd Mueller) Date: Wed, 2 Nov 2016 14:44:50 +0100 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: <2ada1f21-279c-d2cf-6105-0058932237fe@wetron.es> References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> <2ada1f21-279c-d2cf-6105-0058932237fe@wetron.es> Message-ID: <87a5ad9c-9f15-31f2-b04f-e15319bb4a71@gmx.net> On 11/02/2016 02:36 PM, Luca Olivetti via Lazarus wrote: > > Try using a TSynEdit instead of a TMemo. I did not try with lazarus 1.6, > but with 1.4.4 it is 9ms vs 143 ms for a tmemo. > On windows tmemo is even slower, while TSynEdit isn't. > Thank you for your suggestion. With Lazarus 1.6, TSynEdit takes about 4 ms. But I wanted to point out, that there must be a problem with TMemo and Lazarus 1.6. Regards, Bernd. From mailinglists at geldenhuys.co.uk Wed Nov 2 14:47:14 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 2 Nov 2016 13:47:14 +0000 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: <2ada1f21-279c-d2cf-6105-0058932237fe@wetron.es> References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> <2ada1f21-279c-d2cf-6105-0058932237fe@wetron.es> Message-ID: On 2016-11-02 13:36, Luca Olivetti via Lazarus wrote: > Try using a TSynEdit instead of a TMemo. That's a bit of overkill in most cases, plus - as Bernd clearly point out - there is a TMemo regression bug in LCL. Regards, Graeme From kashken at csteldridge.com Wed Nov 2 15:59:08 2016 From: kashken at csteldridge.com (Ken Kashmarek) Date: Wed, 2 Nov 2016 07:59:08 -0700 (MST) Subject: [Lazarus] FPC on Rpi3 executable module sizes In-Reply-To: <91015172-a669-a00f-75af-8180dc3f3467@gmx.de> References: <1477811102597-4050126.post@n3.nabble.com> <1477848722999-4050129.post@n3.nabble.com> <91015172-a669-a00f-75af-8180dc3f3467@gmx.de> Message-ID: <1478098748338-4050151.post@n3.nabble.com> I used Bo Berglund's script to install FPC (including Lasarus) on my RPi3. That script is long and complicated and making changes to it would be in his domain. I suspect there are some issues with any options dealing with smart linking and debug symbols. I hope he gets a chance to review the script in this regard. If your 'uses' clause includes several items, that can easily drive the executable file size over a megabyte (disasterous on any Raspberry Pi node). With no 'uses' clause, over 200K is added to the executable file anyway. By the way, since this isn't a normal apt-get style install, deleting the result of a successful execution of Bo's script, will be quite an effort. The install itself does add 840 meg to your SD card (all the source files and bloated library files of every kind). Ken -- View this message in context: http://free-pascal-lazarus.989080.n3.nabble.com/FPC-on-Rpi3-executable-module-sizes-tp4050126p4050151.html Sent from the Free Pascal - Lazarus mailing list archive at Nabble.com. From werner.pamler at freenet.de Wed Nov 2 16:56:08 2016 From: werner.pamler at freenet.de (Werner Pamler) Date: Wed, 2 Nov 2016 16:56:08 +0100 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> Message-ID: I tested on Win 10 (using the code of the first post in this thread): - 23 sec on Laz trunk / fpc 3.0 - 23 sec on Laz 1.6 / fpc 3.0 - 23 sec Laz trunk / fpc 2.6.4 - 2.2 sec on Laz 1.44 / fpc 2.6.4 - 1.4 sec on Delphi Berlin 10.1 Using Lazarus trunk I could get a good boost by adding the strings first to a separate stringlist which is then assigned to the memo's Lines: 1.1 sec: procedure TForm1.Button1Click(Sender: TObject); var i: Integer; s: String; Start, Stop: DWord; L: TStrings; begin s:= '01234567890123456789012345678901234567890123456789012345678901234567890123456789'; L := TStringList.Create; try for i:=1 to 10000 do L.Add(s); Start := GetTickCount; Memo1.Lines.BeginUpdate; Memo1.Lines.Assign(L); Memo1.Lines.EndUpdate; Stop := GetTickCount; ShowMessage(IntToStr(Stop - Start) + ' ms'); finally L.Free; end; end; From Sascha.Hestermann at gmx.de Wed Nov 2 17:19:15 2016 From: Sascha.Hestermann at gmx.de (Sascha Hestermann) Date: Wed, 2 Nov 2016 17:19:15 +0100 Subject: [Lazarus] FPC on Rpi3 executable module sizes In-Reply-To: <1478098748338-4050151.post@n3.nabble.com> References: <1477811102597-4050126.post@n3.nabble.com> <1477848722999-4050129.post@n3.nabble.com> <91015172-a669-a00f-75af-8180dc3f3467@gmx.de> <1478098748338-4050151.post@n3.nabble.com> Message-ID: Am 02.11.2016 um 15:59 schrieb Ken Kashmarek via Lazarus: > I used Bo Berglund's script to install FPC (including Lasarus) on my RPi3. > That script is long and complicated and making changes to it would be in his > domain. I understand that changing the installation can be a bit complicated. But I was actually referring to the settings of your particular project. I neither have experience with the RPi3 nor with compilation in command line, but if I compile my project without any "-g" options I can use smart linking and otherwise not. But anyways if that is the problem in your case you should get a warning like in my previous mail. So it should be easy to check if that is the cause of the growth in size. It was just an idea to look for because that message can easily be overlooked (at least in Lazarus). From mueller.b at gmx.net Wed Nov 2 17:47:20 2016 From: mueller.b at gmx.net (Bernd Mueller) Date: Wed, 2 Nov 2016 17:47:20 +0100 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> Message-ID: <507b05bb-9adb-b6f4-dfee-905c71fe3a67@gmx.net> On 11/02/2016 04:56 PM, Werner Pamler via Lazarus wrote: > I tested on Win 10 (using the code of the first post in this thread): > > - 23 sec on Laz trunk / fpc 3.0 > - 23 sec on Laz 1.6 / fpc 3.0 > - 23 sec Laz trunk / fpc 2.6.4 > - 2.2 sec on Laz 1.44 / fpc 2.6.4 > - 1.4 sec on Delphi Berlin 10.1 > > Using Lazarus trunk I could get a good boost by adding the strings first > to a separate stringlist which is then assigned to the memo's Lines: 1.1 > sec: original code: 990 ms with Lazarus 0.9.24 (fpc 2.2.0) on Win98/AMD Duron 1,2 GHz ;-) Regards, Bernd. From nc-gaertnma at netcologne.de Wed Nov 2 18:24:28 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Wed, 2 Nov 2016 18:24:28 +0100 (CET) Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> Message-ID: <780437941.87869.1478107468300@comcenter.netcologne.de> > Werner Pamler via Lazarus hat am 2. November 2016 um 16:56 geschrieben: > > I tested on Win 10 (using the code of the first post in this thread): > > * 23 sec on Laz trunk / fpc 3.0 > * 23 sec on Laz 1.6 / fpc 3.0 > * 23 sec Laz trunk / fpc 2.6.4 > * 2.2 sec on Laz 1.44 / fpc 2.6.4 > * 1.4 sec on Delphi Berlin 10.1 Please create a bug report. Mattias From luca at wetron.es Wed Nov 2 19:43:03 2016 From: luca at wetron.es (Luca Olivetti) Date: Wed, 2 Nov 2016 19:43:03 +0100 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> <2ada1f21-279c-d2cf-6105-0058932237fe@wetron.es> Message-ID: El 02/11/16 a les 14:47, Graeme Geldenhuys via Lazarus ha escrit: > On 2016-11-02 13:36, Luca Olivetti via Lazarus wrote: >> Try using a TSynEdit instead of a TMemo. > > That's a bit of overkill in most cases, plus - as Bernd clearly point > out - there is a TMemo regression bug in LCL. Maybe it's overkill, but it's necessary under windows, where tmemo is an order (or two) of magnitude slower than under Linux, even without the regression. Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From mailinglists at geldenhuys.co.uk Wed Nov 2 20:26:13 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 2 Nov 2016 19:26:13 +0000 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> <2ada1f21-279c-d2cf-6105-0058932237fe@wetron.es> Message-ID: On 2016-11-02 18:43, Luca Olivetti via Lazarus wrote: > Maybe it's overkill, but it's necessary under windows, Welcome to the benefits of custom components where you can easily outperform native components. Just curious, has anybody tried the TMemo of LCL-CustomDrawn widgetset? I know the LCL-CustomDrawn components are still far from being useful in real-world applications, but how does that TMemo perform against the other native widgetsets? Or is the regression in some LCL TMemo common code? I tried LCL-fpGUI with Bernd's code snippet, and it is dog slow, but that is because Memo.Lines.BeginUpdate..EndUpdate doesn't do anything to the fpGUI rendering performance. fpGUI has "native" Memo.BeginUpdate..EndUpdate methods (at widget level - irrespective of the internal list class used). I'll see if I can fix LCL-fpGUI's TMemo in that regard, so it calls the appropriate BeginUpdate..EndUpdate. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From m-w-vogel at gmx.de Wed Nov 2 23:24:54 2016 From: m-w-vogel at gmx.de (Michael W. Vogel) Date: Wed, 2 Nov 2016 23:24:54 +0100 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> <2ada1f21-279c-d2cf-6105-0058932237fe@wetron.es> Message-ID: <5247da69-dec6-220f-118d-21a12960c829@gmx.de> I have made a bug entry and added there a first patch (its not the final one, but its late here now). Can you check, if it fixes the speed on your OS too (I have tested only Windows 7 for now)? http://bugs.freepascal.org/view.php?id=30851 Thank you for your feedback! Kind regards Michl Am 02.11.2016 um 20:26 schrieb Graeme Geldenhuys via Lazarus: > On 2016-11-02 18:43, Luca Olivetti via Lazarus wrote: >> Maybe it's overkill, but it's necessary under windows, > Welcome to the benefits of custom components where you can easily > outperform native components. > > Just curious, has anybody tried the TMemo of LCL-CustomDrawn widgetset? > I know the LCL-CustomDrawn components are still far from being useful in > real-world applications, but how does that TMemo perform against the > other native widgetsets? Or is the regression in some LCL TMemo common code? > > I tried LCL-fpGUI with Bernd's code snippet, and it is dog slow, but > that is because Memo.Lines.BeginUpdate..EndUpdate doesn't do anything to > the fpGUI rendering performance. fpGUI has "native" > Memo.BeginUpdate..EndUpdate methods (at widget level - irrespective of > the internal list class used). I'll see if I can fix LCL-fpGUI's TMemo > in that regard, so it calls the appropriate BeginUpdate..EndUpdate. > > > Regards, > Graeme > From mailinglists at geldenhuys.co.uk Wed Nov 2 23:59:55 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 2 Nov 2016 22:59:55 +0000 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: <5247da69-dec6-220f-118d-21a12960c829@gmx.de> References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> <2ada1f21-279c-d2cf-6105-0058932237fe@wetron.es> <5247da69-dec6-220f-118d-21a12960c829@gmx.de> Message-ID: On 2016-11-02 22:24, Michael W. Vogel via Lazarus wrote: > I have made a bug entry and added there a first patch (its not the final > one, but its late here now) I didn't look at what exactly the patch does, but on first testing it reduced the running time from 9000+ milliseconds to 250ms. So that's definitely a step in the right direction. I also replaced the hard-coded text being added to the memo with "line " where n is the value of the loop variable to confirm all lines have been added. They were. I tested with Lazarus 1.7 r52919 FPC 2.6.4 x86_64-freebsd-gtk 2. Regards, Graeme From silvioprog at gmail.com Thu Nov 3 00:25:27 2016 From: silvioprog at gmail.com (silvioprog) Date: Wed, 2 Nov 2016 20:25:27 -0300 Subject: [Lazarus] Question about TRichMemo In-Reply-To: References: Message-ID: On Wed, Nov 2, 2016 at 12:38 AM, Dmitry Boyarintsev < skalogryz.lists at gmail.com> wrote: > On Tue, Nov 1, 2016 at 10:50 PM, silvioprog via Lazarus < > lazarus at lists.lazarus-ide.org> wrote: > >> Anyway, I'm going to send some patches to improve this component ... >> > Thank you! Looking forward! > > Pure Delphi-compatibility patches are likely to be rejected. (unless > they're implemented in the form of helpers) > > Keeping in mind cross-platform compatibility is greatly appreciated (thus > Windows only features are likely to be rejected as well... or could be > added in a form of functions/helpers, rather than a part of TCustomRichMemo > interface) > > thanks, > Dmitry > Done: http://bugs.freepascal.org/view.php?id=30852 . ps. this component should be installed as default in Lazarus IDE. ;-) -- Silvio Clécio -------------- next part -------------- An HTML attachment was scrubbed... URL: From luizamericop at gmail.com Thu Nov 3 00:27:56 2016 From: luizamericop at gmail.com (Luiz Americo Pereira Camara) Date: Wed, 2 Nov 2016 20:27:56 -0300 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: <5247da69-dec6-220f-118d-21a12960c829@gmx.de> References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> <2ada1f21-279c-d2cf-6105-0058932237fe@wetron.es> <5247da69-dec6-220f-118d-21a12960c829@gmx.de> Message-ID: 2016-11-02 19:24 GMT-03:00 Michael W. Vogel via Lazarus < lazarus at lists.lazarus-ide.org>: > I have made a bug entry and added there a first patch (its not the final > one, but its late here now). Can you check, if it fixes the speed on your > OS too (I have tested only Windows 7 for now)? > Congratulations. I looked into it but could not spot the issue. The Control.Text is being queried for each item added Can you try with TextHint <> ''? Seems that will need to add an aditional check for lines UpdateCount Luiz -------------- next part -------------- An HTML attachment was scrubbed... URL: From skalogryz.lists at gmail.com Thu Nov 3 01:09:59 2016 From: skalogryz.lists at gmail.com (Dmitry Boyarintsev) Date: Wed, 2 Nov 2016 20:09:59 -0400 Subject: [Lazarus] Question about TRichMemo In-Reply-To: References: Message-ID: On Wed, Nov 2, 2016 at 7:25 PM, silvioprog via Lazarus < lazarus at lists.lazarus-ide.org> wrote: > > Done: http://bugs.freepascal.org/view.php?id=30852 . > Yep, totally fine. Should accept it tonight. Thank you. ps. this component should be installed as default in Lazarus IDE. ;-) > It's not my call. Including a component into an IDE is a big administrative issue. The main question is - how - the component is included: as a part of LCL (default components set) or as 3d-party component. If the component to become LCL-default component, then the whole work of maintaining it goes to respective widgetset maintainers. If the component to go as a 3d party component, then it needs some sort of versioning in place (and this is not the case for richmemo). So it would be clear which version (revision) of the component goes with the next Lazarus release. thanks, Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvioprog at gmail.com Thu Nov 3 03:25:11 2016 From: silvioprog at gmail.com (silvioprog) Date: Wed, 2 Nov 2016 23:25:11 -0300 Subject: [Lazarus] Question about TRichMemo In-Reply-To: References: Message-ID: On Wed, Nov 2, 2016 at 9:09 PM, Dmitry Boyarintsev via Lazarus < lazarus at lists.lazarus-ide.org> wrote: > On Wed, Nov 2, 2016 at 7:25 PM, silvioprog via Lazarus < > lazarus at lists.lazarus-ide.org> wrote: > >> >> Done: http://bugs.freepascal.org/view.php?id=30852 . >> > Yep, totally fine. Should accept it tonight. Thank you. > Perfect! :-) I had some ideas, and I can send small patches showing them. For example, what do you think about adding the GetLink() method in the TCustomRichMemo class and the href:string attribute in the TLinkMouseInfo record? It can allow the programmer to do something like this: procedure TForm1.RichMemo1LinkAction(Sender: TObject; ALinkAction: TLinkAction; const info: TLinkMouseInfo; LinkStart, LinkLen: Integer); var Link: string; begin if RichMemo1.GetLink(LinkStart, LinkLen, Link) then OpenURL(Link); end; or: var Link: string; begin Link := RichMemo1.GetLink(LinkStart, LinkLen); if Link <> '' then OpenURL(Link); end; or just (easiest way): procedure TForm1.RichMemo1LinkAction(Sender: TObject; ALinkAction: TLinkAction; const info: TLinkMouseInfo; LinkStart, LinkLen: Integer); begin OpenURL(info.href); ... I can implement it easily on GTK using g_object_set_data()/g_object_get_data() doing small changes in the SetTextUIParams()/GetTextUIParams()/Gtk2_RichMemoMouseButton() functions, however, it depends on your decision, if so, I can send a patch asap (first version for GTK but future patch for win-VCL). :-) > ps. this component should be installed as default in Lazarus IDE. ;-) >> > It's not my call. > > Including a component into an IDE is a big administrative issue. > The main question is - how - the component is included: as a part of LCL > (default components set) or as 3d-party component. > > If the component to become LCL-default component, then the whole work of > maintaining it goes to respective widgetset maintainers. > If the component to go as a 3d party component, then it needs some sort of > versioning in place (and this is not the case for richmemo). So it would be > clear which version (revision) of the component goes with the next Lazarus > release. > > thanks, > Dmitry. > Indeed. Anyway, I hope to see this (awesome) component installed by default in Lazarus IDE some day. :-) -- Silvio Clécio -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at freepascal.org Thu Nov 3 09:47:59 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Thu, 3 Nov 2016 09:47:59 +0100 (CET) Subject: [Lazarus] fcl-pdf change Message-ID: Hello, For those using the fcl-pdf package: There has been a change in the API. Well, there were many additions, but this change may influence existing code. Till now, the origin of the page was at the (top,left) corner of the page, contrary to the PDF standard which has the origin at the (bottom,left) corner. At the same time e.g. text was drawn with the current cursor position at the (bottom,left) corner of the text. This is counter-intuitive. The default has now been changed so the origin of the page is now at the (bottom,left) corner of the page, conform the PDF standard. You can easily restore the old behaviour by including poPageOriginAtTop in the document options. Michael. From m-w-vogel at gmx.de Thu Nov 3 09:54:55 2016 From: m-w-vogel at gmx.de (Michael W. Vogel) Date: Thu, 3 Nov 2016 09:54:55 +0100 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> <2ada1f21-279c-d2cf-6105-0058932237fe@wetron.es> <5247da69-dec6-220f-118d-21a12960c829@gmx.de> Message-ID: <9bc03eae-1726-2da6-488d-950785f2e606@gmx.de> Am 03.11.2016 um 00:27 schrieb Luiz Americo Pereira Camara via Lazarus: > Can you try with TextHint <> ''? > > Seems that will need to add an aditional check for lines UpdateCount Thank you for the hints! I add a new patch (just for Windows now), it takes care about this issues. There is one nasty allocation, I have to remove, so it is not the final work. It will takes a while (or someone else has a better solution). Kind regards Michl -------------- next part -------------- An HTML attachment was scrubbed... URL: From tc at epidata.info Thu Nov 3 10:18:43 2016 From: tc at epidata.info (Torsten Bonde Christiansen) Date: Thu, 3 Nov 2016 10:18:43 +0100 Subject: [Lazarus] Question about TRichMemo In-Reply-To: References: Message-ID: <1780113d-feaf-555f-909b-f035a5b2c2a4@epidata.info> On 2016-11-02 03:50, silvioprog via Lazarus wrote: > > Hello, > > First, thanks forthis great component > ! > :-) > > So, what do you think about distributing it on Lazarus components > directory and it cames installed by default in the IDE? > > Anyway, I'm going to send some patches to improve this component ... > If it all possible, can the part that generates the RichTextFormat be moved from the component into a seperate unit. This will make it possible to include RTF generators into eg. console programs. Kind regards, Torsten. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.whyman at mccallumwhyman.com Thu Nov 3 12:26:05 2016 From: tony.whyman at mccallumwhyman.com (Tony Whyman) Date: Thu, 3 Nov 2016 11:26:05 +0000 Subject: [Lazarus] fcl-pdf change In-Reply-To: References: Message-ID: Does this affect the Power PDF package or is this entirely independent? On 03/11/16 08:47, Michael Van Canneyt via Lazarus wrote: > For those using the fcl-pdf package: There has been a change in the API. > Well, there were many additions, but this change may influence > existing code. From mailinglists at geldenhuys.co.uk Thu Nov 3 12:42:35 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 3 Nov 2016 11:42:35 +0000 Subject: [Lazarus] fcl-pdf change In-Reply-To: References: Message-ID: On 2016-11-03 11:26, Tony Whyman via Lazarus wrote: > Does this affect the Power PDF package or is this entirely independent? PowerPDF is an entirely different project. FCL-PDF is a PDF engine included as standard with FPC 3.0.2 onwards. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From list2010 at BrenemanLabs.com Thu Nov 3 17:03:32 2016 From: list2010 at BrenemanLabs.com (Paul Breneman) Date: Thu, 3 Nov 2016 11:03:32 -0500 Subject: [Lazarus] Teaching Pascal at College In-Reply-To: References: <79a0ab2e-fe39-8e8c-5fde-6b15329f5ccb@mccallumwhyman.com> <2d16cec9-a889-297c-2e9c-1c5a73943818@zoznam.sk> <6be99731f84dd3cd4176185537002d09.squirrel@gator3286.hostgator.com> <5b803e46-0bab-f5d2-e5c2-64f1ac4c90ea@lumino.de> <793c05c4-536f-7bd6-7ac0-c474041fddfa@gmx.de> <83921a7c-a7af-fd11-1198-717c1c8e2f95@lumino.de> <03a2221a-b101-3af2-e994-17babef89bd4@gmx.de> Message-ID: <5b285c58-3810-7b76-cce3-8fdda614a703@BrenemanLabs.com> On 10/27/2016 11:15 AM, Paul Breneman via Lazarus wrote: > On 10/25/2016 11:23 AM, Travis Ayres via Lazarus wrote: >> So...who wants to work on a modern course outline with me? We have a >> lot of >> opinions and people willing to chime in, maybe we can do something >> good for >> the community? > > Some suggestions: > > 1) As the OP wrote (in a later message) "All my students will be civil, > environmental or bio engineers but not computer engineers", I would > recommend checking out SoftwareCarpentry.org (see links on home page > www.ControlPascal.com ) which has been teaching basic programming to > non-programmer engineers since 1998. They've already done a *lot* of > work that doesn't need to be repeated! But a pascal version would be nice. > > 2) I just purchased the least expensive PicoScope which I hope to > combine with the Basic Stamp kit (see top of this page): > http://www.controlpascal.com/tutorial.htm > > Instant gratification (blinking LEDs, switches to push) has worked for > me and others. One of my favorite college courses (in about 1981) > combined programming and electronics, and after that I decided to jump > into embedded programming (previously I did electronic work). > > Regards, > Paul > I just added a link (to a recent magazine article on using a scope to "see" Arduino timing) to the top of this page: http://controlpascal.com/tutorial.htm Just trying to help increase embedded and hobby electronic use of Free Pascal! :) From skalogryz.lists at gmail.com Thu Nov 3 19:52:32 2016 From: skalogryz.lists at gmail.com (Dmitry Boyarintsev) Date: Thu, 3 Nov 2016 14:52:32 -0400 Subject: [Lazarus] Question about TRichMemo In-Reply-To: References: Message-ID: On Wed, Nov 2, 2016 at 10:25 PM, silvioprog via Lazarus < lazarus at lists.lazarus-ide.org> wrote: > I had some ideas, and I can send small patches showing them. For example, > what do you think about adding the GetLink() method in the TCustomRichMemo > class and the href:string attribute in the TLinkMouseInfo record? > You might want to refer to SetLink method. There's ALinkRef parameter, that serves this particular purpose. Naturally, LinkRef should end up in TLinkMouseInfo . But I'd like to note, that "Links", are yet "under construction" area. For a few reasons: * old win32 rich edit (for WindoesXP, doesn't have an api to read "href" data. However, a raw access to RTF could be used to extract it... as well as to store it) * setting up a link >>might<< (not critical at themoment) require one more piece of information: Hint text (the text that's shown in the tooltip window) However, if you implement Gtk side and add linkref or href to TLinkMouseInfo, the patch will be accepted. thanks, Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: From skalogryz.lists at gmail.com Thu Nov 3 19:53:00 2016 From: skalogryz.lists at gmail.com (Dmitry Boyarintsev) Date: Thu, 3 Nov 2016 14:53:00 -0400 Subject: [Lazarus] Question about TRichMemo In-Reply-To: <1780113d-feaf-555f-909b-f035a5b2c2a4@epidata.info> References: <1780113d-feaf-555f-909b-f035a5b2c2a4@epidata.info> Message-ID: On Thu, Nov 3, 2016 at 5:18 AM, Torsten Bonde Christiansen via Lazarus < lazarus at lists.lazarus-ide.org> wrote: > > If it all possible, can the part that generates the RichTextFormat be > moved from the component into a seperate unit. This will make it possible > to include RTF generators into eg. console programs. > Yes, it is possible thanks, Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: From skalogryz.lists at gmail.com Thu Nov 3 19:53:53 2016 From: skalogryz.lists at gmail.com (Dmitry Boyarintsev) Date: Thu, 3 Nov 2016 14:53:53 -0400 Subject: [Lazarus] Question about TRichMemo In-Reply-To: References: Message-ID: On Thu, Nov 3, 2016 at 2:52 PM, Dmitry Boyarintsev < skalogryz.lists at gmail.com> wrote: > > But I'd like to note, that "Links", are yet "under construction" area. For > a few reasons: > > one more thing: * custom RTF reader/writer must also be updated to recognize the link and use the proper API to generate one. thanks, Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvioprog at gmail.com Thu Nov 3 20:36:17 2016 From: silvioprog at gmail.com (silvioprog) Date: Thu, 3 Nov 2016 16:36:17 -0300 Subject: [Lazarus] Question about TRichMemo In-Reply-To: References: Message-ID: On Thu, Nov 3, 2016 at 3:52 PM, Dmitry Boyarintsev via Lazarus < lazarus at lists.lazarus-ide.org> wrote: > > > On Wed, Nov 2, 2016 at 10:25 PM, silvioprog via Lazarus < > lazarus at lists.lazarus-ide.org> wrote: > >> I had some ideas, and I can send small patches showing them. For example, >> what do you think about adding the GetLink() method in the TCustomRichMemo >> class and the href:string attribute in the TLinkMouseInfo record? >> > > You might want to refer to SetLink method. > So so, SetLink applies/removes a link, GetLink have a diferente purpose, it just returns the link's URL. (even in friendly name hyperlinks ) :-) > There's ALinkRef parameter, that serves this particular purpose. > Naturally, LinkRef should end up in TLinkMouseInfo . > Perfect. But I'd like to note, that "Links", are yet "under construction" area. For > a few reasons: > * old win32 rich edit (for WindoesXP, doesn't have an api to read "href" > data. However, a raw access to RTF could be used to extract it... as well > as to store it) > * setting up a link >>might<< (not critical at themoment) require one more > piece of information: Hint text (the text that's shown in the tooltip > window) > > However, if you implement Gtk side and add linkref or href to > TLinkMouseInfo, the patch will be accepted. > > thanks, > Dmitry > Done: http://bugs.freepascal.org/view.php?id=30857 . I have a question regarding SetTextUIStyle for WinVCL, its current implementation is: class procedure TRichEditManager.SetTextUIStyle(RichEditWnd: Handle; const ui: TTextUIParam); var w : WPARAM; fmt : TCHARFORMAT2; { st : TSetTextEx; linkrtf : String; txt : WideString; txtrtf : String;} begin if RichEditWnd = 0 then Exit; w := SCF_SELECTION; FillChar(fmt, sizeof(fmt), 0); fmt.cbSize := sizeof(fmt); fmt.dwMask := CFM_LINK; (* txt := GetTextW(RichEditWnd, true); st.codepage:=CP_ACP; st.flags:=ST_SELECTION; txtrtf:=txt; writeln('txtrtf = ', txtrtf); linkrtf:=Format('{\rtf1{\field{\*\fldinst{ HYPERLINK "%s"}}{\fldrslt{%s}}}}', [ui.linkref, txtrtf]); SendMessage(RichEditWnd, EM_SETTEXTEX, WPARAM(@st), LParam(@linkrtf[1])); *) if uiLink in ui.features then fmt.dwEffects := fmt.dwEffects or CFE_LINK; SendMessage(RichEditWnd, EM_SETCHARFORMAT, w, PtrInt(@fmt)); end; what about to change it to? class procedure TRichEditManager.SetTextUIStyle(RichEditWnd: Handle; const ui: TTextUIParam); var { w : WPARAM; fmt : TCHARFORMAT2;} st : TSetTextEx; linkrtf : String; txt : String; begin if RichEditWnd = 0 then Exit; (* w := SCF_SELECTION; FillChar(fmt, sizeof(fmt), 0); fmt.cbSize := sizeof(fmt); fmt.dwMask := CFM_LINK;*) txt := GetTextUtf8(RichEditWnd, true); st.codepage:=CP_UTF8; st.flags:=ST_SELECTION; linkrtf:=Concat('{\rtf1{\field{\*\fldinst{ HYPERLINK "',ui.linkref,'"}}{\fldrslt{ ',txt,' }}}}'); SendMessage(RichEditWnd, EM_SETTEXTEX, WPARAM(@st), LParam(@linkrtf[1])); (* if uiLink in ui.features then fmt.dwEffects := fmt.dwEffects or CFE_LINK; SendMessage(RichEditWnd, EM_SETCHARFORMAT, w, PtrInt(@fmt));*) end; I'm not sure about SetTextUIStyle purpose, if it just retrieve links, the implementation above is done, otherwise it needs a small change, if uiLink in ui.features it applies HYPERLINK, else it keeps EM_SETCHARFORMAT as is. Anyway, it can be the next step implementing (friendly name) hyperlinks support as soon as 30857 was applied. (I'm going to test some rtfs documents containing hyperlinks generated via RichMemo (current it does not keep hidden URLs), LibreOffice Writer and MS Word ... ). -- Silvio Clécio -------------- next part -------------- An HTML attachment was scrubbed... URL: From skalogryz.lists at gmail.com Thu Nov 3 20:48:34 2016 From: skalogryz.lists at gmail.com (Dmitry Boyarintsev) Date: Thu, 3 Nov 2016 15:48:34 -0400 Subject: [Lazarus] Question about TRichMemo In-Reply-To: References: Message-ID: On Thu, Nov 3, 2016 at 3:36 PM, silvioprog via Lazarus < lazarus at lists.lazarus-ide.org> wrote: > There's ALinkRef parameter, that serves this particular purpose. >> > Naturally, LinkRef should end up in TLinkMouseInfo . >> > > Perfect. > Now, I take that back. "ref" information might need to go to some other, rather than TLinkMouseInfo. Instead, TLinkMouseInfo should contain information about the cursor (x,y, shift state, etc) An extra parameter could be added that would contain LinkInformation I have a question regarding SetTextUIStyle for WinVCL, > Why WinVCL? :) > what about to change it to? > > txt := GetTextUtf8(RichEditWnd, true); > st.codepage:=CP_UTF8; > st.flags:=ST_SELECTION; > linkrtf:=Concat('{\rtf1{\field{\*\fldinst{ HYPERLINK > "',ui.linkref,'"}}{\fldrslt{ ',txt,' }}}}'); > SendMessage(RichEditWnd, EM_SETTEXTEX, WPARAM(@st), LParam(@linkrtf[1])); > That's fine. You just need to make sure that parameters are RTF escaped. Also, newer versions of RichEdit do provide API for Link management without need of going into raw RTF. But that's why TRichEditManager class is there (even through there's only one implementation available) thanks, Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvioprog at gmail.com Thu Nov 3 21:17:40 2016 From: silvioprog at gmail.com (silvioprog) Date: Thu, 3 Nov 2016 17:17:40 -0300 Subject: [Lazarus] Question about TRichMemo In-Reply-To: References: Message-ID: On Thu, Nov 3, 2016 at 4:48 PM, Dmitry Boyarintsev via Lazarus < lazarus at lists.lazarus-ide.org> wrote: > On Thu, Nov 3, 2016 at 3:36 PM, silvioprog via Lazarus < > lazarus at lists.lazarus-ide.org> wrote: > >> There's ALinkRef parameter, that serves this particular purpose. >>> >> Naturally, LinkRef should end up in TLinkMouseInfo . >>> >> >> Perfect. >> > Now, I take that back. > "ref" information might need to go to some other, rather than > TLinkMouseInfo. > Instead, TLinkMouseInfo should contain information about the cursor (x,y, > shift state, etc) > An extra parameter could be added that would contain LinkInformation > Do you mean about declaring an additional parameter something like this?: RichMemo1LinkAction(Sender: TObject; ALinkAction: TLinkAction; AMouseInfo: TLinkMouseInfo; *ATextInfo: TLinkTextInfo*; ALinkStart, ALinkLen: Integer); If so, it seems a great idea, and the issue #30857 needs some additional patches. :-) I have a question regarding SetTextUIStyle for WinVCL, >> > Why WinVCL? :) > Nothing special, just because some commented code there hehe... xD But what is the main purpose about SetTextUIStyle, it retrieves only links, or links and formatted texts? :-) what about to change it to? >> >> txt := GetTextUtf8(RichEditWnd, true); >> st.codepage:=CP_UTF8; >> st.flags:=ST_SELECTION; >> linkrtf:=Concat('{\rtf1{\field{\*\fldinst{ HYPERLINK >> "',ui.linkref,'"}}{\fldrslt{ ',txt,' }}}}'); >> SendMessage(RichEditWnd, EM_SETTEXTEX, WPARAM(@st), >> LParam(@linkrtf[1])); >> > > That's fine. You just need to make sure that parameters are RTF escaped. > Indeed. We need to fix that. Also, newer versions of RichEdit do provide API for Link management without > need of going into raw RTF. > > But that's why TRichEditManager class is there (even through there's only > one implementation available) > Yes. But I have an idea, we should keep Get/SetTextUIStyle and Get/SetLink supporting only raw links (as implemented above) because it is supported in mostly of richedit versions, but in future versions we should add two new Get/SetURL methods, available only on supported richedit APIs and providing all URL features. (see MS post talking about a SetURL method (ITextRange::SetURL), so we can follow the same concept :-) ) -- Silvio Clécio -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvioprog at gmail.com Thu Nov 3 21:22:35 2016 From: silvioprog at gmail.com (silvioprog) Date: Thu, 3 Nov 2016 17:22:35 -0300 Subject: [Lazarus] Question about TRichMemo In-Reply-To: References: Message-ID: Oops, On Thu, Nov 3, 2016 at 5:17 PM, silvioprog wrote: [...] > in mostly of richedit versions > I meant "in most of richedit version". ^^' -- Silvio Clécio -------------- next part -------------- An HTML attachment was scrubbed... URL: From skalogryz.lists at gmail.com Thu Nov 3 21:34:09 2016 From: skalogryz.lists at gmail.com (Dmitry Boyarintsev) Date: Thu, 3 Nov 2016 16:34:09 -0400 Subject: [Lazarus] Question about TRichMemo In-Reply-To: References: Message-ID: On Thu, Nov 3, 2016 at 4:17 PM, silvioprog via Lazarus < lazarus at lists.lazarus-ide.org> wrote: > > Nothing special, just because some commented code there hehe... xD But > what is the main purpose about SetTextUIStyle, it retrieves only links, or > links and formatted texts? :-) > > Currently, it sets/gets links only (formatted texts go with FontParams and GetTextAttributes). If more features are to be added, it might easier to extend TTextUIParam structure, rather than introducing more methods to WSclass. Something similar that happened to TFontParams. The structure didn't have Background colors or script positions (for ascended/descended texts) thanks, Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: From m-w-vogel at gmx.de Thu Nov 3 22:46:11 2016 From: m-w-vogel at gmx.de (Michael W. Vogel) Date: Thu, 3 Nov 2016 22:46:11 +0100 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: <9bc03eae-1726-2da6-488d-950785f2e606@gmx.de> References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> <2ada1f21-279c-d2cf-6105-0058932237fe@wetron.es> <5247da69-dec6-220f-118d-21a12960c829@gmx.de> <9bc03eae-1726-2da6-488d-950785f2e606@gmx.de> Message-ID: <250e7505-afed-6d4a-9b76-2651f848bd87@gmx.de> Hi, After looking a bit at this issue http://bugs.freepascal.org/view.php?id=30851, I have some general questions. Is the behaviour of Delphi more important or a user friendly one? 1. TextHint in Delphi is theme dependent and OS dependent (available for Windows Vista, Windows 7, or later), in Lazarus not. What is the desired behaviour? 2. TextHint in a TMemo isn't shown in Delphi (of course the property TextHint is there and can be written and readed). In Lazarus it is sometimes shown but not correct removed, if a line is inserted by code. Should TextHint generally not be shown in a TMemo or the bugs removed? Kind regards Michl From lazarus at kluug.net Fri Nov 4 08:35:17 2016 From: lazarus at kluug.net (Ondrej Pokorny) Date: Fri, 4 Nov 2016 08:35:17 +0100 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: <250e7505-afed-6d4a-9b76-2651f848bd87@gmx.de> References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> <2ada1f21-279c-d2cf-6105-0058932237fe@wetron.es> <5247da69-dec6-220f-118d-21a12960c829@gmx.de> <9bc03eae-1726-2da6-488d-950785f2e606@gmx.de> <250e7505-afed-6d4a-9b76-2651f848bd87@gmx.de> Message-ID: <90358539-f6c9-5444-eaf1-e330e76b0d1b@kluug.net> On 03.11.2016 22:46, Michael W. Vogel via Lazarus wrote: > 1. TextHint in Delphi is theme dependent and OS dependent (available > for Windows Vista, Windows 7, or later), in Lazarus not. What is the > desired behaviour? TextHint in Lazarus should be OS independent (it was decided long time ago). > 2. TextHint in a TMemo isn't shown in Delphi (of course the property > TextHint is there and can be written and readed). In Lazarus it is > sometimes shown but not correct removed, if a line is inserted by > code. Should TextHint generally not be shown in a TMemo or the bugs > removed? The TextHint implementation should be completely rewritten. It shouldn't use the text property but paint the TextHint onto the control by itself. Windows can do that and Qt/Gtk2 should be able to do it as well (IIRC - I talked about it with zeljko in Lazarus ML). For that some new virtual paint method (PaintAfterInterface) should be introduced - that would call the widgetset dependent PaintAfterInterface method. Ondrej From gaborboros at yahoo.com Fri Nov 4 09:47:07 2016 From: gaborboros at yahoo.com (Gabor Boros) Date: Fri, 4 Nov 2016 09:47:07 +0100 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: <90358539-f6c9-5444-eaf1-e330e76b0d1b@kluug.net> References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> <2ada1f21-279c-d2cf-6105-0058932237fe@wetron.es> <5247da69-dec6-220f-118d-21a12960c829@gmx.de> <9bc03eae-1726-2da6-488d-950785f2e606@gmx.de> <250e7505-afed-6d4a-9b76-2651f848bd87@gmx.de> <90358539-f6c9-5444-eaf1-e330e76b0d1b@kluug.net> Message-ID: <2d56197b-801f-8d95-4292-8fd86978fb55@yahoo.com> 2016. 11. 04. 8:35 keltezéssel, Ondrej Pokorny via Lazarus írta: > The TextHint implementation should be completely rewritten. It shouldn't > use the text property but paint the TextHint onto the control by itself. It's good to hear! The new implementation will be included in 1.8? Gabor From mailinglists at geldenhuys.co.uk Fri Nov 4 10:11:26 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 4 Nov 2016 09:11:26 +0000 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: <90358539-f6c9-5444-eaf1-e330e76b0d1b@kluug.net> References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> <2ada1f21-279c-d2cf-6105-0058932237fe@wetron.es> <5247da69-dec6-220f-118d-21a12960c829@gmx.de> <9bc03eae-1726-2da6-488d-950785f2e606@gmx.de> <250e7505-afed-6d4a-9b76-2651f848bd87@gmx.de> <90358539-f6c9-5444-eaf1-e330e76b0d1b@kluug.net> Message-ID: On 2016-11-04 07:35, Ondrej Pokorny via Lazarus wrote: > The TextHint implementation should be completely rewritten. It shouldn't > use the text property but paint the TextHint onto the control by itself. Very true, and using the Tex property for that is indeed a very bad idea/design. fpGUI's widgets that support TextHint does independent painting of such a hint, and obviously doesn't use the Text property for that - it works very well. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From m-w-vogel at gmx.de Fri Nov 4 10:38:16 2016 From: m-w-vogel at gmx.de (Michael W. Vogel) Date: Fri, 4 Nov 2016 10:38:16 +0100 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: <90358539-f6c9-5444-eaf1-e330e76b0d1b@kluug.net> References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> <2ada1f21-279c-d2cf-6105-0058932237fe@wetron.es> <5247da69-dec6-220f-118d-21a12960c829@gmx.de> <9bc03eae-1726-2da6-488d-950785f2e606@gmx.de> <250e7505-afed-6d4a-9b76-2651f848bd87@gmx.de> <90358539-f6c9-5444-eaf1-e330e76b0d1b@kluug.net> Message-ID: <4a248b14-02f7-c387-59a1-95bd08dd5d3a@gmx.de> Am 04.11.2016 um 08:35 schrieb Ondrej Pokorny via Lazarus: > TextHint in Lazarus should be OS independent (it was decided long time > ago). Thats fine! > The TextHint implementation should be completely rewritten. It > shouldn't use the text property but paint the TextHint onto the > control by itself. Windows can do that and Qt/Gtk2 should be able to > do it as well (IIRC - I talked about it with zeljko in Lazarus ML). > For that some new virtual paint method (PaintAfterInterface) should be > introduced - that would call the widgetset dependent > PaintAfterInterface method. Thats also fine. So it can be implemented for TComboBox (as in Delphi) too. So for now, the speed and paint issue should be fixed, later the redesign. Thank you for your hints. Kind regards Michl From lazarus at kluug.net Fri Nov 4 11:52:47 2016 From: lazarus at kluug.net (Ondrej Pokorny) Date: Fri, 4 Nov 2016 11:52:47 +0100 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: <4a248b14-02f7-c387-59a1-95bd08dd5d3a@gmx.de> References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> <2ada1f21-279c-d2cf-6105-0058932237fe@wetron.es> <5247da69-dec6-220f-118d-21a12960c829@gmx.de> <9bc03eae-1726-2da6-488d-950785f2e606@gmx.de> <250e7505-afed-6d4a-9b76-2651f848bd87@gmx.de> <90358539-f6c9-5444-eaf1-e330e76b0d1b@kluug.net> <4a248b14-02f7-c387-59a1-95bd08dd5d3a@gmx.de> Message-ID: On 04.11.2016 10:38, Michael W. Vogel via Lazarus wrote: > Thats also fine. So it can be implemented for TComboBox (as in Delphi) > too. Yes, exactly. > So for now, the speed and paint issue should be fixed, later the redesign. If the issue is a direct cause of introducing the TextHint property then I would first do the redesign and then check the issue again. I don't have time now but next week should be OK. I thought about it already a long time ago, so I have some kind of concept - I'll check with other developers first because it will mean that TextHint will stop working - the TextHint painting methods will have to be introduced for every one widgetset. But IMO it has to be done because the current TextHint implementation is a no-go for me (I use the WinAPI TextHint in my applications). On 04.11.2016 10:11, Graeme Geldenhuys via Lazarus wrote: > fpGUI's widgets that support TextHint does independent painting of > such a hint, and obviously doesn't use the Text property for that - it > works very well. You have the comfort of a custom-drawn widget set. The LCL has to paint over native controls, which is more complicated. Well, I like custom drawn widget sets more and more with the time :) Ondrej From luizamericop at gmail.com Fri Nov 4 13:16:31 2016 From: luizamericop at gmail.com (Luiz Americo Pereira Camara) Date: Fri, 4 Nov 2016 09:16:31 -0300 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> <2ada1f21-279c-d2cf-6105-0058932237fe@wetron.es> <5247da69-dec6-220f-118d-21a12960c829@gmx.de> <9bc03eae-1726-2da6-488d-950785f2e606@gmx.de> <250e7505-afed-6d4a-9b76-2651f848bd87@gmx.de> <90358539-f6c9-5444-eaf1-e330e76b0d1b@kluug.net> <4a248b14-02f7-c387-59a1-95bd08dd5d3a@gmx.de> Message-ID: In the last trunk, the slow issue is fixed regardless of usage of TextHint in TMemo or not. Fixed also not being reset after text changed / added Due to the way CharCase is implemented, the slow will manifest if this property is set to a value different from the default one Some notes: - It must be decided if TMemo.TextHint should be published. Delphi does not publish it - The implementation of TextHint using custom paint is desired but there are no reasons to postpone the mentioned fixes since they did not require any major change - Must be investigated the possibility of offloading the CharCase implementation to widgetset. The current implementation is far from optimal (at each change, uppercase/lowercase and reset the Text property) leading to performance and visual cluttering. Windows offers a native implementation. I don't know for others. An alternative is to uppercase / lowercase at keypress Luiz -------------- next part -------------- An HTML attachment was scrubbed... URL: From bartjunk64 at gmail.com Fri Nov 4 14:28:45 2016 From: bartjunk64 at gmail.com (Bart) Date: Fri, 4 Nov 2016 14:28:45 +0100 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: <90358539-f6c9-5444-eaf1-e330e76b0d1b@kluug.net> References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> <2ada1f21-279c-d2cf-6105-0058932237fe@wetron.es> <5247da69-dec6-220f-118d-21a12960c829@gmx.de> <9bc03eae-1726-2da6-488d-950785f2e606@gmx.de> <250e7505-afed-6d4a-9b76-2651f848bd87@gmx.de> <90358539-f6c9-5444-eaf1-e330e76b0d1b@kluug.net> Message-ID: On 11/4/16, Ondrej Pokorny via Lazarus wrote: > The TextHint implementation should be completely rewritten. It shouldn't > use the text property but paint the TextHint onto the control by itself. > Windows can do that and Qt/Gtk2 should be able to do it as well (IIRC - > I talked about it with zeljko in Lazarus ML). For that some new virtual > paint method (PaintAfterInterface) should be introduced - that would > call the widgetset dependent PaintAfterInterface method. The Windows API provides a nice interface to set TextHint (and the possibility to display it if control has focus, but Text is empty). At the time I implemented it, I saw no API in GTK/QT for a TextHint-like feature. Unfortunately TCustomEdit does not have a Canvas ;-) And I was unable to find a suitable way to paint over the control in a reliable way. Not messing around with RealSetText/RealGetText would of course be much more disirable. Bart From lazarus at kluug.net Fri Nov 4 15:32:41 2016 From: lazarus at kluug.net (Ondrej Pokorny) Date: Fri, 4 Nov 2016 15:32:41 +0100 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> <2ada1f21-279c-d2cf-6105-0058932237fe@wetron.es> <5247da69-dec6-220f-118d-21a12960c829@gmx.de> <9bc03eae-1726-2da6-488d-950785f2e606@gmx.de> <250e7505-afed-6d4a-9b76-2651f848bd87@gmx.de> <90358539-f6c9-5444-eaf1-e330e76b0d1b@kluug.net> <4a248b14-02f7-c387-59a1-95bd08dd5d3a@gmx.de> Message-ID: <163e1c67-d4de-a703-1713-fcdc1b904bb2@kluug.net> On 04.11.2016 13:16, Luiz Americo Pereira Camara via Lazarus wrote: > In the last trunk, the slow issue is fixed regardless of usage of > TextHint in TMemo or not. Fixed also not being reset after text > changed / added I see that r53292, r53293 and r53296 are all about TextHint - all this code will be removed if we decide to rewrite TextHint, so it was just a waste of time :( That's why I said better to wait, just to save your energy. Ondrej From zeljko at holobit.net Fri Nov 4 16:16:57 2016 From: zeljko at holobit.net (zeljko) Date: Fri, 4 Nov 2016 16:16:57 +0100 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> <2ada1f21-279c-d2cf-6105-0058932237fe@wetron.es> <5247da69-dec6-220f-118d-21a12960c829@gmx.de> <9bc03eae-1726-2da6-488d-950785f2e606@gmx.de> <250e7505-afed-6d4a-9b76-2651f848bd87@gmx.de> <90358539-f6c9-5444-eaf1-e330e76b0d1b@kluug.net> Message-ID: <233ac118-28b1-26b7-399e-fdc8a131f520@holobit.net> On 11/04/2016 02:28 PM, Bart via Lazarus wrote: > On 11/4/16, Ondrej Pokorny via Lazarus wrote: > >> The TextHint implementation should be completely rewritten. It shouldn't >> use the text property but paint the TextHint onto the control by itself. >> Windows can do that and Qt/Gtk2 should be able to do it as well (IIRC - >> I talked about it with zeljko in Lazarus ML). For that some new virtual >> paint method (PaintAfterInterface) should be introduced - that would >> call the widgetset dependent PaintAfterInterface method. > > The Windows API provides a nice interface to set TextHint (and the > possibility to display it if control has focus, but Text is empty). > At the time I implemented it, I saw no API in GTK/QT for a > TextHint-like feature. > Unfortunately TCustomEdit does not have a Canvas ;-) > And I was unable to find a suitable way to paint over the control in a > reliable way. It means exactly nothing for qt,gtk2 and carbon/cocoa, don't know about win32 but I'm pretty sure about mentioned ws. TCustomEdit uses native WS handle, so WS is taking care about painting and it does not provide PaintEvent to TCustomEdit (sure for qt,gtk2,carbon and cocoa) - so Canvas is useless in that case. Basically, WS should draw it's control and after that LCL should get PaintEvent and event stopped, so ws won't paint it again. This is possible under Qt WS (from qt5lcl it will have property for texthint, so no need to expose paintevent to lcl) but again, not sure about others. All WS api should be checked if we need paintEvent for TextHint or WS handle have property for TextHint. Probably we'll have to support both ways to get all WS functional in case of TextHint. zeljko From zeljko at holobit.net Fri Nov 4 16:18:05 2016 From: zeljko at holobit.net (zeljko) Date: Fri, 4 Nov 2016 16:18:05 +0100 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: <163e1c67-d4de-a703-1713-fcdc1b904bb2@kluug.net> References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> <2ada1f21-279c-d2cf-6105-0058932237fe@wetron.es> <5247da69-dec6-220f-118d-21a12960c829@gmx.de> <9bc03eae-1726-2da6-488d-950785f2e606@gmx.de> <250e7505-afed-6d4a-9b76-2651f848bd87@gmx.de> <90358539-f6c9-5444-eaf1-e330e76b0d1b@kluug.net> <4a248b14-02f7-c387-59a1-95bd08dd5d3a@gmx.de> <163e1c67-d4de-a703-1713-fcdc1b904bb2@kluug.net> Message-ID: On 11/04/2016 03:32 PM, Ondrej Pokorny via Lazarus wrote: > On 04.11.2016 13:16, Luiz Americo Pereira Camara via Lazarus wrote: >> In the last trunk, the slow issue is fixed regardless of usage of >> TextHint in TMemo or not. Fixed also not being reset after text >> changed / added > > I see that r53292, r53293 and r53296 are all about TextHint - all this > code will be removed if we decide to rewrite TextHint, so it was just a > waste of time :( That's why I said better to wait, just to save your > energy. No it's not. It's pure LCL implementation and I guess that we won't be able to get it handled on WS side for all widgetsets. In that case Bart's implementation will be used. zeljko From luizamericop at gmail.com Fri Nov 4 16:35:41 2016 From: luizamericop at gmail.com (Luiz Americo Pereira Camara) Date: Fri, 4 Nov 2016 12:35:41 -0300 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: <163e1c67-d4de-a703-1713-fcdc1b904bb2@kluug.net> References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> <2ada1f21-279c-d2cf-6105-0058932237fe@wetron.es> <5247da69-dec6-220f-118d-21a12960c829@gmx.de> <9bc03eae-1726-2da6-488d-950785f2e606@gmx.de> <250e7505-afed-6d4a-9b76-2651f848bd87@gmx.de> <90358539-f6c9-5444-eaf1-e330e76b0d1b@kluug.net> <4a248b14-02f7-c387-59a1-95bd08dd5d3a@gmx.de> <163e1c67-d4de-a703-1713-fcdc1b904bb2@kluug.net> Message-ID: 2016-11-04 11:32 GMT-03:00 Ondrej Pokorny via Lazarus < lazarus at lists.lazarus-ide.org>: > On 04.11.2016 13:16, Luiz Americo Pereira Camara via Lazarus wrote: > >> In the last trunk, the slow issue is fixed regardless of usage of >> TextHint in TMemo or not. Fixed also not being reset after text changed / >> added >> > > I see that r53292, r53293 and r53296 are all about TextHint - all this > code will be removed if we decide to rewrite TextHint, so it was just a > waste of time :( That's why I said better to wait, just to save your energy. > > The custom paint feature has no schedule. In the mean time, we need to fix both performance and behavior issues. If/when custom paint is implemented i will be happy to see this code removed Luiz -------------- next part -------------- An HTML attachment was scrubbed... URL: From gaborboros at yahoo.com Sat Nov 5 10:30:49 2016 From: gaborboros at yahoo.com (Gabor Boros) Date: Sat, 5 Nov 2016 10:30:49 +0100 Subject: [Lazarus] DBLookupComboBox vs Qt Message-ID: <0d805bcc-c655-b642-b1b3-351eeb345318@yahoo.com> Hi All, Created an issue in the past but got no answer. Now attached a better example project. Please try and comment. Is it a Qt bug or this is the expected behaviour? http://bugs.freepascal.org/view.php?id=28597 Gabor From zeljko at holobit.net Sat Nov 5 10:47:11 2016 From: zeljko at holobit.net (zeljko) Date: Sat, 5 Nov 2016 10:47:11 +0100 Subject: [Lazarus] DBLookupComboBox vs Qt In-Reply-To: <0d805bcc-c655-b642-b1b3-351eeb345318@yahoo.com> References: <0d805bcc-c655-b642-b1b3-351eeb345318@yahoo.com> Message-ID: <1d473598-a1c3-051c-9768-f14c20a849b7@holobit.net> On 11/05/2016 10:30 AM, Gabor Boros via Lazarus wrote: > Hi All, > > Created an issue in the past but got no answer. Now attached a better > example project. Please try and comment. Is it a Qt bug or this is the > expected behaviour? > > http://bugs.freepascal.org/view.php?id=28597 I don't use db controls at all so don't know what's exact problem. Can it be reproduced with regular TComboBox ? I cannot understand what's exact problem from issue explanation ... 1.TCombobox is empty 2.You are assigning items 3.ItemIndex should stay -1 instead of 0 (first item selected ? ) 4.What about other widgetsets ? zeljko From vfclists at gmail.com Sat Nov 5 10:50:32 2016 From: vfclists at gmail.com (vfclists .) Date: Sat, 5 Nov 2016 09:50:32 +0000 Subject: [Lazarus] Does closing a form hide it or free it? Message-ID: I have a form I use as database dialog that looks up a list of databases to connect to and when I close the form I expect it to be closed via caHide so that I can reuse it with ShowModal later, but it seems to get destroyed because Screen.FindForm doesn't locate it. The CloseAction is set to caHide. if FDatabasesDialog = nil then FDatabasesDialog := TDatabasesForm(Screen.FindForm(TDatabasesForm.ClassName)); if FDatabasesDialog = nil then FDatabasesDialog := TDatabasesForm.Create(Application); Is there some fault with this code? The only reason I can think if is that it could be down to a fault in the FindForm implementation as the Application object it still present. It is running on a 1.5 series build on Debian Linux under Qt. I will try it elsewhere if there are some bugs there. -- Frank Church ======================= http://devblog.brahmancreations.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From gaborboros at yahoo.com Sat Nov 5 11:04:37 2016 From: gaborboros at yahoo.com (Gabor Boros) Date: Sat, 5 Nov 2016 11:04:37 +0100 Subject: [Lazarus] DBLookupComboBox vs Qt In-Reply-To: <1d473598-a1c3-051c-9768-f14c20a849b7@holobit.net> References: <0d805bcc-c655-b642-b1b3-351eeb345318@yahoo.com> <1d473598-a1c3-051c-9768-f14c20a849b7@holobit.net> Message-ID: 2016. 11. 05. 10:47 keltezéssel, zeljko írta: > On 11/05/2016 10:30 AM, Gabor Boros via Lazarus wrote: >> Hi All, >> >> Created an issue in the past but got no answer. Now attached a better >> example project. Please try and comment. Is it a Qt bug or this is the >> expected behaviour? >> >> http://bugs.freepascal.org/view.php?id=28597 > > I don't use db controls at all so don't know what's exact problem. Can > it be reproduced with regular TComboBox ? I cannot understand what's > exact problem from issue explanation ... > 1.TCombobox is empty > 2.You are assigning items > 3.ItemIndex should stay -1 instead of 0 (first item selected ? ) > 4.What about other widgetsets ? Attached a screenshot to the issue. My problem is with Qt widgetset... If append a record into an empty dataset in FormShow the new record selected automatically in the DBLookupComboBox. Gabor From gaborboros at yahoo.com Sat Nov 5 11:43:49 2016 From: gaborboros at yahoo.com (Gabor Boros) Date: Sat, 5 Nov 2016 11:43:49 +0100 Subject: [Lazarus] DBLookupComboBox vs Qt In-Reply-To: <1d473598-a1c3-051c-9768-f14c20a849b7@holobit.net> References: <0d805bcc-c655-b642-b1b3-351eeb345318@yahoo.com> <1d473598-a1c3-051c-9768-f14c20a849b7@holobit.net> Message-ID: <4662393b-76e8-fbf3-e8c6-b5a4e427df1b@yahoo.com> 2016. 11. 05. 10:47 keltezéssel, zeljko írta: > On 11/05/2016 10:30 AM, Gabor Boros via Lazarus wrote: >> Hi All, >> >> Created an issue in the past but got no answer. Now attached a better >> example project. Please try and comment. Is it a Qt bug or this is the >> expected behaviour? >> >> http://bugs.freepascal.org/view.php?id=28597 > > Can it be reproduced with regular TComboBox ? I cannot understand what's > exact problem from issue explanation ... Yes I got same result with a TComboBox. See the attached screenshot, better than my description. > 1.TCombobox is empty Yes. > 2.You are assigning items Yes, in two places. In FormCreate and in FormShow. > 3.ItemIndex should stay -1 instead of 0 (first item selected ? ) No automatic selection if Items filled up in FormCreate but automatic selection if filled up in FormShow. > 4.What about other widgetsets ? On Windows works as expected. Nothing selected. (Got same result with Delphi.) Gabor From zeljko at holobit.net Sat Nov 5 13:05:35 2016 From: zeljko at holobit.net (zeljko) Date: Sat, 5 Nov 2016 13:05:35 +0100 Subject: [Lazarus] DBLookupComboBox vs Qt In-Reply-To: <4662393b-76e8-fbf3-e8c6-b5a4e427df1b@yahoo.com> References: <0d805bcc-c655-b642-b1b3-351eeb345318@yahoo.com> <1d473598-a1c3-051c-9768-f14c20a849b7@holobit.net> <4662393b-76e8-fbf3-e8c6-b5a4e427df1b@yahoo.com> Message-ID: <0741d9bb-21ff-29cf-2af0-efa2bbdc4be5@holobit.net> On 11/05/2016 11:43 AM, Gabor Boros via Lazarus wrote: > 2016. 11. 05. 10:47 keltezéssel, zeljko írta: >> On 11/05/2016 10:30 AM, Gabor Boros via Lazarus wrote: >>> Hi All, >>> >>> Created an issue in the past but got no answer. Now attached a better >>> example project. Please try and comment. Is it a Qt bug or this is the >>> expected behaviour? >>> >>> http://bugs.freepascal.org/view.php?id=28597 >> >> Can it be reproduced with regular TComboBox ? I cannot understand what's >> exact problem from issue explanation ... > > Yes I got same result with a TComboBox. See the attached screenshot, > better than my description. Ok, then please create example project with TComboBox - it's easier to fix it then. > >> 1.TCombobox is empty > > Yes. > >> 2.You are assigning items > > Yes, in two places. In FormCreate and in FormShow. > >> 3.ItemIndex should stay -1 instead of 0 (first item selected ? ) > > No automatic selection if Items filled up in FormCreate but automatic > selection if filled up in FormShow. I see, in FormShow TComboBox handle is created, so something happening at WS part. > > >> 4.What about other widgetsets ? > > On Windows works as expected. Nothing selected. (Got same result with > Delphi.) Ok, just create example project with TComboBox which reproduces problem so I'll sit with it and try to fix it somehow. zeljko From gaborboros at yahoo.com Sat Nov 5 13:25:28 2016 From: gaborboros at yahoo.com (Gabor Boros) Date: Sat, 5 Nov 2016 13:25:28 +0100 Subject: [Lazarus] DBLookupComboBox vs Qt In-Reply-To: <0741d9bb-21ff-29cf-2af0-efa2bbdc4be5@holobit.net> References: <0d805bcc-c655-b642-b1b3-351eeb345318@yahoo.com> <1d473598-a1c3-051c-9768-f14c20a849b7@holobit.net> <4662393b-76e8-fbf3-e8c6-b5a4e427df1b@yahoo.com> <0741d9bb-21ff-29cf-2af0-efa2bbdc4be5@holobit.net> Message-ID: <000a66a5-1692-c1b7-9848-9592c03d83a6@yahoo.com> 2016. 11. 05. 13:05 keltezéssel, zeljko írta: > Ok, just create example project with TComboBox which reproduces problem > so I'll sit with it and try to fix it somehow. Done. You can find as an attachment in the bugtracker. Gabor From zeljko at holobit.net Sat Nov 5 13:30:05 2016 From: zeljko at holobit.net (zeljko) Date: Sat, 5 Nov 2016 13:30:05 +0100 Subject: [Lazarus] DBLookupComboBox vs Qt In-Reply-To: <000a66a5-1692-c1b7-9848-9592c03d83a6@yahoo.com> References: <0d805bcc-c655-b642-b1b3-351eeb345318@yahoo.com> <1d473598-a1c3-051c-9768-f14c20a849b7@holobit.net> <4662393b-76e8-fbf3-e8c6-b5a4e427df1b@yahoo.com> <0741d9bb-21ff-29cf-2af0-efa2bbdc4be5@holobit.net> <000a66a5-1692-c1b7-9848-9592c03d83a6@yahoo.com> Message-ID: On 11/05/2016 01:25 PM, Gabor Boros via Lazarus wrote: > 2016. 11. 05. 13:05 keltezéssel, zeljko írta: > >> Ok, just create example project with TComboBox which reproduces problem >> so I'll sit with it and try to fix it somehow. > > Done. You can find as an attachment in the bugtracker. Tnx. zeljko From nc-gaertnma at netcologne.de Sat Nov 5 15:06:39 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Sat, 5 Nov 2016 15:06:39 +0100 (CET) Subject: [Lazarus] Does closing a form hide it or free it? In-Reply-To: References: Message-ID: <1731470300.115791.1478354799879@comcenter.netcologne.de> >  if FDatabasesDialog = nil then >     FDatabasesDialog := TDatabasesForm(Screen.FindForm(TDatabasesForm.ClassName)); FindForm finds a form by Name, not by ClassName. Mattias From zeljko at holobit.net Sat Nov 5 15:06:59 2016 From: zeljko at holobit.net (zeljko) Date: Sat, 5 Nov 2016 15:06:59 +0100 Subject: [Lazarus] DBLookupComboBox vs Qt In-Reply-To: <000a66a5-1692-c1b7-9848-9592c03d83a6@yahoo.com> References: <0d805bcc-c655-b642-b1b3-351eeb345318@yahoo.com> <1d473598-a1c3-051c-9768-f14c20a849b7@holobit.net> <4662393b-76e8-fbf3-e8c6-b5a4e427df1b@yahoo.com> <0741d9bb-21ff-29cf-2af0-efa2bbdc4be5@holobit.net> <000a66a5-1692-c1b7-9848-9592c03d83a6@yahoo.com> Message-ID: <8a39520b-5fb7-a015-0769-e8a15aa69d29@holobit.net> On 11/05/2016 01:25 PM, Gabor Boros via Lazarus wrote: > 2016. 11. 05. 13:05 keltezéssel, zeljko írta: > >> Ok, just create example project with TComboBox which reproduces problem >> so I'll sit with it and try to fix it somehow. > > Done. You can find as an attachment in the bugtracker. Fixed. zeljko From gaborboros at yahoo.com Sat Nov 5 16:19:28 2016 From: gaborboros at yahoo.com (Gabor Boros) Date: Sat, 5 Nov 2016 16:19:28 +0100 Subject: [Lazarus] DBLookupComboBox vs Qt In-Reply-To: <8a39520b-5fb7-a015-0769-e8a15aa69d29@holobit.net> References: <0d805bcc-c655-b642-b1b3-351eeb345318@yahoo.com> <1d473598-a1c3-051c-9768-f14c20a849b7@holobit.net> <4662393b-76e8-fbf3-e8c6-b5a4e427df1b@yahoo.com> <0741d9bb-21ff-29cf-2af0-efa2bbdc4be5@holobit.net> <000a66a5-1692-c1b7-9848-9592c03d83a6@yahoo.com> <8a39520b-5fb7-a015-0769-e8a15aa69d29@holobit.net> Message-ID: <2e8f79a6-a6a4-1cc6-04fe-8e171a04ff5a@yahoo.com> 2016. 11. 05. 15:06 keltezéssel, zeljko írta: > Fixed. Confirmed. Thank you very much Zeljko! Gabor From laz at vgdata.dk Sat Nov 5 16:23:47 2016 From: laz at vgdata.dk (Kaj Mikkelsen) Date: Sat, 5 Nov 2016 16:23:47 +0100 Subject: [Lazarus] Spedd buttons disappeared Message-ID: Hi I just rebuild the IDE in order to allow docking. Docking works fine, but the main speed buttons (open, run, ....) has disappeared. I have googlet for this issue, but has not been able to find anything. Does anybody knows where the speed buttons has gone, and how I get them back? /Kaj From laz at vgdata.dk Sat Nov 5 16:29:20 2016 From: laz at vgdata.dk (Kaj Mikkelsen) Date: Sat, 5 Nov 2016 16:29:20 +0100 Subject: [Lazarus] Spedd buttons disappeared In-Reply-To: References: Message-ID: Just to clarify, I run version 1.6 on mint 17.3 /Kaj On 2016-11-05 16:23, Kaj Mikkelsen via Lazarus wrote: > Hi > > > I just rebuild the IDE in order to allow docking. > Docking works fine, but the main speed buttons (open, run, ....) has > disappeared. > I have googlet for this issue, but has not been able to find anything. > > Does anybody knows where the speed buttons has gone, and how I get > them back? > > > /Kaj > From hdpc at talktalk.net Sat Nov 5 17:28:33 2016 From: hdpc at talktalk.net (Howard Page-Clark) Date: Sat, 5 Nov 2016 16:28:33 +0000 Subject: [Lazarus] Spedd buttons disappeared In-Reply-To: References: Message-ID: On 05/11/16 15:29, Kaj Mikkelsen via Lazarus wrote: > Just to clarify, I run version 1.6 on mint 17.3 > > /Kaj > > > On 2016-11-05 16:23, Kaj Mikkelsen via Lazarus wrote: >> Hi >> >> >> I just rebuild the IDE in order to allow docking. >> Docking works fine, but the main speed buttons (open, run, ....) has >> disappeared. >> I have googlet for this issue, but has not been able to find anything. >> >> Does anybody knows where the speed buttons has gone, and how I get >> them back? >> >> >> /Kaj >> > Check in the Tools->Options dialog, Environmjent node, IDE Coolbar page that [X] Coolbar is visible is checked, and that Coolbar width edit field is set to a sensible value. From laz at vgdata.dk Sat Nov 5 17:42:28 2016 From: laz at vgdata.dk (Kaj Mikkelsen) Date: Sat, 5 Nov 2016 17:42:28 +0100 Subject: [Lazarus] Spedd buttons disappeared In-Reply-To: References: Message-ID: <53e6cb61-bb6c-65a0-5d75-1031317df2d8@vgdata.dk> That did the trick. Thanks! Been running through those options many times, but didnt realize, that it was the coolbar I should look at. /Kaj On 2016-11-05 17:28, Howard Page-Clark via Lazarus wrote: > On 05/11/16 15:29, Kaj Mikkelsen via Lazarus wrote: >> Just to clarify, I run version 1.6 on mint 17.3 >> >> /Kaj >> >> >> On 2016-11-05 16:23, Kaj Mikkelsen via Lazarus wrote: >>> Hi >>> >>> >>> I just rebuild the IDE in order to allow docking. >>> Docking works fine, but the main speed buttons (open, run, ....) has >>> disappeared. >>> I have googlet for this issue, but has not been able to find anything. >>> >>> Does anybody knows where the speed buttons has gone, and how I get >>> them back? >>> >>> >>> /Kaj >>> >> > Check in the Tools->Options dialog, Environmjent node, IDE Coolbar > page that > > [X] Coolbar is visible is checked, and that > > Coolbar width edit field is set to a sensible value. > From getmem1 at gmail.com Sun Nov 6 11:14:20 2016 From: getmem1 at gmail.com (=?UTF-8?Q?Bal=C3=A1zs_Sz=C3=A9kely?=) Date: Sun, 6 Nov 2016 03:14:20 -0700 (MST) Subject: [Lazarus] Lazarus Version Message-ID: <1478427260700-4050205.post@n3.nabble.com> Hi, Is there a way to get Lazarus version from a package? I know about LazarusVersionStr constant from {$LazarusDir}/IDE/lazconfig.pp, but that's not accessible from a package. I can create a patch if necessary, but I was hopping somebody already did it. Thanks you! Balázs -- View this message in context: http://free-pascal-lazarus.989080.n3.nabble.com/Lazarus-Version-tp4050205.html Sent from the Free Pascal - Lazarus mailing list archive at Nabble.com. From nc-gaertnma at netcologne.de Sun Nov 6 11:35:34 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Sun, 6 Nov 2016 11:35:34 +0100 (CET) Subject: [Lazarus] Lazarus Version In-Reply-To: <1478427260700-4050205.post@n3.nabble.com> References: <1478427260700-4050205.post@n3.nabble.com> Message-ID: <511638044.118941.1478428534352@comcenter.netcologne.de> > Balázs Székely via Lazarus hat am 6. November 2016 um 11:14 geschrieben: > > Hi, > > Is there a way to get Lazarus version from a package? > I know about LazarusVersionStr constant from {$LazarusDir}/IDE/lazconfig.pp, > but that's not accessible from a package. I can create a patch if necessary, > but I was hopping somebody already did it. Use unit lclversion. Mattias From getmem1 at gmail.com Sun Nov 6 11:54:31 2016 From: getmem1 at gmail.com (=?UTF-8?Q?Bal=C3=A1zs_Sz=C3=A9kely?=) Date: Sun, 6 Nov 2016 03:54:31 -0700 (MST) Subject: [Lazarus] Lazarus Version In-Reply-To: <511638044.118941.1478428534352@comcenter.netcologne.de> References: <1478427260700-4050205.post@n3.nabble.com> <511638044.118941.1478428534352@comcenter.netcologne.de> Message-ID: <1478429671746-4050207.post@n3.nabble.com> >>@Mattias >>Use unit lclversion. Thank you! :) Balázs -- View this message in context: http://free-pascal-lazarus.989080.n3.nabble.com/Lazarus-Version-tp4050205p4050207.html Sent from the Free Pascal - Lazarus mailing list archive at Nabble.com. From michael at freepascal.org Sun Nov 6 11:59:44 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Sun, 6 Nov 2016 11:59:44 +0100 (CET) Subject: [Lazarus] Lazarus Version In-Reply-To: <511638044.118941.1478428534352@comcenter.netcologne.de> References: <1478427260700-4050205.post@n3.nabble.com> <511638044.118941.1478428534352@comcenter.netcologne.de> Message-ID: On Sun, 6 Nov 2016, Mattias Gaertner via Lazarus wrote: > >> Balázs Székely via Lazarus hat am 6. November 2016 um 11:14 geschrieben: >> >> Hi, >> >> Is there a way to get Lazarus version from a package? >> I know about LazarusVersionStr constant from {$LazarusDir}/IDE/lazconfig.pp, >> but that's not accessible from a package. I can create a patch if necessary, >> but I was hopping somebody already did it. > > Use unit lclversion. It would be good to have an option in the package system to write and/or register the package version somewhere, so it is accessible at runtime, and an application can query the various packages and their versions. I have integrated such a registration in my build system, but a 'native' solution would be preferable. Just a thought. Michael. From juergen.hestermann at gmx.de Sun Nov 6 12:27:52 2016 From: juergen.hestermann at gmx.de (=?UTF-8?Q?J=c3=bcrgen_Hestermann?=) Date: Sun, 6 Nov 2016 12:27:52 +0100 Subject: [Lazarus] Exception in OnResize event handler Message-ID: <77b9104a-b2ec-edfd-6d80-dd37fe533ed7@gmx.de> In one of my Windows programs I use a splitter to separate two VirtualTreeView components on a Form. The relation of the heights of these two VirtualTreeView components should be constant even if the height of the Form changed. To achieve this, the two VirtualTreeView components are anchored to the splitter and I use the OnResize event to move the splitter in case the height of the form has changed. This works well except for one very special case: If I type (on Windows 8.1) Windows key + arrow down three times and then go to the (now invisible program) with Alt+Tab then the program is shown again but consists of the Windows header with the standard icons for minimize, maximize and close only. If I then click on the icon to maximize the program I get an exception in TControl.InvalidatePreferredSize where RaiseLoop is executed. This only happens when I use the above key combinations. I don't know what the exception actually means and how I can avoid this crash. Any ideas? BTW: The help in Lazarus about the OnResize event says: "This event is triggered after the Width, Height, ClientWidth or ClientHeight of the control has changed, and before the LCL sends the new size to the widgetset. The size of the underlying widget (e.g. unit LCLIntf function GetWindowSize and GetClientRect) may differ from the control's Width/Height/ClientRect during OnResize. During autosize the size can change multiple times, but only the last change triggers the OnResize." [...] "Especially it is not sufficient to write only a TForm.OnResize handler to resize all controls on the form. This is a common bug in Delphi applications." What does the last sentence mean? What else is needed to resize all controls on the form? From vfclists at gmail.com Sun Nov 6 12:35:10 2016 From: vfclists at gmail.com (vfclists .) Date: Sun, 6 Nov 2016 11:35:10 +0000 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: <720ab092ae799b63946c94c8842c0b6e.squirrel@gator3286.hostgator.com> References: <20161021111331.0846d181@limapholos.matflo.wg> <0690e875-8608-c93d-ce39-f86e7a0bf5e3@geldenhuys.co.uk> <20161021120507.33bf5fdd@limapholos.matflo.wg> <20161022233647.63d1d853@limapholos.matflo.wg> <0ccf92ea-c2ce-8c1d-cec1-bf0777619b41@geldenhuys.co.uk> <720ab092ae799b63946c94c8842c0b6e.squirrel@gator3286.hostgator.com> Message-ID: On 24 October 2016 at 00:34, Lars via Lazarus wrote: > Now that I think about my post about using chromium embedded for a help > engine, the issue I see is that it's a large dependency .. so for small > applications that are say 1MB large, and you want to supply a help system > with it... all of a sudden the 1mb exe has to be shipped with a gazillion > other files that wouldn't be needed with a more simple format. > > Still, I think I will try to release a help system for powtils using > chromium embedded, as an offline experiment with CGI (no web server > needed). However this will take time, and I almost feel like I posted that > chromium idea drunk, even though I was not drinking. > > On Sat, October 22, 2016 5:24 pm, Graeme Geldenhuys via Lazarus wrote: > > On 2016-10-22 22:36, Mattias Gaertner via Lazarus wrote: > > > >> Is this a problem of the CHM producer or the CHM viewer? > >> > > > > Both. The LaTeX-to-HTML conversion is definitely not great. Michael > > would agree on this one. Then taking that already bad HTML and converting > > in to CHM, makes the end result even worse. That doesn't do any justices > > for Michael's hard work in writing the documentation and having it > > beautifully presented (like the official PDF versions). > .... > -- > _______________________________________________ > Lazarus mailing list > Lazarus at lists.lazarus-ide.org > http://lists.lazarus-ide.org/listinfo/lazarus > I think using CEF is fine as there don't seem to be any other realistic options. That is the situation as it is. Something which is likely to get more support is "more better" than a perfect but little used and little known system. A Lazarus installation currently takes over 1 Gb, so what difference does another 300Mb make to it when it is something as critical as help? INF files and viewers may be fine, but besides Graeme who is willing to make the time and effort to learn it well enough to support Graeme to develop it further? It may sound cynical but that is the state of contemporary systems development where the idea is to settle for less than ideal systems and hope that by throwing enough people at these sub par systems the flaws will be worked out, or made "good enough". -- Frank Church ======================= http://devblog.brahmancreations.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From vfclists at gmail.com Sun Nov 6 12:44:26 2016 From: vfclists at gmail.com (vfclists .) Date: Sun, 6 Nov 2016 11:44:26 +0000 Subject: [Lazarus] Does closing a form hide it or free it? In-Reply-To: <1731470300.115791.1478354799879@comcenter.netcologne.de> References: <1731470300.115791.1478354799879@comcenter.netcologne.de> Message-ID: On 5 November 2016 at 14:06, Mattias Gaertner via Lazarus < lazarus at lists.lazarus-ide.org> wrote: > > if FDatabasesDialog = nil then > > FDatabasesDialog := TDatabasesForm(Screen.FindForm(TDatabasesForm. > ClassName)); > > FindForm finds a form by Name, not by ClassName. > > Mattias > -- > _______________________________________________ > Lazarus mailing list > Lazarus at lists.lazarus-ide.org > http://lists.lazarus-ide.org/listinfo/lazarus > FindForm depends on the ClassName, usuing Screen.FindForm(TDatabasesForm.Name) gave the error: Error: Only class methods, class properties and class variables can be referred with class references Any way my use of the Screen.FindForm routine was wrong I had a FindForm routine of my own and I assumed that the built in one worked similarly. I think I switched to the built in because it handles DataModules where as mine worked on forms. function FindForm(formClass: string):TForm; var i: integer; upFormClass: string; begin result := nil; upformClass := UpperCase(formClass); for i := 0 to Screen.FormCount-1 do begin if UpperCase(Screen.Forms[i].ClassName) = upFormClass then begin result := Screen.Forms[i]; end; end; end; -- Frank Church ======================= http://devblog.brahmancreations.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nc-gaertnma at netcologne.de Sun Nov 6 12:45:34 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Sun, 6 Nov 2016 12:45:34 +0100 (CET) Subject: [Lazarus] Exception in OnResize event handler In-Reply-To: <77b9104a-b2ec-edfd-6d80-dd37fe533ed7@gmx.de> References: <77b9104a-b2ec-edfd-6d80-dd37fe533ed7@gmx.de> Message-ID: <244160755.119462.1478432734218@comcenter.netcologne.de> > Jürgen Hestermann via Lazarus hat am 6. November 2016 um 12:27 geschrieben: >[...] > "Especially it is not sufficient to write only a TForm.OnResize handler > to resize all controls on the form. This is a common bug in Delphi applications." > > What does the last sentence mean? For example a TButton in a TGroupBox in a TForm. When the theme changes, the GroupBox client area may change, and the form's client area not. Then form's OnResize is not triggered. You need to set the GroupBox.OnResize event. > What else is needed to resize all controls on the form? Depending on your layout you may need to set more Control OnResize events. Mattias From juergen.hestermann at gmx.de Sun Nov 6 13:03:13 2016 From: juergen.hestermann at gmx.de (=?UTF-8?Q?J=c3=bcrgen_Hestermann?=) Date: Sun, 6 Nov 2016 13:03:13 +0100 Subject: [Lazarus] Exception in OnResize event handler In-Reply-To: <244160755.119462.1478432734218@comcenter.netcologne.de> References: <77b9104a-b2ec-edfd-6d80-dd37fe533ed7@gmx.de> <244160755.119462.1478432734218@comcenter.netcologne.de> Message-ID: Am 2016-11-06 um 12:45 schrieb Mattias Gaertner via Lazarus: > For example a TButton in a TGroupBox in a TForm. > When the theme changes, the GroupBox client area may change, > and the form's client area not. > Then form's OnResize is not triggered. > You need to set the GroupBox.OnResize event. Then this seems to be unrelated to my problem. It's not that the OnResize event is *not* triggered but that it is triggered but then leads to the RaiseLoop exception. BTW: The wording of the help is misleading. It says: "Common mistake: Keep in mind that ClientWidth and ClientHeight can change even when Width, Height stays the same" but it also says: "This event is triggered after the Width, Height, ClientWidth or ClientHeight of the control has changed" When OnResize is triggered even when ClientWidth or ClientHeight has changed then the "Common mistake"-sentence makes no sense to me. From fjf.vanleeuwen at quicknet.nl Sun Nov 6 13:06:08 2016 From: fjf.vanleeuwen at quicknet.nl (Frans) Date: Sun, 6 Nov 2016 13:06:08 +0100 Subject: [Lazarus] Where is TSynMemo? Message-ID: <879f6411-60c8-5648-c006-06ff92ebc3f5@quicknet.nl> Hi. I'm using Lazarus 1.6 and FPC 3.0.0. on Windows 7. I've installed the SynEdit 1.0 and the SynEditDsgn 1.0 package. But strangely enough, I don't seem to have TSynMemo available. Stranger I find is the example SynAnyHighlighter. This uses TSynMemo and I can open this example in my IDE and compile it without any problems. And TSynMemo is on the Form, it's not in the code. The list of Components also can't find TSynMemo. Am I forgetting something? -- mvg Frans van Leeuwen M 06-51695390 From zeljko at holobit.net Sun Nov 6 15:42:06 2016 From: zeljko at holobit.net (zeljko) Date: Sun, 6 Nov 2016 15:42:06 +0100 Subject: [Lazarus] Where is TSynMemo? In-Reply-To: <879f6411-60c8-5648-c006-06ff92ebc3f5@quicknet.nl> References: <879f6411-60c8-5648-c006-06ff92ebc3f5@quicknet.nl> Message-ID: <66095cf6-b8b7-2a23-9a74-81ac91fcf2a9@holobit.net> On 11/06/2016 01:06 PM, Frans via Lazarus wrote: > Hi. > > I'm using Lazarus 1.6 and FPC 3.0.0. on Windows 7. I've installed the > SynEdit 1.0 and the SynEditDsgn 1.0 package. > But strangely enough, I don't seem to have TSynMemo available. > Stranger I find is the example SynAnyHighlighter. This uses TSynMemo and > I can open this example in my IDE and compile it without any problems. > And TSynMemo is on the Form, it's not in the code. > The list of Components also can't find TSynMemo. > Am I forgetting something? AFAIR, TSynMemo is deprecated, use TSynEdit zeljko From lazarus at kluug.net Sun Nov 6 16:08:48 2016 From: lazarus at kluug.net (Ondrej Pokorny) Date: Sun, 6 Nov 2016 16:08:48 +0100 Subject: [Lazarus] Exception in OnResize event handler In-Reply-To: References: <77b9104a-b2ec-edfd-6d80-dd37fe533ed7@gmx.de> <244160755.119462.1478432734218@comcenter.netcologne.de> Message-ID: <850aec5b-001e-d833-304d-15e7576cb194@kluug.net> On 06.11.2016 13:03, Jürgen Hestermann via Lazarus wrote: > BTW: > The wording of the help is misleading. > It says: > > "Common mistake: Keep in mind that ClientWidth and ClientHeight can > change even when Width, Height stays the same" > > but it also says: > > "This event is triggered after the Width, Height, ClientWidth or > ClientHeight of the control has changed" > > When OnResize is triggered even when ClientWidth or ClientHeight has > changed then > the "Common mistake"-sentence makes no sense to me. Why? It's good additional information. Ondrej From juergen.hestermann at gmx.de Sun Nov 6 16:24:51 2016 From: juergen.hestermann at gmx.de (=?UTF-8?Q?J=c3=bcrgen_Hestermann?=) Date: Sun, 6 Nov 2016 16:24:51 +0100 Subject: [Lazarus] Exception in OnResize event handler In-Reply-To: <850aec5b-001e-d833-304d-15e7576cb194@kluug.net> References: <77b9104a-b2ec-edfd-6d80-dd37fe533ed7@gmx.de> <244160755.119462.1478432734218@comcenter.netcologne.de> <850aec5b-001e-d833-304d-15e7576cb194@kluug.net> Message-ID: <33aea97d-9ad4-72f1-4b24-0332ae3ebb82@gmx.de> Am 2016-11-06 um 16:08 schrieb Ondrej Pokorny via Lazarus: > On 06.11.2016 13:03, Jürgen Hestermann via Lazarus wrote: >> The wording of the help is misleading. >> It says: >> "Common mistake: Keep in mind that ClientWidth and ClientHeight can change even when Width, Height stays the same" >> but it also says: >> "This event is triggered after the Width, Height, ClientWidth or ClientHeight of the control has changed" >> When OnResize is triggered even when ClientWidth or ClientHeight has changed then >> the "Common mistake"-sentence makes no sense to me. > Why? It's good additional information. The sentence "Common mistake: Keep in mind that ClientWidth and ClientHeight can change even when Width, Height stays the same" makes me think that the event is not triggered when *Client*Width/-Height changes but only when Width/Height changes (why else would there be a "common mistake"?) but actually it is triggered in both cases. From lazarus at kluug.net Sun Nov 6 16:26:01 2016 From: lazarus at kluug.net (Ondrej Pokorny) Date: Sun, 6 Nov 2016 16:26:01 +0100 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> <2ada1f21-279c-d2cf-6105-0058932237fe@wetron.es> <5247da69-dec6-220f-118d-21a12960c829@gmx.de> <9bc03eae-1726-2da6-488d-950785f2e606@gmx.de> <250e7505-afed-6d4a-9b76-2651f848bd87@gmx.de> <90358539-f6c9-5444-eaf1-e330e76b0d1b@kluug.net> <4a248b14-02f7-c387-59a1-95bd08dd5d3a@gmx.de> <163e1c67-d4de-a703-1713-fcdc1b904bb2@kluug.net> Message-ID: <6602f2d5-51fc-6129-532d-f7569c9d54db@kluug.net> On 04.11.2016 16:18, zeljko wrote: > On 11/04/2016 03:32 PM, Ondrej Pokorny via Lazarus wrote: >> On 04.11.2016 13:16, Luiz Americo Pereira Camara via Lazarus wrote: >>> In the last trunk, the slow issue is fixed regardless of usage of >>> TextHint in TMemo or not. Fixed also not being reset after text >>> changed / added >> >> I see that r53292, r53293 and r53296 are all about TextHint - all this >> code will be removed if we decide to rewrite TextHint, so it was just a >> waste of time :( That's why I said better to wait, just to save your >> energy. > > No it's not. It's pure LCL implementation and I guess that we won't be > able to get it handled on WS side for all widgetsets. In that case > Bart's implementation will be used. The current implementation opened many issues and bugs. You probably won't be able to solve some of them at all or at a reasonable effort (both for development and maintenance). E.g. try to set the edit font color while the text hint is shown: Edit1.Font.Color := clRed; // << execute when TextHint is visible I remember from last year that the TextHint sometimes even wasn't correctly hidden. From that point I have never used it. My opinion is that the current implementation of TextHint should be completely removed. Even if TextHint won't be supported on all widgetsets. Sometimes it's better to have nothing than to have a bad solution. You said Qt5 has native support, so has WinAPI, Qt4 can be solved with custom painting -> not a bad start at all. Then there is the question about using the native TextHint. E.g. WinAPI supports it but doesn't support custom TextHintFontColor and TextHintFontStyle - so what to do if we decide to use native TextHint support? My opinion is to keep things simple and both TextHintFontColor and TextHintFontStyle should be removed because they are superfluous. Is TextHintFontColor and TextHintFontStyle supported natively on Qt5? Using Text and Font properties for an informative-only and inessential feature is just a rape of that properties. I mean everybody can do it in his own programs but to have such a solution on LCL level is not acceptable, in my eyes. In any case: if the TextHint property doesn't work, your programs won't stop working. On 04.11.2016 14:28, Bart via Lazarus wrote: > The Windows API provides a nice interface to set TextHint (and the > possibility to display it if control has focus, but Text is empty). At > the time I implemented it, I saw no API in GTK/QT for a TextHint-like > feature. I see all you say. It was still a bad idea :) Ondrej -------------- next part -------------- An HTML attachment was scrubbed... URL: From lazarus at kluug.net Sun Nov 6 16:39:56 2016 From: lazarus at kluug.net (Ondrej Pokorny) Date: Sun, 6 Nov 2016 16:39:56 +0100 Subject: [Lazarus] Exception in OnResize event handler In-Reply-To: <33aea97d-9ad4-72f1-4b24-0332ae3ebb82@gmx.de> References: <77b9104a-b2ec-edfd-6d80-dd37fe533ed7@gmx.de> <244160755.119462.1478432734218@comcenter.netcologne.de> <850aec5b-001e-d833-304d-15e7576cb194@kluug.net> <33aea97d-9ad4-72f1-4b24-0332ae3ebb82@gmx.de> Message-ID: <5a65f0a5-b565-30b6-f2c6-a14cf0efbeee@kluug.net> On 06.11.2016 16:24, Jürgen Hestermann via Lazarus wrote: > Am 2016-11-06 um 16:08 schrieb Ondrej Pokorny via Lazarus: > > On 06.11.2016 13:03, Jürgen Hestermann via Lazarus wrote: > >> The wording of the help is misleading. > >> It says: > >> "Common mistake: Keep in mind that ClientWidth and ClientHeight can > change even when Width, Height stays the same" > >> but it also says: > >> "This event is triggered after the Width, Height, ClientWidth or > ClientHeight of the control has changed" > >> When OnResize is triggered even when ClientWidth or ClientHeight > has changed then > >> the "Common mistake"-sentence makes no sense to me. > > Why? It's good additional information. > > The sentence > > "Common mistake: Keep in mind that ClientWidth and ClientHeight can > change even when Width, Height stays the same" > > makes me think that the event is not triggered when > *Client*Width/-Height changes > but only when Width/Height changes (why else would there be a "common > mistake"?) > but actually it is triggered in both cases. The sentence doesn't say anything about when OnResize is triggered so it doesn't make me think anything about OnResize triggers. Don't be like a woman who always finds much more meanings in her husband's words than he had in mind, all leading to problems :) Ondrej From zeljko at holobit.net Sun Nov 6 16:45:20 2016 From: zeljko at holobit.net (zeljko) Date: Sun, 6 Nov 2016 16:45:20 +0100 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: <6602f2d5-51fc-6129-532d-f7569c9d54db@kluug.net> References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> <2ada1f21-279c-d2cf-6105-0058932237fe@wetron.es> <5247da69-dec6-220f-118d-21a12960c829@gmx.de> <9bc03eae-1726-2da6-488d-950785f2e606@gmx.de> <250e7505-afed-6d4a-9b76-2651f848bd87@gmx.de> <90358539-f6c9-5444-eaf1-e330e76b0d1b@kluug.net> <4a248b14-02f7-c387-59a1-95bd08dd5d3a@gmx.de> <163e1c67-d4de-a703-1713-fcdc1b904bb2@kluug.net> <6602f2d5-51fc-6129-532d-f7569c9d54db@kluug.net> Message-ID: <45adb8fb-713b-cf94-298e-de771df7a233@holobit.net> On 11/06/2016 04:26 PM, Ondrej Pokorny via Lazarus wrote: > Then there is the question about using the native TextHint. E.g. WinAPI > supports it but doesn't support custom TextHintFontColor and > TextHintFontStyle - so what to do if we decide to use native TextHint > support? My opinion is to keep things simple and both TextHintFontColor > and TextHintFontStyle should be removed because they are superfluous. Is > TextHintFontColor and TextHintFontStyle supported natively on Qt5? No, I don't know any widgetset which supports different font color/style for texthint. zeljko From zeljko at holobit.net Sun Nov 6 16:48:48 2016 From: zeljko at holobit.net (zeljko) Date: Sun, 6 Nov 2016 16:48:48 +0100 Subject: [Lazarus] Exception in OnResize event handler In-Reply-To: <5a65f0a5-b565-30b6-f2c6-a14cf0efbeee@kluug.net> References: <77b9104a-b2ec-edfd-6d80-dd37fe533ed7@gmx.de> <244160755.119462.1478432734218@comcenter.netcologne.de> <850aec5b-001e-d833-304d-15e7576cb194@kluug.net> <33aea97d-9ad4-72f1-4b24-0332ae3ebb82@gmx.de> <5a65f0a5-b565-30b6-f2c6-a14cf0efbeee@kluug.net> Message-ID: <70c4f157-7b9a-d137-0deb-5ba33b1e0758@holobit.net> On 11/06/2016 04:39 PM, Ondrej Pokorny via Lazarus wrote: > Don't be like a woman who always finds much more meanings in her > husband's words than he had in mind, all leading to problems :) X :))))) zeljko From michael at freepascal.org Sun Nov 6 18:05:39 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Sun, 6 Nov 2016 18:05:39 +0100 (CET) Subject: [Lazarus] ctrl-c code completion Message-ID: Hi, Why does the IDE insist on reformatting existing declarations ? I added 1 method to TStrings, press ctrl-c to do command-completion, and it changes the headers of all methods, changing - Function to function, - Procedure to procedure - and the setter in property Values[const Name: string]: string read GetValue write SetValue; is changed from procedure SetValue(const Name, Value: string); to procedure SetValue(const Name : string; Const Value: string); Causing the compiler to generate an error... I can appreciate that the latter is difficult to handle, but the former is really annoying. An svn diff consists out of 90%+ junk after that :/ Michael. From bartjunk64 at gmail.com Sun Nov 6 18:37:01 2016 From: bartjunk64 at gmail.com (Bart) Date: Sun, 6 Nov 2016 18:37:01 +0100 Subject: [Lazarus] ctrl-c code completion In-Reply-To: References: Message-ID: On 11/6/16, Michael Van Canneyt via Lazarus wrote: > Why does the IDE insist on reformatting existing declarations ? Tools->Options->Codetools->Class Completion Uncheck: "Update all method signatures" ? Bart From juergen.hestermann at gmx.de Sun Nov 6 19:08:43 2016 From: juergen.hestermann at gmx.de (=?UTF-8?Q?J=c3=bcrgen_Hestermann?=) Date: Sun, 6 Nov 2016 19:08:43 +0100 Subject: [Lazarus] Exception in OnResize event handler In-Reply-To: <5a65f0a5-b565-30b6-f2c6-a14cf0efbeee@kluug.net> References: <77b9104a-b2ec-edfd-6d80-dd37fe533ed7@gmx.de> <244160755.119462.1478432734218@comcenter.netcologne.de> <850aec5b-001e-d833-304d-15e7576cb194@kluug.net> <33aea97d-9ad4-72f1-4b24-0332ae3ebb82@gmx.de> <5a65f0a5-b565-30b6-f2c6-a14cf0efbeee@kluug.net> Message-ID: <5188bd98-ac66-6102-f5f6-5523646a94c8@gmx.de> Am 2016-11-06 um 16:39 schrieb Ondrej Pokorny via Lazarus: >> The sentence >> "Common mistake: Keep in mind that ClientWidth and ClientHeight can change even when Width, Height stays the same" >> makes me think that the event is not triggered when *Client*Width/-Height changes >> but only when Width/Height changes (why else would there be a "common mistake"?) >> but actually it is triggered in both cases. > The sentence doesn't say anything about when OnResize is triggered so it doesn't make me think anything about OnResize triggers. Then I don't know what the text is about at all. It warns but does not say against what. From mailinglists at geldenhuys.co.uk Sun Nov 6 21:18:48 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Sun, 6 Nov 2016 20:18:48 +0000 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: References: <20161021111331.0846d181@limapholos.matflo.wg> <0690e875-8608-c93d-ce39-f86e7a0bf5e3@geldenhuys.co.uk> <20161021120507.33bf5fdd@limapholos.matflo.wg> <20161022233647.63d1d853@limapholos.matflo.wg> <0ccf92ea-c2ce-8c1d-cec1-bf0777619b41@geldenhuys.co.uk> <720ab092ae799b63946c94c8842c0b6e.squirrel@gator3286.hostgator.com> Message-ID: On 2016-11-06 11:35, vfclists . via Lazarus wrote: > I think using CEF is fine as there don't seem to be any other realistic > options. That is the situation as it is. No it's not! If you have a login for Lazarus Forum's, check out this post with a fully functional application with context sensitive help. That's an application (small), help contents and a help viewer - all under 2MB in size. http://forum.lazarus.freepascal.org/index.php/topic,30421.msg193651.html#msg193651 > known system. A Lazarus installation currently takes over 1 Gb, so what > difference does another 300Mb make to it when it is something as critical > as help? If anybody things installing 300MB just to get some lousy help for a small 1MB application is acceptable, then you need to seriously re-evaluate your career as a software developer. Also, my clients don't have Lazarus installed, so 300MB 3rd party files for a 1-10MB application is a MAJOR issue! For online distribution and online updates, size does matter. > INF files and viewers may be fine, but besides Graeme who is > willing to make the time and effort to learn it well enough to support > Graeme to develop it further? I'm more than willing to implement any new feature I deem worthy or beneficial for a help system. IBM did a stellar job designing the INF help system, and it was also used for eBooks - 10+ years ahead of the likes of ePub, AZW etc. I've said it a million times before, HTML is the worst markup for a help system. It's just to verbose, and the HTML Viewers are too inconsistent with features they support. Read my previous posts on all the features that INF and DocView supports. I'm not bothered about popularity contests, so if nobody else uses INF, there loss. I can say that I've used it for years in my own applications and 4 of my past clients use it in commercial software too. > hope that by throwing enough people at these sub par systems the flaws will > be worked out, or made "good enough". I welcome your thoughts on why you think INF or DocView would be sub par? ps: Did you see the sub par user experience is these CHM files? http://geldenhuys.co.uk/~graemeg/temp/kchmviewer_vs_lhelp.png http://geldenhuys.co.uk/~graemeg/temp/kchmviewer_vs_lhelp_2.png Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From michael at freepascal.org Sun Nov 6 23:04:54 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Sun, 6 Nov 2016 23:04:54 +0100 (CET) Subject: [Lazarus] ctrl-c code completion In-Reply-To: References: Message-ID: On Sun, 6 Nov 2016, Bart via Lazarus wrote: > On 11/6/16, Michael Van Canneyt via Lazarus > wrote: > >> Why does the IDE insist on reformatting existing declarations ? > > Tools->Options->Codetools->Class Completion > Uncheck: "Update all method signatures" ? Well, thank you very much. I should visit those options pages more often... Michael. From mailinglists at geldenhuys.co.uk Mon Nov 7 00:20:55 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Sun, 6 Nov 2016 23:20:55 +0000 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: References: Message-ID: On 2016-10-21 09:58, Graeme Geldenhuys via Lazarus wrote: > It was surprisingly hard to find a solution, especially something > cross-platform. In the end I researched help formats with the goal to > implement our own help viewer. We looked at Microsoft's HLP, CHM > formats, IBM's INF, OpenOffice's help, Gnome's help sytem and a few others. I thought I should elaborate on this process a bit, after reading Frank's last message - in case somebody else gets the wrong impression. The research wasn't a quick search on the Internet one afternoon. Cross-Platform Help was very important to my employer. We spent 3 months researching and evaluating help viewers and help formats. We did extensive testing and looking at all aspects around help - from ease of authoring help, efficiency of file formats, file sizes and help viewers. After all that, I think we came up with a very good choice, and a solution that ticked all our requirements. My employer was also kind enough to donate back all the work that was put into it, hoping others would benefit from this. After all, they benefited hugely from all the effort others put into Free Pascal and Lazarus. Regards, Graeme From mailinglists at geldenhuys.co.uk Mon Nov 7 00:39:51 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Sun, 6 Nov 2016 23:39:51 +0000 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: <45adb8fb-713b-cf94-298e-de771df7a233@holobit.net> References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> <2ada1f21-279c-d2cf-6105-0058932237fe@wetron.es> <5247da69-dec6-220f-118d-21a12960c829@gmx.de> <9bc03eae-1726-2da6-488d-950785f2e606@gmx.de> <250e7505-afed-6d4a-9b76-2651f848bd87@gmx.de> <90358539-f6c9-5444-eaf1-e330e76b0d1b@kluug.net> <4a248b14-02f7-c387-59a1-95bd08dd5d3a@gmx.de> <163e1c67-d4de-a703-1713-fcdc1b904bb2@kluug.net> <6602f2d5-51fc-6129-532d-f7569c9d54db@kluug.net> <45adb8fb-713b-cf94-298e-de771df7a233@holobit.net> Message-ID: <529cc3b5-f72b-ada2-e378-bff8d5bbb325@geldenhuys.co.uk> On 2016-11-06 15:45, zeljko via Lazarus wrote: > No, I don't know any widgetset which supports different font color/style > for texthint. fpGUI does - for some years now. ;-) I also implemented a specific colour alias constant (clPlaceholderText) and alias font name, to make it easier to customise in user-defined custom style classes. Regards, Graeme From mse00000 at gmail.com Mon Nov 7 07:39:45 2016 From: mse00000 at gmail.com (Martin Schreiber) Date: Mon, 7 Nov 2016 07:39:45 +0100 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: <529cc3b5-f72b-ada2-e378-bff8d5bbb325@geldenhuys.co.uk> References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> <45adb8fb-713b-cf94-298e-de771df7a233@holobit.net> <529cc3b5-f72b-ada2-e378-bff8d5bbb325@geldenhuys.co.uk> Message-ID: <201611070739.46130.mse00000@gmail.com> On Monday 07 November 2016 00:39:51 Graeme Geldenhuys via Lazarus wrote: > On 2016-11-06 15:45, zeljko via Lazarus wrote: > > No, I don't know any widgetset which supports different font color/style > > for texthint. > > fpGUI does - for some years now. ;-) I also implemented a specific > colour alias constant (clPlaceholderText) and alias font name, to make > it easier to customise in user-defined custom style classes. > Marketing is the most important task in software development, so here what MSEgui provides: http://mseide-msegui.sourceforge.net/pics/empty_text.png Martin From mailinglists at geldenhuys.co.uk Mon Nov 7 09:07:22 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 7 Nov 2016 08:07:22 +0000 Subject: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6 In-Reply-To: <201611070739.46130.mse00000@gmail.com> References: <52177465-f0dd-75e8-9b4d-f8c276e2a124@gmx.net> <45adb8fb-713b-cf94-298e-de771df7a233@holobit.net> <529cc3b5-f72b-ada2-e378-bff8d5bbb325@geldenhuys.co.uk> <201611070739.46130.mse00000@gmail.com> Message-ID: <3d1cd11d-10ea-39d4-4307-619787dd2d3b@geldenhuys.co.uk> On 2016-11-07 06:39, Martin Schreiber via Lazarus wrote: > Marketing is the most important task It was for the interest of education of course. ;-) Regards, Graeme From zeljko at holobit.net Mon Nov 7 09:10:20 2016 From: zeljko at holobit.net (zeljko) Date: Mon, 7 Nov 2016 09:10:20 +0100 Subject: [Lazarus] Exception in OnResize event handler In-Reply-To: <5188bd98-ac66-6102-f5f6-5523646a94c8@gmx.de> References: <77b9104a-b2ec-edfd-6d80-dd37fe533ed7@gmx.de> <244160755.119462.1478432734218@comcenter.netcologne.de> <850aec5b-001e-d833-304d-15e7576cb194@kluug.net> <33aea97d-9ad4-72f1-4b24-0332ae3ebb82@gmx.de> <5a65f0a5-b565-30b6-f2c6-a14cf0efbeee@kluug.net> <5188bd98-ac66-6102-f5f6-5523646a94c8@gmx.de> Message-ID: On 11/06/2016 07:08 PM, Jürgen Hestermann via Lazarus wrote: > Am 2016-11-06 um 16:39 schrieb Ondrej Pokorny via Lazarus: >>> The sentence >>> "Common mistake: Keep in mind that ClientWidth and ClientHeight can > change even when Width, Height stays the same" >>> makes me think that the event is not triggered when > *Client*Width/-Height changes >>> but only when Width/Height changes (why else would there be a "common > mistake"?) >>> but actually it is triggered in both cases. >> The sentence doesn't say anything about when OnResize is triggered so > it doesn't make me think anything about OnResize triggers. > > Then I don't know what the text is about at all. > It warns but does not say against what. It's against thinking that OnResize triggers only when width or/and height is changed. eg. let's assume that you have TCustomControl on form (with scrollbars), when theme is changed it is possible that vscrollbar width is changed from 20 to 22, so TCustomControl clientWidth is changed too since clientRect area is smaller now...OnResize() is triggered too. zeljko From nc-gaertnma at netcologne.de Mon Nov 7 09:52:08 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Mon, 7 Nov 2016 09:52:08 +0100 (CET) Subject: [Lazarus] Exception in OnResize event handler In-Reply-To: References: <77b9104a-b2ec-edfd-6d80-dd37fe533ed7@gmx.de> <244160755.119462.1478432734218@comcenter.netcologne.de> Message-ID: <1004613117.126760.1478508728757@comcenter.netcologne.de> > Jürgen Hestermann via Lazarus hat am 6. November 2016 um 13:03 geschrieben: >[...] > Then this seems to be unrelated to my problem. > It's not that the OnResize event is *not* triggered > but that it is triggered but then leads to the RaiseLoop exception. Yes. I guess so too. > BTW: > The wording of the help is misleading. > It says: > > "Common mistake: Keep in mind that ClientWidth and ClientHeight can change even when Width, Height stays the same" > > but it also says: > > "This event is triggered after the Width, Height, ClientWidth or ClientHeight of the control has changed" > > When OnResize is triggered even when ClientWidth or ClientHeight has changed then > the "Common mistake"-sentence makes no sense to me. Well, it is rare that ClientWidth changes without Width changing, so it is common that programmers forget about ClientWidth. That's why I had to add a note. Mattias > > -- > > _______________________________________________ > Lazarus mailing list > Lazarus at lists.lazarus-ide.org > http://lists.lazarus-ide.org/listinfo/lazarus From juergen.hestermann at gmx.de Mon Nov 7 16:45:06 2016 From: juergen.hestermann at gmx.de (=?UTF-8?Q?J=c3=bcrgen_Hestermann?=) Date: Mon, 7 Nov 2016 16:45:06 +0100 Subject: [Lazarus] Fwd: Re: Exception in OnResize event handler In-Reply-To: References: Message-ID: <1dc0c695-db4b-4640-abdb-0fa1230abd7f@gmx.de> I did a reply but then saw that this email was not sent via Lazarus mailing list but directly from zeljko to me. I therefore forward it again to the list. -------- Weitergeleitete Nachricht -------- Betreff: Re: [Lazarus] Exception in OnResize event handler Datum: Mon, 7 Nov 2016 16:07:24 +0100 Von: Jürgen Hestermann An: zeljko Am 2016-11-07 um 09:10 schrieb zeljko: >> Then I don't know what the text is about at all. >> It warns but does not say against what. > It's against thinking that OnResize triggers only when width or/and height is changed. But that's the first sentence: "This event is triggered after the Width, Height, ClientWidth or ClientHeight of the control has changed,..." So it's already all said in the first paragraph. Why repeat the same in convoluted and wrong wording? Reading the same in other words lets me think that there is something else to discover which I do just not get now. This text "Common mistake: Keep in mind that ClientWidth and ClientHeight can change even when Width, Height stays the same. For example when the theme changes, the Width and Height remain the same, but the changed frame reduces the ClientWidth and ClientHeight. This does not happen that often under Windows, but it happens quite often on other platforms. Especially it is not sufficient to write only a TForm.OnResize handler to resize all controls on the form. This is a common bug in Delphi applications. " should be reworded more clearly. It starts with "Common mistake:" but then does not tell about this mistake but only explains what has been said above already. So what is done wrongly often? And telling me that size changes of components within the Form are not triggered by OnResize of the Form is somewhat confusing (because it's a banality). Therefore I was under the impression that I had to do additional things because I only used OnResize of my Form. Especially, because the last sentence is wrong. Of course can it be sufficient to resize all controls on a form within a TForm.OnResize handler only. I can simply reduce (or expand) sizes of the components in relation to the ClientHeight/-Width change by portioning the remaining space. But reading the text made me insecure about such coding. If the facts should be repeated in more detail I would write the text above like this: "Keep in mind: ClientWidth and ClientHeight can change even when Width, Height stay the same. For example when the theme changes, the Width and Height remain the same, but the changed frame reduces ClientWidth and ClientHeight. This does not happen that often under Windows, but it happens quite often on other platforms." -------------- next part -------------- An HTML attachment was scrubbed... URL: From lazarus at kluug.net Mon Nov 7 16:51:16 2016 From: lazarus at kluug.net (Ondrej Pokorny) Date: Mon, 7 Nov 2016 16:51:16 +0100 Subject: [Lazarus] Fwd: Re: Exception in OnResize event handler In-Reply-To: <1dc0c695-db4b-4640-abdb-0fa1230abd7f@gmx.de> References: <1dc0c695-db4b-4640-abdb-0fa1230abd7f@gmx.de> Message-ID: <000300fc-571f-0a8d-1cd5-ee68dfafa7c0@kluug.net> Please send a patch through Mantis so that it can be reviewed and applied. It's useless to argue without a patch :) Ondrej From vfclists at gmail.com Mon Nov 7 20:25:08 2016 From: vfclists at gmail.com (vfclists .) Date: Mon, 7 Nov 2016 19:25:08 +0000 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: References: Message-ID: On 6 November 2016 at 23:20, Graeme Geldenhuys via Lazarus < lazarus at lists.lazarus-ide.org> wrote: > On 2016-10-21 09:58, Graeme Geldenhuys via Lazarus wrote: > > It was surprisingly hard to find a solution, especially something > > cross-platform. In the end I researched help formats with the goal to > > implement our own help viewer. We looked at Microsoft's HLP, CHM > > formats, IBM's INF, OpenOffice's help, Gnome's help sytem and a few > others. > > I thought I should elaborate on this process a bit, after reading > Frank's last message - in case somebody else gets the wrong impression. > The research wasn't a quick search on the Internet one afternoon. > Cross-Platform Help was very important to my employer. We spent 3 months > researching and evaluating help viewers and help formats. We did > extensive testing and looking at all aspects around help - from ease of > authoring help, efficiency of file formats, file sizes and help viewers. > > After all that, I think we came up with a very good choice, and a > solution that ticked all our requirements. My employer was also kind > enough to donate back all the work that was put into it, hoping others > would benefit from this. After all, they benefited hugely from all the > effort others put into Free Pascal and Lazarus. > > Regards, > Graeme > > -- > _______________________________________________ > Lazarus mailing list > Lazarus at lists.lazarus-ide.org > http://lists.lazarus-ide.org/listinfo/lazarus > I am not questioning the value of the INF format, DocView and other associated utilities. I am just trying to say that this is the current state of affairs today, and for the last 20 years as well, where the computing industry has been try to shoehorn every da*n thing into Javascript and HTML, and who knows what the industry "leaders" will come up in their bid to fit square pegs into round holes and channel users into their increasingly restricted systems? I mean the latest thing now is WebAssembly which shows how ridiculous the whole business has become. It is not a fault on Lars end that he sees CEF as the best way to provide help. It is just the way things are. Computing environments have gone full retard in service of the browser and the web. BTW, is there an INF to HTML convertor that would enable documentation to be developed in INF then translated to HTML for those who want dumbed down display systems? -- Frank Church ======================= http://devblog.brahmancreations.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at geldenhuys.co.uk Mon Nov 7 21:41:38 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 7 Nov 2016 20:41:38 +0000 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: References: Message-ID: <419f1709-5a84-8f36-87a4-ab09c5dc3d38@geldenhuys.co.uk> On 2016-11-07 19:25, vfclists . via Lazarus wrote: > computing industry has been try to shoehorn every da*n thing into > Javascript and HTML, and who knows what the industry "leaders" will come up > in their bid to fit square pegs into round holes and channel users into Exactly, and there is no reason to follow those idiots - I know I don't. INF (by IBM) and HLP (by Microsoft) was designed from the ground up as help file formats. The are very good at what they do. Having studied both in depth, I think IBM did a much better job, and has more features than HLP had. The only mistake IBM made was that the developed a crappy INF viewer. That's were DocView fills the gap - much more modern and user friendly INF viewer. > BTW, is there an INF to HTML convertor that would enable documentation to > be developed in INF then translated to HTML for those who want dumbed down > display systems? That totally defeats the point of a descent and useful help viewer. Saying that, I have implemented an export option for DocView where you can export selected help topics to plain text. I'm also busy writing a new exporter using the new fcl-pdf package, so DocView can export selected topics to PDF. The idea of this export functionality is to easily print or collate information (help topics) of interest in one condensed file. I don't really use this too much these days, as DocView also supports Bookmarks, which is simply faster. Creating a exporter for HTML shouldn't be hard either, but I think the PDF format will be much more useful, and like INF, everything (text and images) are contained in a single file. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From noreply at z505.com Tue Nov 8 03:27:44 2016 From: noreply at z505.com (Lars) Date: Mon, 7 Nov 2016 19:27:44 -0700 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: References: <20161021111331.0846d181@limapholos.matflo.wg> <0690e875-8608-c93d-ce39-f86e7a0bf5e3@geldenhuys.co.uk> <20161021120507.33bf5fdd@limapholos.matflo.wg> <20161022233647.63d1d853@limapholos.matflo.wg> <0ccf92ea-c2ce-8c1d-cec1-bf0777619b41@geldenhuys.co.uk> <720ab092ae799b63946c94c8842c0b6e.squirrel@gator3286.hostgator.com> Message-ID: <4559996ba5f36670c92b31e8b7aebb16.squirrel@gator3286.hostgator.com> On Sun, November 6, 2016 4:35 am, vfclists . via Lazarus wrote: > On 24 October 2016 at 00:34, Lars via Lazarus > >> wrote: >> > >> Now that I think about my post about using chromium embedded for a help >> engine, the issue I see is that it's a large dependency .. so for >> small applications that are say 1MB large, and you want to supply a help >> system with it... all of a sudden the 1mb exe has to be shipped with a >> gazillion other files that wouldn't be needed with a more simple format. >> >> >> Still, I think I will try to release a help system for powtils using >> chromium embedded, as an offline experiment with CGI (no web server >> needed). However this will take time, and I almost feel like I posted >> that chromium idea drunk, even though I was not drinking. >> >> On Sat, October 22, 2016 5:24 pm, Graeme Geldenhuys via Lazarus wrote: >> >>> On 2016-10-22 22:36, Mattias Gaertner via Lazarus wrote: >>> >>> >>>> Is this a problem of the CHM producer or the CHM viewer? >>>> >>>> >>> >>> Both. The LaTeX-to-HTML conversion is definitely not great. Michael >>> would agree on this one. Then taking that already bad HTML and >>> converting in to CHM, makes the end result even worse. That doesn't do >>> any justices for Michael's hard work in writing the documentation and >>> having it beautifully presented (like the official PDF versions). >> .... >> -- >> _______________________________________________ >> Lazarus mailing list >> Lazarus at lists.lazarus-ide.org >> http://lists.lazarus-ide.org/listinfo/lazarus >> >> > > > I think using CEF is fine as there don't seem to be any other realistic > options. That is the situation as it is. Something which is likely to get > more support is "more better" than a perfect but little used and little > known system. A Lazarus installation currently takes over 1 Gb, so what > difference does another 300Mb make to it when it is something as critical > as help? I was speaking of a help system for any application, not just lazarus alone... i.e. you build a 2mb exe and ship it to your customer (not lazarus.exe but another exe built with lazarus)... So now your elf/exe has to include a huge dependency... Chromium is not just one dll. It would be ideal if it was only one dll, like mysqlite. So if you build a 2-6mb app, now you have to ship yet more files increasing the size further. Maybe not a huge issue with todays high speed internet connections, but it still is another dependency. From noreply at z505.com Tue Nov 8 03:31:53 2016 From: noreply at z505.com (Lars) Date: Mon, 7 Nov 2016 19:31:53 -0700 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: References: <20161021111331.0846d181@limapholos.matflo.wg> <0690e875-8608-c93d-ce39-f86e7a0bf5e3@geldenhuys.co.uk> <20161021120507.33bf5fdd@limapholos.matflo.wg> <20161022233647.63d1d853@limapholos.matflo.wg> <0ccf92ea-c2ce-8c1d-cec1-bf0777619b41@geldenhuys.co.uk> <720ab092ae799b63946c94c8842c0b6e.squirrel@gator3286.hostgator.com> Message-ID: On Sun, November 6, 2016 4:35 am, vfclists . via Lazarus wrote: > Something which is likely to get > more support is "more better" than a perfect but little used and little > known system. One issue is firefox has a track record of not supporting embedded browser for very long without abandoning it, or changing the api to make it incompatible with old code... so who says this isn't also going to happen with chromium (CEF) at some point... Hopefully chromium will not go down the same path as firefox embedded. I do know, that CEF1 has some features that are incompatible with CEF3 so they've already broken some things... hopefully cef3 stays stable api for a long time and there is no cef4 that comes out which breaks old cef3 code. From noreply at z505.com Tue Nov 8 03:33:53 2016 From: noreply at z505.com (Lars) Date: Mon, 7 Nov 2016 19:33:53 -0700 Subject: [Lazarus] ctrl-c code completion In-Reply-To: References: Message-ID: <3e44e6b17be7250d1de84c73cf1ad8ac.squirrel@gator3286.hostgator.com> On Sun, November 6, 2016 10:05 am, Michael Van Canneyt via Lazarus wrote: > > press ctrl-c to do command-completion If ctrl - c is for copying, how does this not interfere? i.e. ctrl c is for copy and paste, so... how is ctrl-c used for command completion without interfering with clipboard? From noreply at z505.com Tue Nov 8 03:39:33 2016 From: noreply at z505.com (Lars) Date: Mon, 7 Nov 2016 19:39:33 -0700 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: References: <20161021111331.0846d181@limapholos.matflo.wg> <0690e875-8608-c93d-ce39-f86e7a0bf5e3@geldenhuys.co.uk> <20161021120507.33bf5fdd@limapholos.matflo.wg> <20161022233647.63d1d853@limapholos.matflo.wg> <0ccf92ea-c2ce-8c1d-cec1-bf0777619b41@geldenhuys.co.uk> <720ab092ae799b63946c94c8842c0b6e.squirrel@gator3286.hostgator.com> Message-ID: On Sun, November 6, 2016 1:18 pm, Graeme Geldenhuys via Lazarus wrote: > If anybody things installing 300MB just to get some lousy help for a > small 1MB application is acceptable, Maybe CEF needs a lite version. I am guessing that chromium embedded pulls in a lot of unused code that is not needed for most cef embededded browser apps. Would be nice if there was a CEF (chromium embedded) lite which was only, maybe 10MB. Obviously, I'd prefer a 100KB option over even a 10MB option.... 300MB seems awfully like bloatware to me.. is it really 300MB to ship the latest CEF 3? I haven't checked. Even if it was 110MB that's still too large. From noreply at z505.com Tue Nov 8 03:51:06 2016 From: noreply at z505.com (Lars) Date: Mon, 7 Nov 2016 19:51:06 -0700 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: References: Message-ID: <6ae6beeae72d5bd668dbea960664f0d1.squirrel@gator3286.hostgator.com> On Mon, November 7, 2016 12:25 pm, vfclists . via Lazarus wrote: > I mean the latest thing now is > WebAssembly which shows how ridiculous the whole business has become. Web assembly, if designed properly, might actually get rid of some problems. Javascript is a large mammoth, or ugly beast. Web assembly may allow one to for example compile freepascal code directly to byte code that runs in the browser, instead of people using ugly obfuscated bloated javascript "hacks". It's sort of like a JVM bytecode, but for the web browser. Or a .net bytecode. I don't fully know what web assembly intends to be, as it's not completed yet fully, but, it may actually get rid of some of the javascript bloated crap out there. Lots of people may in fact ignore webassembly and continue to use javascript. God forbid. > It > is not a fault on Lars end that he sees CEF as the best way to provide > help. It is just the way things are. Not necessarily the best, because of the large dependency.. If CEF (chromium embedded) offered a lite version that was only 2MB to ship with an exe, or 500KB then it may in fact be a good solution for help.. From mailinglists at geldenhuys.co.uk Tue Nov 8 11:09:41 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Tue, 8 Nov 2016 10:09:41 +0000 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: <4559996ba5f36670c92b31e8b7aebb16.squirrel@gator3286.hostgator.com> References: <20161021111331.0846d181@limapholos.matflo.wg> <0690e875-8608-c93d-ce39-f86e7a0bf5e3@geldenhuys.co.uk> <20161021120507.33bf5fdd@limapholos.matflo.wg> <20161022233647.63d1d853@limapholos.matflo.wg> <0ccf92ea-c2ce-8c1d-cec1-bf0777619b41@geldenhuys.co.uk> <720ab092ae799b63946c94c8842c0b6e.squirrel@gator3286.hostgator.com> <4559996ba5f36670c92b31e8b7aebb16.squirrel@gator3286.hostgator.com> Message-ID: On 2016-11-08 02:27, Lars via Lazarus wrote: > Maybe not a huge issue with todays high speed internet connections, but it > still is another dependency. Not all internet connections are equal in all countries. In the UK, 8Mbps is currently the average speed. In South Africa the average speed would be 256-512Kbps (yes, that's with a K). The highest "reliable" speed (take that with a huge pinch of salt - as you never get close to that speed in reality) in South Africa is 4Mbps. A stark contrast to the UK's affordable and reliable 75-200Mbps. And apparently the UK is lagging behind other countries too. So an additional 10MB download can make a huge difference, depending where in the world you live. Adding a 100-300MB for each application download is simply absurd. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From bartjunk64 at gmail.com Tue Nov 8 11:13:30 2016 From: bartjunk64 at gmail.com (Bart) Date: Tue, 8 Nov 2016 11:13:30 +0100 Subject: [Lazarus] ctrl-c code completion In-Reply-To: <3e44e6b17be7250d1de84c73cf1ad8ac.squirrel@gator3286.hostgator.com> References: <3e44e6b17be7250d1de84c73cf1ad8ac.squirrel@gator3286.hostgator.com> Message-ID: On 11/8/16, Lars via Lazarus wrote: > On Sun, November 6, 2016 10:05 am, Michael Van Canneyt via Lazarus wrote: >> >> press ctrl-c to do command-completion > > If ctrl - c is for copying, how does this not interfere? It is Shift+Ctrl+C by default. Bart From mailinglists at geldenhuys.co.uk Tue Nov 8 11:13:31 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Tue, 8 Nov 2016 10:13:31 +0000 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: References: <20161021111331.0846d181@limapholos.matflo.wg> <0690e875-8608-c93d-ce39-f86e7a0bf5e3@geldenhuys.co.uk> <20161021120507.33bf5fdd@limapholos.matflo.wg> <20161022233647.63d1d853@limapholos.matflo.wg> <0ccf92ea-c2ce-8c1d-cec1-bf0777619b41@geldenhuys.co.uk> <720ab092ae799b63946c94c8842c0b6e.squirrel@gator3286.hostgator.com> Message-ID: On 2016-11-08 02:31, Lars via Lazarus wrote: > One issue is firefox has a track record of not supporting embedded browser > for very long without abandoning it, or changing the api to make it > incompatible with old code... so who says this isn't also going to happen > with chromium (CEF) at some point... My point is, for a help system you really don't need the latest and greatest HTML5 features. It's simply not needed. What you do want in well formatted text, images and some basic rich text styles. Good help is more about the contents and the speed of getting to that contents, that about the presentation. But some people are more obsessed about presentation with rubbish or near zero content. Regards, Graeme From mailinglists at geldenhuys.co.uk Tue Nov 8 11:19:06 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Tue, 8 Nov 2016 10:19:06 +0000 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: <6ae6beeae72d5bd668dbea960664f0d1.squirrel@gator3286.hostgator.com> References: <6ae6beeae72d5bd668dbea960664f0d1.squirrel@gator3286.hostgator.com> Message-ID: <635fca1f-c3a8-5f43-6765-0897df679929@geldenhuys.co.uk> On 2016-11-08 02:51, Lars via Lazarus wrote: > It's sort of like a JVM bytecode, but for the web browser. That makes you wonder, why not simply go back to Java Applets. They came out in 1996 and I thought they were brilliant for web applications. You had the full power of the Java language and graphics stack at your disposal. Yes there was phase when Java had some security issues, but those were resolved, and any future security issues could be resolved just as easily. I simply don't understand why they must always try and reinvent the wheel, when they could simply fix or improve the wheel. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From marcov at stack.nl Tue Nov 8 11:34:15 2016 From: marcov at stack.nl (Marco van de Voort) Date: Tue, 8 Nov 2016 11:34:15 +0100 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: References: <20161021111331.0846d181@limapholos.matflo.wg> <0690e875-8608-c93d-ce39-f86e7a0bf5e3@geldenhuys.co.uk> <20161021120507.33bf5fdd@limapholos.matflo.wg> Message-ID: <20161108103415.GA43448@stack.nl> On Fri, Oct 21, 2016 at 12:13:32PM +0100, Graeme Geldenhuys via Lazarus wrote: > Regarding the FPC guides. I consider the FPC Language Reference the most > important one, so I manually converted it (and keep it in sync with FPC > releases when I can), and also added my own additions to take advantage > of the INF format. See attached screenshot. > > As for the others guides, I wrote a tool that does LaTex to IPF > conversions (that was hard). I also did a HTML to IPF tool. But in both > cases some elements are not yet converted, and generally the formatting > is not nearly as good as it should be (my standards are high when it > comes to help formatting). So I don't publicise what I don't think is of > high enough quality yet. If you can store a reasonably abstract inbetween format that would be good. > Take the Free Pascal CHM help as an example - it is horrific looking. > The fpdoc's HTML output writer was clearly designed for online HTML > usage with popup browser windows and decent CSS support etc. The HTML output writer is parameterizable. IOW there is html output and chm output. The original CHM output was designed for the Windows help viewer though, not Lhelp. It works fine in the IDE though. > The CHM > conversion of that gives broken links, unsupported features and bad > formatting. This is incorrect for fpdoc output, as it is not the html data that is being converted. So I'm going to need examples here. From michael at freepascal.org Tue Nov 8 11:42:10 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Tue, 8 Nov 2016 11:42:10 +0100 (CET) Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: <6ae6beeae72d5bd668dbea960664f0d1.squirrel@gator3286.hostgator.com> References: <6ae6beeae72d5bd668dbea960664f0d1.squirrel@gator3286.hostgator.com> Message-ID: On Mon, 7 Nov 2016, Lars via Lazarus wrote: > On Mon, November 7, 2016 12:25 pm, vfclists . via Lazarus wrote: >> I mean the latest thing now is >> WebAssembly which shows how ridiculous the whole business has become. > > > Web assembly, if designed properly, might actually get rid of some > problems. Javascript is a large mammoth, or ugly beast. Web assembly may > allow one to for example compile freepascal code directly to byte code > that runs in the browser, instead of people using ugly obfuscated bloated > javascript "hacks". > > It's sort of like a JVM bytecode, but for the web browser. Or a .net > bytecode. I don't fully know what web assembly intends to be, as it's not > completed yet fully, but, it may actually get rid of some of the > javascript bloated crap out there. I seriously doubt that. It's just something that will exist next to javascript but in essence will perform the same tasks as javascript. You can create relatively clean and structured javascript if you want. It just requires discipline as the language doesn't enforce it. The problem is IMHO not so much the language, but what you do with it. > > Lots of people may in fact ignore webassembly and continue to use > javascript. God forbid. Well, there is interest in a WebAssembly backend for FPC. Someone is looking at it. Just as we are working on a transpiler from Pascal to Javascript. Michael. From mschnell at lumino.de Tue Nov 8 11:49:20 2016 From: mschnell at lumino.de (Michael Schnell) Date: Tue, 8 Nov 2016 11:49:20 +0100 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: References: <6ae6beeae72d5bd668dbea960664f0d1.squirrel@gator3286.hostgator.com> Message-ID: <015cb9e9-3360-41bf-711d-aeba01152b3a@lumino.de> On 08.11.2016 11:42, Michael Van Canneyt via Lazarus wrote: > > I seriously doubt that. It's just something that will exist next to > javascript but in essence will perform the same tasks as javascript. ==OFF TOPIC== (so ignore if there is not a very short answer) Any plans for a webassembly support with FPC ? -Michael From nc-gaertnma at netcologne.de Tue Nov 8 12:07:32 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Tue, 8 Nov 2016 12:07:32 +0100 Subject: [Lazarus] CCR, how to send files? In-Reply-To: <6803f7b7-8456-72b9-a0da-ceb0d29c2f93@ya.ru> References: <362eee4c-2fc2-d194-3735-4b8ed12111bc@lumino.de> <6803f7b7-8456-72b9-a0da-ceb0d29c2f93@ya.ru> Message-ID: <20161108120732.7df50c00@limapholos.matflo.wg> On Fri, 28 Oct 2016 11:58:31 +0300 Alexey via Lazarus wrote: > Hi > I try to send mail to Vincent S, he is unreachable, mail cannot send. > How to send my files to CCR? Has Vincent answered in the meantime? Mattias From nc-gaertnma at netcologne.de Tue Nov 8 12:45:39 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Tue, 8 Nov 2016 12:45:39 +0100 Subject: [Lazarus] Lazarus Version In-Reply-To: References: <1478427260700-4050205.post@n3.nabble.com> <511638044.118941.1478428534352@comcenter.netcologne.de> Message-ID: <20161108124539.1d9d56c5@limapholos.matflo.wg> On Sun, 6 Nov 2016 11:59:44 +0100 (CET) Michael Van Canneyt via Lazarus wrote: >[...] > It would be good to have an option in the package system to write and/or > register the package version somewhere, so it is accessible at runtime, and > an application can query the various packages and their versions. AFAIK most users asked for the version at compile time. So it must be either a define or some consts in an unit like lclversion does. The defines would create many ugly FPC parameters, fpmake can't create them. The 'version unit' is compatible with all build systems and works at runtime too. It is not supported by codetools yet though. Maybe the IDE can automatically update/create such version units. Mattias From mschnell at lumino.de Tue Nov 8 12:59:06 2016 From: mschnell at lumino.de (Michael Schnell) Date: Tue, 8 Nov 2016 12:59:06 +0100 Subject: [Lazarus] TThread.Synchronize In-Reply-To: <3033bf13-9fd5-4851-ae11-a31d69582e8f@zoznam.sk> References: <85611d18-b4da-8a65-c875-bccdcc5d1025@lumino.de> <3033bf13-9fd5-4851-ae11-a31d69582e8f@zoznam.sk> Message-ID: <01599e31-8145-5bc4-c37c-3188a6c49c95@lumino.de> On 25.10.2016 14:07, LacaK via Lazarus wrote: > > Yes this can happen. > MyForm.MyMethod is called also from event handler and also is used in > Synchronize(@MyForm.MyMethod) > How can this happen/play role? I suppose by "event handler" you mean a GUI event (Mouse, Keyboard, ...) Such events are serviced by the Queue as well and hence run in the same Thread ("MainThread" as the synchronized methods. So there can't be a mutual interrupt. The whole point with the Event programming paradigm is to do "run to completion" events. -Michael From michael at freepascal.org Tue Nov 8 13:01:20 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Tue, 8 Nov 2016 13:01:20 +0100 (CET) Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: <015cb9e9-3360-41bf-711d-aeba01152b3a@lumino.de> References: <6ae6beeae72d5bd668dbea960664f0d1.squirrel@gator3286.hostgator.com> <015cb9e9-3360-41bf-711d-aeba01152b3a@lumino.de> Message-ID: On Tue, 8 Nov 2016, Michael Schnell via Lazarus wrote: > On 08.11.2016 11:42, Michael Van Canneyt via Lazarus wrote: >> >> I seriously doubt that. It's just something that will exist next to >> javascript but in essence will perform the same tasks as javascript. > ==OFF TOPIC== (so ignore if there is not a very short answer) > > Any plans for a webassembly support with FPC ? I wrote it in the email you are replying to. Please re-read. Michael. From nc-gaertnma at netcologne.de Tue Nov 8 12:59:55 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Tue, 8 Nov 2016 12:59:55 +0100 Subject: [Lazarus] ctrl-c code completion In-Reply-To: References: Message-ID: <20161108125955.3713e5fc@limapholos.matflo.wg> On Sun, 6 Nov 2016 18:05:39 +0100 (CET) Michael Van Canneyt via Lazarus wrote: >[...] > - Function to function, > > - Procedure to procedure > > - and the setter in > > property Values[const Name: string]: string read GetValue write SetValue; > > is changed from > > procedure SetValue(const Name, Value: string); > > to > > procedure SetValue(const Name : string; Const Value: string); > > Causing the compiler to generate an error... Why does that cause a compiler error? Mattias From michael at freepascal.org Tue Nov 8 13:08:41 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Tue, 8 Nov 2016 13:08:41 +0100 (CET) Subject: [Lazarus] Lazarus Version In-Reply-To: <20161108124539.1d9d56c5@limapholos.matflo.wg> References: <1478427260700-4050205.post@n3.nabble.com> <511638044.118941.1478428534352@comcenter.netcologne.de> <20161108124539.1d9d56c5@limapholos.matflo.wg> Message-ID: On Tue, 8 Nov 2016, Mattias Gaertner via Lazarus wrote: > On Sun, 6 Nov 2016 11:59:44 +0100 (CET) > Michael Van Canneyt via Lazarus wrote: > >> [...] >> It would be good to have an option in the package system to write and/or >> register the package version somewhere, so it is accessible at runtime, and >> an application can query the various packages and their versions. > > AFAIK most users asked for the version at compile time. So it must be > either a define or some consts in an unit like lclversion does. > The defines would create many ugly FPC parameters, fpmake can't > create them. > The 'version unit' is compatible with all build systems and works at > runtime too. It is not supported by codetools yet though. Maybe the IDE > can automatically update/create such version units. I'm not sure we're talking about the same thing. I don't know what 'version unit' you mean ? I have software which consists of many different packages which we control, from different SVN repos. In order to correctly identify the version of each package on a production system, I need somewhere a registry of versions of all used packages. For each package I now create an include file with a version string which is written to a central registry. At runtime I query the registry and display for all used packages the version number. As far as I know, the version number of a lazarus packages lives outside the sources, it resides just in the LPK. I now use some XML routines to extract this version number from the .lpk and write it in the abovementioned include file. This happens in our build system. I don't necessarily expect lazarus to provide such a central registry, but to be able to have a version unit for each package would be nice, so I no longer need to do the XML trickery or adapt the build system manually... But please, this is a nice to have, it was just a thought after seeing the lclversion tip. Michael. From michael at freepascal.org Tue Nov 8 13:08:41 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Tue, 8 Nov 2016 13:08:41 +0100 (CET) Subject: [Lazarus] Lazarus Version In-Reply-To: <20161108124539.1d9d56c5@limapholos.matflo.wg> References: <1478427260700-4050205.post@n3.nabble.com> <511638044.118941.1478428534352@comcenter.netcologne.de> <20161108124539.1d9d56c5@limapholos.matflo.wg> Message-ID: On Tue, 8 Nov 2016, Mattias Gaertner via Lazarus wrote: > On Sun, 6 Nov 2016 11:59:44 +0100 (CET) > Michael Van Canneyt via Lazarus wrote: > >> [...] >> It would be good to have an option in the package system to write and/or >> register the package version somewhere, so it is accessible at runtime, and >> an application can query the various packages and their versions. > > AFAIK most users asked for the version at compile time. So it must be > either a define or some consts in an unit like lclversion does. > The defines would create many ugly FPC parameters, fpmake can't > create them. > The 'version unit' is compatible with all build systems and works at > runtime too. It is not supported by codetools yet though. Maybe the IDE > can automatically update/create such version units. I'm not sure we're talking about the same thing. I don't know what 'version unit' you mean ? I have software which consists of many different packages which we control, from different SVN repos. In order to correctly identify the version of each package on a production system, I need somewhere a registry of versions of all used packages. For each package I now create an include file with a version string which is written to a central registry. At runtime I query the registry and display for all used packages the version number. As far as I know, the version number of a lazarus packages lives outside the sources, it resides just in the LPK. I now use some XML routines to extract this version number from the .lpk and write it in the abovementioned include file. This happens in our build system. I don't necessarily expect lazarus to provide such a central registry, but to be able to have a version unit for each package would be nice, so I no longer need to do the XML trickery or adapt the build system manually... But please, this is a nice to have, it was just a thought after seeing the lclversion tip. Michael. From michael at freepascal.org Tue Nov 8 13:10:40 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Tue, 8 Nov 2016 13:10:40 +0100 (CET) Subject: [Lazarus] ctrl-c code completion In-Reply-To: <20161108125955.3713e5fc@limapholos.matflo.wg> References: <20161108125955.3713e5fc@limapholos.matflo.wg> Message-ID: On Tue, 8 Nov 2016, Mattias Gaertner via Lazarus wrote: > On Sun, 6 Nov 2016 18:05:39 +0100 (CET) > Michael Van Canneyt via Lazarus wrote: > >> [...] >> - Function to function, >> >> - Procedure to procedure >> >> - and the setter in >> >> property Values[const Name: string]: string read GetValue write SetValue; >> >> is changed from >> >> procedure SetValue(const Name, Value: string); >> >> to >> >> procedure SetValue(const Name : string; Const Value: string); >> >> Causing the compiler to generate an error... > > Why does that cause a compiler error? Because both procedures remained in the sources. Open classes unit, press code completion shortcut while in TStrings (or was it TStringlist?), and observe the effect... I noticed this while fixing a bug report. Michael. From mailinglists at geldenhuys.co.uk Tue Nov 8 14:00:44 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Tue, 8 Nov 2016 13:00:44 +0000 Subject: [Lazarus] ctrl-c code completion In-Reply-To: References: <20161108125955.3713e5fc@limapholos.matflo.wg> Message-ID: <392fadae-97ef-5444-4005-085f3c984445@geldenhuys.co.uk> On 2016-11-08 12:10, Michael Van Canneyt via Lazarus wrote: >> > >> > Why does that cause a compiler error? > Because both procedures remained in the sources. I can confirm, I've seen this quite a few times recently too. Not sure if this is related: Another way to reproduce this is to change the parameters of two overloaded methods and then do Ctrl+Shift+C to class complete (update their implementation signatures). Instead of updating the existing methods, it defines new ones. Regards, Graeme From nc-gaertnma at netcologne.de Tue Nov 8 14:05:08 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Tue, 8 Nov 2016 14:05:08 +0100 Subject: [Lazarus] Lazarus Version In-Reply-To: References: <1478427260700-4050205.post@n3.nabble.com> <511638044.118941.1478428534352@comcenter.netcologne.de> <20161108124539.1d9d56c5@limapholos.matflo.wg> Message-ID: <20161108140508.6fbbae53@limapholos.matflo.wg> On Tue, 8 Nov 2016 13:08:41 +0100 (CET) Michael Van Canneyt wrote: >[...] > I'm not sure we're talking about the same thing. I don't know what 'version > unit' you mean ? For example lazarus/lcl/lclversion.pas >[...] > As far as I know, the version number of a lazarus packages lives outside the > sources, it resides just in the LPK. Yes. > I now use some XML routines to extract > this version number from the .lpk and write it in the abovementioned include > file. This happens in our build system. The IDE could write the version to some file (or update an existing file). What would be a good place? For example when package A needs to know the version of a required package B the version must be stored either in a unit of A or B. Storing it in B avoids redundancy, but when B is read only it needs to be stored in A. Mattias From nc-gaertnma at netcologne.de Tue Nov 8 14:05:47 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Tue, 8 Nov 2016 14:05:47 +0100 Subject: [Lazarus] ctrl-c code completion In-Reply-To: References: <20161108125955.3713e5fc@limapholos.matflo.wg> Message-ID: <20161108140547.22fa1805@limapholos.matflo.wg> On Tue, 8 Nov 2016 13:10:40 +0100 (CET) Michael Van Canneyt via Lazarus wrote: > On Tue, 8 Nov 2016, Mattias Gaertner via Lazarus wrote: > > > On Sun, 6 Nov 2016 18:05:39 +0100 (CET) > > Michael Van Canneyt via Lazarus wrote: > > > >> [...] > >> - Function to function, > >> > >> - Procedure to procedure > >> > >> - and the setter in > >> > >> property Values[const Name: string]: string read GetValue write SetValue; > >> > >> is changed from > >> > >> procedure SetValue(const Name, Value: string); > >> > >> to > >> > >> procedure SetValue(const Name : string; Const Value: string); > >> > >> Causing the compiler to generate an error... > > > > Why does that cause a compiler error? > > Because both procedures remained in the sources. > > Open classes unit, press code completion shortcut while in TStrings (or was > it TStringlist?), and observe the effect... I noticed this while fixing a bug report. Please create a bug report. Mattias From nc-gaertnma at netcologne.de Tue Nov 8 14:14:24 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Tue, 8 Nov 2016 14:14:24 +0100 Subject: [Lazarus] ctrl-c code completion In-Reply-To: <392fadae-97ef-5444-4005-085f3c984445@geldenhuys.co.uk> References: <20161108125955.3713e5fc@limapholos.matflo.wg> <392fadae-97ef-5444-4005-085f3c984445@geldenhuys.co.uk> Message-ID: <20161108141424.2ea0ea2a@limapholos.matflo.wg> On Tue, 8 Nov 2016 13:00:44 +0000 Graeme Geldenhuys via Lazarus wrote: >[...] > I can confirm, I've seen this quite a few times recently too. > > Not sure if this is related: > Another way to reproduce this is to change the parameters of two > overloaded methods and then do Ctrl+Shift+C to class complete (update > their implementation signatures). Instead of updating the existing > methods, it defines new ones. In this case codetools don't have enough information. Because it does not know the former connection. It only sees two declarations without bodies and two bodies without declarations. It can't know for sure which belong together. The non-interactive-code-completion should stop with an error. The interactive can ask. Please create a report. Mattias From mailinglists at geldenhuys.co.uk Tue Nov 8 14:49:16 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Tue, 8 Nov 2016 13:49:16 +0000 Subject: [Lazarus] ctrl-c code completion In-Reply-To: <20161108141424.2ea0ea2a@limapholos.matflo.wg> References: <20161108125955.3713e5fc@limapholos.matflo.wg> <392fadae-97ef-5444-4005-085f3c984445@geldenhuys.co.uk> <20161108141424.2ea0ea2a@limapholos.matflo.wg> Message-ID: <290d5579-2af4-c0b5-a322-1ccf04cf1161@geldenhuys.co.uk> On 2016-11-08 13:14, Mattias Gaertner via Lazarus wrote: > In this case codetools don't have enough information. Because it does > not know the former connection. By why does it work if I do them one at a time. eg: Change the first interface declaration and do code completion. Change the second interface declaration and do code completion. That works. But doing them at the same time it doesn't. So in the first case, CodeTools somehow knows the connection, even though the interface and implementation declarations don't match (until code completion is invoked). It then magically knows which implementation declaration to update. So why would CodeTools not know the connection when both interface declarations are updated at the same time? I don't know how CodeTools works, but I would imagine it has some memory lookup (line numbers) where interface declaration xyz has an implementation at line 123. So when the declaration xyz changes (by the developer), go to line 123 and change it there too? Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From lazarus at kluug.net Tue Nov 8 14:52:27 2016 From: lazarus at kluug.net (Ondrej Pokorny) Date: Tue, 8 Nov 2016 14:52:27 +0100 Subject: [Lazarus] ctrl-c code completion In-Reply-To: <290d5579-2af4-c0b5-a322-1ccf04cf1161@geldenhuys.co.uk> References: <20161108125955.3713e5fc@limapholos.matflo.wg> <392fadae-97ef-5444-4005-085f3c984445@geldenhuys.co.uk> <20161108141424.2ea0ea2a@limapholos.matflo.wg> <290d5579-2af4-c0b5-a322-1ccf04cf1161@geldenhuys.co.uk> Message-ID: On 08.11.2016 14:49, Graeme Geldenhuys via Lazarus wrote: > On 2016-11-08 13:14, Mattias Gaertner via Lazarus wrote: >> In this case codetools don't have enough information. Because it does >> not know the former connection. > By why does it work if I do them one at a time. eg: Change the first > interface declaration and do code completion. Change the second > interface declaration and do code completion. That works. > > But doing them at the same time it doesn't. > > So in the first case, CodeTools somehow knows the connection, even > though the interface and implementation declarations don't match (until > code completion is invoked). It then magically knows which > implementation declaration to update. No magic at all. If the incompatibility ratio of interface methods : implementation methods is 1:1 then the connection is more than obvious. It doesn't work only with overloads. You can rename the method and it works as well. Just do changes one by one and you are good to go. Ondrej From juergen.hestermann at gmx.de Tue Nov 8 14:59:45 2016 From: juergen.hestermann at gmx.de (=?UTF-8?Q?J=c3=bcrgen_Hestermann?=) Date: Tue, 8 Nov 2016 14:59:45 +0100 Subject: [Lazarus] Anchoring fails on Windows 10 Message-ID: I have a simple form with 2 components, a TVirtualDrawTree and a TProgressBar. The TProgressBar is anchored to the bottom of the form and the bottom of the TVirtualDrawTree is anchored to the top of the TProgressBar. This works okay on Windows 7 and 8.1 but not on Windows 10! When I resize the form by moving down the bottom border or by making it full size then the position of the TProgressBar within the form stays where it was and is not moved to the bottom of the form. Anybody else having such issues on Windows 10? From nc-gaertnma at netcologne.de Tue Nov 8 15:45:54 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Tue, 8 Nov 2016 15:45:54 +0100 Subject: [Lazarus] ctrl-c code completion In-Reply-To: <290d5579-2af4-c0b5-a322-1ccf04cf1161@geldenhuys.co.uk> References: <20161108125955.3713e5fc@limapholos.matflo.wg> <392fadae-97ef-5444-4005-085f3c984445@geldenhuys.co.uk> <20161108141424.2ea0ea2a@limapholos.matflo.wg> <290d5579-2af4-c0b5-a322-1ccf04cf1161@geldenhuys.co.uk> Message-ID: <20161108154554.3b14aeb1@limapholos.matflo.wg> On Tue, 8 Nov 2016 13:49:16 +0000 Graeme Geldenhuys via Lazarus wrote: > On 2016-11-08 13:14, Mattias Gaertner via Lazarus wrote: > > In this case codetools don't have enough information. Because it does > > not know the former connection. > > By why does it work if I do them one at a time. eg: Change the first > interface declaration and do code completion. Change the second > interface declaration and do code completion. That works. Because this case is unambiguous. There is only one possible mapping. > But doing them at the same time it doesn't. Yes, with two you have two possible mappings. Three has six and so forth. Basic math: n! So, as Ondrej wrote: Just do changes one by one and you are good to go. >[...] > So why would CodeTools not know the connection when both interface > declarations are updated at the same time? I don't know how CodeTools > works, but I would imagine it has some memory lookup (line numbers) > where interface declaration xyz has an implementation at line 123. So > when the declaration xyz changes (by the developer), go to line 123 and > change it there too? Codetools only sees the sources when the IDE invokes it (e.g. code completion). It has no idea what happens since last time in the IDE and it does not store old states, so it can't compare versions. Theoretically something similar to synedits Syncro-Edit could be implemented for procedure declaration/implementation. Or even better: something similar to rename-identifier, but for procedures: rename, remove parameter, move parameter, insert parameter, and all references are updated too. I started that, but it needs much work. Mattias From mailinglists at geldenhuys.co.uk Tue Nov 8 15:50:10 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Tue, 8 Nov 2016 14:50:10 +0000 Subject: [Lazarus] ctrl-c code completion In-Reply-To: <20161108154554.3b14aeb1@limapholos.matflo.wg> References: <20161108125955.3713e5fc@limapholos.matflo.wg> <392fadae-97ef-5444-4005-085f3c984445@geldenhuys.co.uk> <20161108141424.2ea0ea2a@limapholos.matflo.wg> <290d5579-2af4-c0b5-a322-1ccf04cf1161@geldenhuys.co.uk> <20161108154554.3b14aeb1@limapholos.matflo.wg> Message-ID: On 2016-11-08 14:45, Mattias Gaertner via Lazarus wrote: > Just do changes one by one and you are good to go. Thanks for the explanations... I'll continue has I have been doing, one at a time. Regards, Graeme From listbox at martoks-place.de Tue Nov 8 15:56:49 2016 From: listbox at martoks-place.de (Martok) Date: Tue, 8 Nov 2016 15:56:49 +0100 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: References: Message-ID: Hi, I may have missed this point in the discussion, but would it not make more sense to get a native HTML component (either from IPro or the THTML port) to the point where it can provide everything needed? THTML (my favourite) already has fairly solid layout and CSS support, so it should provide most things that are required. What it does miss is proper DOM access and manipulation, but I'd rather see efforts focused there than on CEF, which would require the same work to wrap it on the pascal side anyway... Depending on the scenario, we might get away without any Javascript support by using PascalScript, iff there would be some interface between DOM and the host application. Certainly doing that would result in lots of reusable code for completely different applications. Martok From markMLl.lazarus at telemetry.co.uk Tue Nov 8 16:20:22 2016 From: markMLl.lazarus at telemetry.co.uk (Mark Morgan Lloyd) Date: Tue, 8 Nov 2016 15:20:22 +0000 Subject: [Lazarus] Lazarus Version In-Reply-To: <20161108140508.6fbbae53@limapholos.matflo.wg> References: <1478427260700-4050205.post@n3.nabble.com> <511638044.118941.1478428534352@comcenter.netcologne.de> <20161108124539.1d9d56c5@limapholos.matflo.wg> <20161108140508.6fbbae53@limapholos.matflo.wg> Message-ID: On 08/11/16 13:30, Mattias Gaertner via Lazarus wrote: > On Tue, 8 Nov 2016 13:08:41 +0100 (CET)Michael Van Canneyt wrote: >> [...]> I'm not sure we're talking about the same thing. I don't know what 'version> unit' you mean ? > For example lazarus/lcl/lclversion.pas I don't want to hijack anybody else's thread, but I habitually use that file to get version info so that I can always find out what compiler etc. has been used to build a binary. The one downside of this is that I end up with a -Fu $(LazarusDir)/lcl which (I suspect) contributes to the entire LCL being rebuilt more often than is strictly necessary. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] From nc-gaertnma at netcologne.de Tue Nov 8 16:47:54 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Tue, 8 Nov 2016 16:47:54 +0100 Subject: [Lazarus] Anchoring fails on Windows 10 In-Reply-To: References: Message-ID: <20161108164754.57c22ae7@limapholos.matflo.wg> On Tue, 8 Nov 2016 14:59:45 +0100 Jürgen Hestermann via Lazarus wrote: > I have a simple form with 2 components, > a TVirtualDrawTree and a TProgressBar. > > The TProgressBar is anchored to the bottom of the form and > the bottom of the TVirtualDrawTree is anchored to the top of the TProgressBar. > > This works okay on Windows 7 and 8.1 but not on Windows 10! > When I resize the form by moving down the bottom border or > by making it full size then the position of the TProgressBar > within the form stays where it was > and is not moved to the bottom of the form. > > Anybody else having such issues on Windows 10? I tested with a TTreeView and a TProgressBar and it works here with Laz 1.7 at design time and run time. Mattias From nc-gaertnma at netcologne.de Tue Nov 8 17:10:25 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Tue, 8 Nov 2016 17:10:25 +0100 Subject: [Lazarus] Lazarus Version In-Reply-To: References: <1478427260700-4050205.post@n3.nabble.com> <511638044.118941.1478428534352@comcenter.netcologne.de> <20161108124539.1d9d56c5@limapholos.matflo.wg> <20161108140508.6fbbae53@limapholos.matflo.wg> Message-ID: <20161108171025.03302147@limapholos.matflo.wg> On Tue, 8 Nov 2016 15:20:22 +0000 Mark Morgan Lloyd via Lazarus wrote: > On 08/11/16 13:30, Mattias Gaertner via Lazarus wrote: > > On Tue, 8 Nov 2016 13:08:41 +0100 (CET)Michael Van Canneyt wrote: > >> [...]> I'm not sure we're talking about the same thing. I don't know what 'version> unit' you mean ? > > For example lazarus/lcl/lclversion.pas > > I don't want to hijack anybody else's thread, but I habitually use that > file to get version info so that I can always find out what compiler > etc. has been used to build a binary. How does lclversion tell you the used compiler? > The one downside of this is that I > end up with a -Fu $(LazarusDir)/lcl which (I suspect) contributes to the > entire LCL being rebuilt more often than is strictly necessary. Alternative: add lclbase as requirement in the project inspector. Mattias From nc-gaertnma at netcologne.de Tue Nov 8 17:12:46 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Tue, 8 Nov 2016 17:12:46 +0100 Subject: [Lazarus] COCOA Graphics In-Reply-To: <58C532E41FD247BA9884D9C2AC9AB92A@ianPC> References: <58C532E41FD247BA9884D9C2AC9AB92A@ianPC> Message-ID: <20161108171246.7395462e@limapholos.matflo.wg> On Sat, 1 Oct 2016 18:09:29 +0100 Josh via Lazarus wrote: > Not sure if this list is the place to post issues using COCOA > > I have tried laz 1.6 fpc 3.0.1 with fixes and laz 1.7 fpc 3.1.1 trunk > > I have a problem, I thought was with bgrabitmap but after some test it appears problem is lower down with image create. > > If I place a timage on a form and compile for carbon all is fine; image is shown. > If I change to Cocoa X64, it compiles and run but no image is shown. > > Any ideas of a fix; or how to report Create a bug report and attach a small example project (zipped). Mattias From mailinglists at geldenhuys.co.uk Tue Nov 8 17:37:13 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Tue, 8 Nov 2016 16:37:13 +0000 Subject: [Lazarus] Lazarus Version In-Reply-To: <20161108171025.03302147@limapholos.matflo.wg> References: <1478427260700-4050205.post@n3.nabble.com> <511638044.118941.1478428534352@comcenter.netcologne.de> <20161108124539.1d9d56c5@limapholos.matflo.wg> <20161108140508.6fbbae53@limapholos.matflo.wg> <20161108171025.03302147@limapholos.matflo.wg> Message-ID: <5019eda5-e190-2f05-3923-dacf933b4796@geldenhuys.co.uk> On 2016-11-08 16:10, Mattias Gaertner via Lazarus wrote: >> > I don't want to hijack anybody else's thread, but I habitually use that >> > file to get version info so that I can always find out what compiler >> > etc. has been used to build a binary. > How does lclversion tell you the used compiler? > > Yeah I'm confused too... Instead simply something like the following: =========================================== Program InfoDemo; Const User = {$I %USER%}; begin Write ('This program was compiled at ',{$I %TIME%}); Writeln (' on ',{$I %DATE%}); Writeln ('By ',User); Writeln ('Compiler version : ',{$I %FPCVERSION%}); Writeln ('Target CPU : ',{$I %FPCTARGET%}); end. =========================================== Creates the following output: This program was compiled at 16:36:18 on 2016/11/09 By graemeg Compiler version : 2.6.4 Target CPU : x86_64-freebsd Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From werner.pamler at freenet.de Tue Nov 8 17:36:30 2016 From: werner.pamler at freenet.de (Werner Pamler) Date: Tue, 8 Nov 2016 17:36:30 +0100 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: References: Message-ID: <06e64487-f0c7-94e1-eefd-4ab97bab5f77@freenet.de> Am 08.11.2016 um 15:56 schrieb Martok via Lazarus: > Hi, > > I may have missed this point in the discussion, but would it not make more sense > to get a native HTML component (either from IPro or the THTML port) to the point > where it can provide everything needed? THTML (my favourite) already has fairly > solid layout and CSS support, so it should provide most things that are > required. What it does miss is proper DOM access and manipulation, but I'd > rather see efforts focused there than on CEF, which would require the same work > to wrap it on the pascal side anyway... > > Depending on the scenario, we might get away without any Javascript support by > using PascalScript, iff there would be some interface between DOM and the host > application. > > Certainly doing that would result in lots of reusable code for completely > different applications. +1 From juergen.hestermann at gmx.de Tue Nov 8 18:45:56 2016 From: juergen.hestermann at gmx.de (=?UTF-8?Q?J=c3=bcrgen_Hestermann?=) Date: Tue, 8 Nov 2016 18:45:56 +0100 Subject: [Lazarus] Anchoring fails on Windows 10 In-Reply-To: <20161108164754.57c22ae7@limapholos.matflo.wg> References: <20161108164754.57c22ae7@limapholos.matflo.wg> Message-ID: <9d22e8de-0c0b-af00-8dbe-17811d2e4cad@gmx.de> Am 2016-11-08 um 16:47 schrieb Mattias Gaertner via Lazarus: > On Tue, 8 Nov 2016 14:59:45 +0100 > Jürgen Hestermann via Lazarus wrote: > >> I have a simple form with 2 components, >> a TVirtualDrawTree and a TProgressBar. >> >> The TProgressBar is anchored to the bottom of the form and >> the bottom of the TVirtualDrawTree is anchored to the top of the TProgressBar. >> >> This works okay on Windows 7 and 8.1 but not on Windows 10! >> When I resize the form by moving down the bottom border or >> by making it full size then the position of the TProgressBar >> within the form stays where it was >> and is not moved to the bottom of the form. >> >> Anybody else having such issues on Windows 10? > I tested with a TTreeView and a TProgressBar and it works here with Laz > 1.7 at design time and run time. > On Windows 10? I am using Lazarus 1.6. Where there changes in 1.7? From markMLl.lazarus at telemetry.co.uk Tue Nov 8 19:27:05 2016 From: markMLl.lazarus at telemetry.co.uk (Mark Morgan Lloyd) Date: Tue, 8 Nov 2016 18:27:05 +0000 Subject: [Lazarus] Lazarus Version In-Reply-To: <20161108171025.03302147@limapholos.matflo.wg> References: <1478427260700-4050205.post@n3.nabble.com> <511638044.118941.1478428534352@comcenter.netcologne.de> <20161108124539.1d9d56c5@limapholos.matflo.wg> <20161108140508.6fbbae53@limapholos.matflo.wg> <20161108171025.03302147@limapholos.matflo.wg> Message-ID: On 08/11/16 16:30, Mattias Gaertner via Lazarus wrote: > On Tue, 8 Nov 2016 15:20:22 +0000Mark Morgan Lloyd via Lazarus wrote: >> On 08/11/16 13:30, Mattias Gaertner via Lazarus wrote:> > On Tue, 8 Nov 2016 13:08:41 +0100 (CET)Michael Van Canneyt wrote: > >> [...]> I'm not sure we're talking about the same thing. I don't know what 'version> unit' you mean ? > > For example lazarus/lcl/lclversion.pas > > I don't want to hijack anybody else's thread, but I habitually use that > file to get version info so that I can always find out what compiler > etc. has been used to build a binary. > How does lclversion tell you the used compiler? I said compiler /etc./ lazV= 'Lazarus IDE v' + (*$I version.inc *) ; lclV= 'Lazarus Class Library v' + lcl_version; fpcV= 'Free Pascal v' + (*$I %FPCVERSION% *) ; fpcC= ' for ' + (*$I %FPCTARGETCPU% *) ; fpcO= (*$I %FPCTARGETOS% *) ; ..and much other stuff, almost all captured at build although in some cases post-processed. >> The one downside of this is that I > end up with a -Fu $(LazarusDir)/lcl which (I suspect) contributes to the > entire LCL being rebuilt more often than is strictly necessary. > Alternative: add lclbase as requirement in the project inspector. Thanks, I'll try that. Is there an easy way to get the version.inc file without specifying an absolute path? At the moment I'm using -Fi (or rather, the equivalent in the paths dialogue). -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] From michael at freepascal.org Tue Nov 8 21:45:16 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Tue, 8 Nov 2016 21:45:16 +0100 (CET) Subject: [Lazarus] Lazarus Version In-Reply-To: <20161108140508.6fbbae53@limapholos.matflo.wg> References: <1478427260700-4050205.post@n3.nabble.com> <511638044.118941.1478428534352@comcenter.netcologne.de> <20161108124539.1d9d56c5@limapholos.matflo.wg> <20161108140508.6fbbae53@limapholos.matflo.wg> Message-ID: On Tue, 8 Nov 2016, Mattias Gaertner via Lazarus wrote: > On Tue, 8 Nov 2016 13:08:41 +0100 (CET) > Michael Van Canneyt wrote: > >> [...] >> I'm not sure we're talking about the same thing. I don't know what 'version >> unit' you mean ? > > For example lazarus/lcl/lclversion.pas > > >> [...] >> As far as I know, the version number of a lazarus packages lives outside the >> sources, it resides just in the LPK. > > Yes. > >> I now use some XML routines to extract >> this version number from the .lpk and write it in the abovementioned include >> file. This happens in our build system. > > The IDE could write the version to some file (or update an existing > file). What would be a good place? A unit in the package. If you need the version, you use the unit. packagename_version.p(p|pas) > For example when package A needs to know the version of a required > package B the version must be stored either in a unit of A or B. > Storing it in B avoids redundancy, but when B is read only it needs > to be stored in A. Well, I will always control every package, so for me this question is academic. But it seems to me that if B doesn't provide the version, then the user is simply out of luck. If you really want to go that far, you could split the option in the package options: [x] Generate unit with version number [x] Generate version numbers for all used packages Then unit a_version; interface AVersionStr = '1.2.3'; BversionStr = '2.3.4'; implementation end. Or somesuch... Michael. From michael at freepascal.org Tue Nov 8 21:45:16 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Tue, 8 Nov 2016 21:45:16 +0100 (CET) Subject: [Lazarus] Lazarus Version In-Reply-To: <20161108140508.6fbbae53@limapholos.matflo.wg> References: <1478427260700-4050205.post@n3.nabble.com> <511638044.118941.1478428534352@comcenter.netcologne.de> <20161108124539.1d9d56c5@limapholos.matflo.wg> <20161108140508.6fbbae53@limapholos.matflo.wg> Message-ID: On Tue, 8 Nov 2016, Mattias Gaertner via Lazarus wrote: > On Tue, 8 Nov 2016 13:08:41 +0100 (CET) > Michael Van Canneyt wrote: > >> [...] >> I'm not sure we're talking about the same thing. I don't know what 'version >> unit' you mean ? > > For example lazarus/lcl/lclversion.pas > > >> [...] >> As far as I know, the version number of a lazarus packages lives outside the >> sources, it resides just in the LPK. > > Yes. > >> I now use some XML routines to extract >> this version number from the .lpk and write it in the abovementioned include >> file. This happens in our build system. > > The IDE could write the version to some file (or update an existing > file). What would be a good place? A unit in the package. If you need the version, you use the unit. packagename_version.p(p|pas) > For example when package A needs to know the version of a required > package B the version must be stored either in a unit of A or B. > Storing it in B avoids redundancy, but when B is read only it needs > to be stored in A. Well, I will always control every package, so for me this question is academic. But it seems to me that if B doesn't provide the version, then the user is simply out of luck. If you really want to go that far, you could split the option in the package options: [x] Generate unit with version number [x] Generate version numbers for all used packages Then unit a_version; interface AVersionStr = '1.2.3'; BversionStr = '2.3.4'; implementation end. Or somesuch... Michael. From nc-gaertnma at netcologne.de Tue Nov 8 23:13:26 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Tue, 8 Nov 2016 23:13:26 +0100 Subject: [Lazarus] Anchoring fails on Windows 10 In-Reply-To: <9d22e8de-0c0b-af00-8dbe-17811d2e4cad@gmx.de> References: <20161108164754.57c22ae7@limapholos.matflo.wg> <9d22e8de-0c0b-af00-8dbe-17811d2e4cad@gmx.de> Message-ID: <20161108231326.48ffcc6c@limapholos.matflo.wg> On Tue, 8 Nov 2016 18:45:56 +0100 Jürgen Hestermann via Lazarus wrote: >[...] > >> Anybody else having such issues on Windows 10? > > I tested with a TTreeView and a TProgressBar and it works here with Laz > > 1.7 at design time and run time. > > > On Windows 10? Yes. > I am using Lazarus 1.6. > Where there changes in 1.7? Maybe. It works with 1.6 too. Does it work with a new project? Mattias From nc-gaertnma at netcologne.de Tue Nov 8 23:23:37 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Tue, 8 Nov 2016 23:23:37 +0100 Subject: [Lazarus] Lazarus Version In-Reply-To: References: <1478427260700-4050205.post@n3.nabble.com> <511638044.118941.1478428534352@comcenter.netcologne.de> <20161108124539.1d9d56c5@limapholos.matflo.wg> <20161108140508.6fbbae53@limapholos.matflo.wg> Message-ID: <20161108232337.4341ea4a@limapholos.matflo.wg> On Tue, 8 Nov 2016 21:45:16 +0100 (CET) Michael Van Canneyt wrote: > packagename_version.p(p|pas) Ok. Although if we make it configurable, we can use it for lclversion.pas as well. >[...] > [x] Generate unit with version number Ok. Needs update when saving the package. > [x] Generate version numbers for all used packages Ok. Needs update when compiling the package. So the IDE and lazbuild can do that. fpmake cannot. > Then > > unit a_version; > > interface > AVersionStr = '1.2.3'; > BversionStr = '2.3.4'; To make compare operations simple I suggest to use the lclversion scheme: const lcl_major = 1; lcl_minor = 7; lcl_release = 0; lcl_patch = 0; lcl_fullversion = ((lcl_major * 100 + lcl_minor) * 100 + lcl_release) * 100 + lcl_patch; lcl_version = '1.7'; > implementation > > end. > > Or somesuch... Mattias From michael at freepascal.org Wed Nov 9 00:34:21 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Wed, 9 Nov 2016 00:34:21 +0100 (CET) Subject: [Lazarus] Lazarus Version In-Reply-To: <20161108232337.4341ea4a@limapholos.matflo.wg> References: <1478427260700-4050205.post@n3.nabble.com> <511638044.118941.1478428534352@comcenter.netcologne.de> <20161108124539.1d9d56c5@limapholos.matflo.wg> <20161108140508.6fbbae53@limapholos.matflo.wg> <20161108232337.4341ea4a@limapholos.matflo.wg> Message-ID: On Tue, 8 Nov 2016, Mattias Gaertner via Lazarus wrote: > On Tue, 8 Nov 2016 21:45:16 +0100 (CET) > Michael Van Canneyt wrote: > >> packagename_version.p(p|pas) > > Ok. Although if we make it configurable, we can use it for > lclversion.pas as well. Your proposals sound all very well. Michael. From noreply at z505.com Wed Nov 9 05:38:11 2016 From: noreply at z505.com (Lars) Date: Tue, 8 Nov 2016 21:38:11 -0700 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: <015cb9e9-3360-41bf-711d-aeba01152b3a@lumino.de> References: <6ae6beeae72d5bd668dbea960664f0d1.squirrel@gator3286.hostgator.com> <015cb9e9-3360-41bf-711d-aeba01152b3a@lumino.de> Message-ID: On Tue, November 8, 2016 3:49 am, Michael Schnell via Lazarus wrote: > On 08.11.2016 11:42, Michael Van Canneyt via Lazarus wrote: > >> >> I seriously doubt that. It's just something that will exist next to >> javascript but in essence will perform the same tasks as javascript. > ==OFF TOPIC== (so ignore if there is not a very short answer) > > > Any plans for a webassembly support with FPC ? > > There is an old thread about it here: http://forum.lazarus.freepascal.org/index.php/topic,28836.0.html Many skeptics, but many think it is an interesting idea even though skeptical. And what happened to microsoft silverlight? did anyone care? From noreply at z505.com Wed Nov 9 05:43:53 2016 From: noreply at z505.com (Lars) Date: Tue, 8 Nov 2016 21:43:53 -0700 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: <635fca1f-c3a8-5f43-6765-0897df679929@geldenhuys.co.uk> References: <6ae6beeae72d5bd668dbea960664f0d1.squirrel@gator3286.hostgator.com> <635fca1f-c3a8-5f43-6765-0897df679929@geldenhuys.co.uk> Message-ID: <4021a401413264ad02b1f70562dc8cc6.squirrel@gator3286.hostgator.com> On Tue, November 8, 2016 3:19 am, Graeme Geldenhuys via Lazarus wrote: > On 2016-11-08 02:51, Lars via Lazarus wrote: > >> It's sort of like a JVM bytecode, but for the web browser. >> > > That makes you wonder, why not simply go back to Java Applets. One issue, back in the day, was that you could only use Java programming language, right? At that time no one had thought of multi language jvm targetting with different originating languages... all java applets were java programming language coded, afaik... I could be wrong. Another issue with java applets is you had to make sure they were installed correctly, whereas javascript need not install. With webassembly I don't think there is a java system you have to install on the machine. Java applets required first downloading the JVM from Sun, right? It's been so long since I've seen a java craplet (that's the locker room talk name for it) that I cannot remember. From noreply at z505.com Wed Nov 9 05:48:31 2016 From: noreply at z505.com (Lars) Date: Tue, 8 Nov 2016 21:48:31 -0700 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: <06e64487-f0c7-94e1-eefd-4ab97bab5f77@freenet.de> References: <06e64487-f0c7-94e1-eefd-4ab97bab5f77@freenet.de> Message-ID: On Tue, November 8, 2016 9:36 am, Werner Pamler via Lazarus wrote: > Am 08.11.2016 um 15:56 schrieb Martok via Lazarus: > >> Hi, >> >> >> I may have missed this point in the discussion, but would it not make >> more sense to get a native HTML component (either from IPro or the THTML >> port) to the point where it can provide everything needed? ... > +1 Well the reason chromium is in my line of sight, is because other people do the work to maintain the browser for you. Creating your own web browser component is massive amounts of work, whereas chromium is coded by other people. True you have to write wrappers around it, but you also end up with a standard component where there are already plenty of c++ examples to learn from, and you are supported by a massive team over at chromium. Whereas writing your own browser component requires constantly playing "catch up", implementing every feature needed which chromium had 5 years ago. So does IPro or THtml have any large following and existing codebase to work with? I would have to learn about these as I have not used them. From noreply at z505.com Wed Nov 9 06:13:12 2016 From: noreply at z505.com (Lars) Date: Tue, 8 Nov 2016 22:13:12 -0700 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: References: <20161021111331.0846d181@limapholos.matflo.wg> <0690e875-8608-c93d-ce39-f86e7a0bf5e3@geldenhuys.co.uk> <20161021120507.33bf5fdd@limapholos.matflo.wg> <20161022233647.63d1d853@limapholos.matflo.wg> <0ccf92ea-c2ce-8c1d-cec1-bf0777619b41@geldenhuys.co.uk> <720ab092ae799b63946c94c8842c0b6e.squirrel@gator3286.hostgator.com> Message-ID: <9630f8207a8a79038ffa00053b12332d.squirrel@gator3286.hostgator.com> On Tue, November 8, 2016 3:13 am, Graeme Geldenhuys via Lazarus wrote: > My point is, for a help system you really don't need the latest and > greatest HTML5 features. It's simply not needed. What you do want in well > formatted text, images and some basic rich text styles. Good help is more > about the contents and the speed of getting to that contents, that about > the presentation. But some people are more obsessed about presentation > with rubbish or near zero content. > Agreed, but when you need documentation to look as professional as a PDF file, HTML 5 could be useful. I find the documentation, for example, for Total Commander, to just be a little bit too Windows 3.1 looking. It's may be good documentation filled with lots of good text, but it feels like something from Windows 95 or windows 3.1. For professional software apps a windows 3.1 look may be just a bit too off putting. In the case of total commander, the folks who use total commander are they types of nerds that don't care. But for modern professional capitalism sold apps, I think help documents have to look more modern. As much as I hate modern, just for the sake of being modern. Like some kind of fashion show. From noreply at z505.com Wed Nov 9 06:20:15 2016 From: noreply at z505.com (Lars) Date: Tue, 8 Nov 2016 22:20:15 -0700 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: References: <6ae6beeae72d5bd668dbea960664f0d1.squirrel@gator3286.hostgator.com> Message-ID: <65bed2e82491ab98f216ff9816144e5b.squirrel@gator3286.hostgator.com> On Tue, November 8, 2016 3:42 am, Michael Van Canneyt via Lazarus wrote: > I seriously doubt that. It's just something that will exist next to > javascript but in essence will perform the same tasks as javascript. You > can create relatively clean and structured javascript if you want. It just > requires discipline as the language doesn't enforce it. I start off by writing some javascript and I think, hey this isn't so bad. But eventually after about 10 paragraphs of code it starts to get ugly, no matter what I try. That's why there is a book written called "Javascript, the good parts" because it has become such a large mammoth that they needed to write a book about a subset of java that may (or may not) be the good parts. Whether those are the good parts or not, is still up for debate, because I haven't read the book. If I had time.. > > The problem is IMHO not so much the language, but what you do with it. > > Okay but take brainf*ck language as an example. In this case the language is in fact a serious problem. Or take C++. The language just encourages you to do nasty things when you need/want to. In order to write sensible looking C++ code you should... just use a subset of C++, such as C, and avoid most C++ features. But then you call in some library and they are using that feature, so, you have to use it too... the issue with javascript is you pull in a lot of libraries that make use of the features so you have to end up using them indirectly too. Again, I guess I should read the book "Javascript the good parts" if I have time. > > Well, there is interest in a WebAssembly backend for FPC. > Someone is looking at it. > Just as we are working on a transpiler from Pascal to Javascript. > That's good news, and I have no idea how you guys keep up with all this crap that comes out every year. The work required to port fpc to all these systems, whether virtual machines, or real machines, is enormous. What ever happened to LLVM ? much interest? Yet another port to a virtual machine. From mschnell at lumino.de Wed Nov 9 09:48:26 2016 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 9 Nov 2016 09:48:26 +0100 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: References: <6ae6beeae72d5bd668dbea960664f0d1.squirrel@gator3286.hostgator.com> <015cb9e9-3360-41bf-711d-aeba01152b3a@lumino.de> Message-ID: <3c7a5923-aed4-a1cc-5521-fa8cb75d0f44@lumino.de> > I wrote it in the email you are replying to. Please re-read. > Sorry for hitting the send button too early :-( -Michael From mschnell at lumino.de Wed Nov 9 09:56:48 2016 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 9 Nov 2016 09:56:48 +0100 Subject: [Lazarus] missing "LCLWidgetType" drop down menu Message-ID: Version 1.6 on Windows: Project -> Project Options -> Additions and Overrides -> Set "LCLWidgetType" -> Drop Down selection Value "fpgui". Sadly in my compiled "trunk" version 1.7 on Linux (revision 53324), the <"LCLWidgetType"> drop down menu is not shown any more. So the available WidgetTypes (aka Interfaces) can't be easily selected . Bug, feature or erroneous configuration on my site ? -Michael From lazarus at kluug.net Wed Nov 9 10:01:18 2016 From: lazarus at kluug.net (Ondrej Pokorny) Date: Wed, 9 Nov 2016 10:01:18 +0100 Subject: [Lazarus] missing "LCLWidgetType" drop down menu In-Reply-To: References: Message-ID: <7c7c86a1-6b6f-69ee-4fd8-021201877cda@kluug.net> On 09.11.2016 9:56, Michael Schnell via Lazarus wrote: > Version 1.6 on Windows: > > Project -> Project Options -> Additions and Overrides -> Set > "LCLWidgetType" -> Drop Down selection Value "fpgui". > > > Sadly in my compiled "trunk" version 1.7 on Linux (revision 53324), > the <"LCLWidgetType"> drop down menu is not shown any more. So the > available WidgetTypes (aka Interfaces) can't be easily selected . > > Bug, feature or erroneous configuration on my site ? Strange, here it is (Win10 - it shouldn't be OS-dependent). Please recheck. Ondrej From mschnell at lumino.de Wed Nov 9 10:38:59 2016 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 9 Nov 2016 10:38:59 +0100 Subject: [Lazarus] WebAssembly Message-ID: <342e6a09-9f2b-713c-9b9e-5d9d1340c66f@lumino.de> (Creating a new thread instead of using "Help System with Chromium Embedded component") On 09.11.2016 05:38, Lars via Lazarus wrote: > On Tue, November 8, 2016 3:49 am, Michael Schnell via Lazarus wrote: >> On 08.11.2016 11:42, Michael Van Canneyt via Lazarus wrote: >> >>> I seriously doubt that. It's just something that will exist next to >>> javascript but in essence will perform the same tasks as javascript. >> ==OFF TOPIC== (so ignore if there is not a very short answer) >> >> >> Any plans for a webassembly support with FPC ? >> >> > There is an old thread about it here: > > http://forum.lazarus.freepascal.org/index.php/topic,28836.0.html > > Many skeptics, but many think it is an interesting idea even though > skeptical. > > And what happened to microsoft silverlight? did anyone care? IMHO Silverlight is dying because Java is the winner over C#, due to Android systems outselling any other OS architecture. Hence WebASM - that seems to be based on Java - might be successful in pushing the idea of allowing for precompiled byte code embedded in HTML. Regarding fpc/Lazarus, it obviously would be a huge benefit if on top of fpc's WebAdmin support, the LCL would provide decent support for an appropriate WidgetType that allows to simply cross-compile a "usual" Lazarus project to be runnable in a browser. The "WEB-LCL"code would need to access the Browser's "GUI" infrastructure using the appropriate API (supposedly defined as a part of the WebASM specs), in a way as compatible as possible to the other WidgetTypes (such as "Win32" or "GTK2"). Of course a "WEB-LCL" and "WEB-RTL" (dynamic Web-linkable) WEBASM files needs to be provided on a server and the project resources need to be embedded somehow. As a further extension, "in depth" support for communicating (using WebSocket) between the parts of a dual-issue application, one part running in native code on the Server "behind" the WebServer, one part running in the browser, would be very appropriate. (Doing a single "application" and seamlessly distributing it in that way had always been a promise of Silverlight's.) This is a great opportunity to beat Embarcadero :-):-):-) Michael (just dreaming) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at geldenhuys.co.uk Wed Nov 9 11:07:03 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 9 Nov 2016 10:07:03 +0000 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: <4021a401413264ad02b1f70562dc8cc6.squirrel@gator3286.hostgator.com> References: <6ae6beeae72d5bd668dbea960664f0d1.squirrel@gator3286.hostgator.com> <635fca1f-c3a8-5f43-6765-0897df679929@geldenhuys.co.uk> <4021a401413264ad02b1f70562dc8cc6.squirrel@gator3286.hostgator.com> Message-ID: <06e71da8-3eab-a3d9-3501-6e2bb8d449c9@geldenhuys.co.uk> On 2016-11-09 04:43, Lars via Lazarus wrote: > One issue, back in the day, was that you could only use Java programming > language, right? Hence the name "Java Applet" ;-) > Another issue with java applets is you had to make sure they were > installed correctly, No, the web server served it to the web browser, just like it does with HTML, CSS etc. Later they introduced WebStart which allows you to run the Java Applet or Application outside the browser window too - thus the embedded window was not a requirement any more. > Java applets required first downloading the JVM from Sun, right? Correct, just like you need to download and install a Flash plugin before you can view the crap flash-based ads. But if there was enough of a push, a Java runtime could easily have been included with a web browser (just like there Javascript Engines - Netscape did both, so did Opera back in the day), or include a Java runitem as standard with the OS itself (like IBM did with OS/2). But as with everything Internet based, everything has a maximum shelf life of 6-12 months, then something new must be introduced. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From mailinglists at geldenhuys.co.uk Wed Nov 9 11:10:31 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 9 Nov 2016 10:10:31 +0000 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: <9630f8207a8a79038ffa00053b12332d.squirrel@gator3286.hostgator.com> References: <20161021111331.0846d181@limapholos.matflo.wg> <0690e875-8608-c93d-ce39-f86e7a0bf5e3@geldenhuys.co.uk> <20161021120507.33bf5fdd@limapholos.matflo.wg> <20161022233647.63d1d853@limapholos.matflo.wg> <0ccf92ea-c2ce-8c1d-cec1-bf0777619b41@geldenhuys.co.uk> <720ab092ae799b63946c94c8842c0b6e.squirrel@gator3286.hostgator.com> <9630f8207a8a79038ffa00053b12332d.squirrel@gator3286.hostgator.com> Message-ID: <26d53b2d-48d4-44a1-a9e7-c1176d7df115@geldenhuys.co.uk> On 2016-11-09 05:13, Lars via Lazarus wrote: > I find the documentation, for example, for > Total Commander, to just be a little bit too Windows 3.1 looking. I'll bet you a 6-pack of beer that the documentation was written by the developer himself. That would explain the lack of typography. :) Regards, Graeme From mschnell at lumino.de Wed Nov 9 11:16:09 2016 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 9 Nov 2016 11:16:09 +0100 Subject: [Lazarus] missing "LCLWidgetType" drop down menu In-Reply-To: <7c7c86a1-6b6f-69ee-4fd8-021201877cda@kluug.net> References: <7c7c86a1-6b6f-69ee-4fd8-021201877cda@kluug.net> Message-ID: <3a0e4c81-7e7f-8865-601d-02833b8bf4a2@lumino.de> On 09.11.2016 10:01, Ondrej Pokorny via Lazarus wrote: > > Strange, here it is (Win10 - it shouldn't be OS-dependent). Please > recheck. Graeme pointed me to the cause. I did not define the project as an "LCL project" (as this is a project to test my own extension to the NoGUI widget Type which of course is not yet in the LCL but in my own code). After defining a new project I do see drop down menu. So not a bug but a decent feature. -Michael From nc-gaertnma at netcologne.de Wed Nov 9 11:53:15 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Wed, 9 Nov 2016 11:53:15 +0100 Subject: [Lazarus] WebAssembly In-Reply-To: <342e6a09-9f2b-713c-9b9e-5d9d1340c66f@lumino.de> References: <342e6a09-9f2b-713c-9b9e-5d9d1340c66f@lumino.de> Message-ID: <20161109115315.3517a3c6@limapholos.matflo.wg> On Wed, 9 Nov 2016 10:38:59 +0100 Michael Schnell via Lazarus wrote: >[...] > Hence WebASM - that seems to be based on Java - might be successful in > pushing the idea of allowing for precompiled byte code embedded in HTML. WebAsm <> WebAssembly. WebAsm is "A processor for text-based documents (most notably, HTML)". WebAssembly is a subset of JavaScript with some additions, optimized for compiling languages like C/C++/Java to JavaSript. Some browser vendors said they are working on it. >[...] Mattias From mschnell at lumino.de Wed Nov 9 12:02:56 2016 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 9 Nov 2016 12:02:56 +0100 Subject: [Lazarus] WebAssembly In-Reply-To: <20161109115315.3517a3c6@limapholos.matflo.wg> References: <342e6a09-9f2b-713c-9b9e-5d9d1340c66f@lumino.de> <20161109115315.3517a3c6@limapholos.matflo.wg> Message-ID: <4c881acd-15d3-4851-31e1-49db9228ab3b@lumino.de> On 09.11.2016 11:53, Mattias Gaertner via Lazarus wrote: > > WebAsm <> WebAssembly. > > WebAsm is "A processor for text-based documents (most notably, HTML)". > > WebAssembly is a subset of JavaScript with some additions, optimized > for compiling languages like C/C++/Java to JavaSript. Some browser > vendors said they are working on it. Thanks for clarification. see -> https://hacks.mozilla.org/2016/03/a-webassembly-milestone/ -Michael From mschnell at lumino.de Wed Nov 9 12:12:58 2016 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 9 Nov 2016 12:12:58 +0100 Subject: [Lazarus] WebAssembly In-Reply-To: <4c881acd-15d3-4851-31e1-49db9228ab3b@lumino.de> References: <342e6a09-9f2b-713c-9b9e-5d9d1340c66f@lumino.de> <20161109115315.3517a3c6@limapholos.matflo.wg> <4c881acd-15d3-4851-31e1-49db9228ab3b@lumino.de> Message-ID: <67054bc3-5664-de7c-aa11-d7527c901511@lumino.de> -> https://hacks.mozilla.org/2016/10/webassembly-browser-preview/ : > However, assuming no issues are found that require substantial time to > address, the WebAssembly Community Group would like to mark an initial > version of the standard as “done” in Q1 2017 which would then enable > browsers to start shipping WebAssembly without a flag. For our part, > in Firefox, this green light would mean shipping WebAssembly in > Firefox 52 (March 2017). -Michael From lazarus at kluug.net Wed Nov 9 12:31:18 2016 From: lazarus at kluug.net (Ondrej Pokorny) Date: Wed, 9 Nov 2016 12:31:18 +0100 Subject: [Lazarus] missing "LCLWidgetType" drop down menu In-Reply-To: <3a0e4c81-7e7f-8865-601d-02833b8bf4a2@lumino.de> References: <7c7c86a1-6b6f-69ee-4fd8-021201877cda@kluug.net> <3a0e4c81-7e7f-8865-601d-02833b8bf4a2@lumino.de> Message-ID: <7ecda638-c32a-4e9b-565a-f2e530fb2fcc@kluug.net> On 09.11.2016 11:16, Michael Schnell via Lazarus wrote: > On 09.11.2016 10:01, Ondrej Pokorny via Lazarus wrote: >> >> Strange, here it is (Win10 - it shouldn't be OS-dependent). Please >> recheck. > Graeme pointed me to the cause. I did not define the project as an > "LCL project" (as this is a project to test my own extension to the > NoGUI widget Type which of course is not yet in the LCL but in my own > code). > > After defining a new project I do see drop down menu. > > So not a bug but a decent feature. I improved user experience in r53326. Ondrej From juergen.hestermann at gmx.de Wed Nov 9 12:45:02 2016 From: juergen.hestermann at gmx.de (=?UTF-8?Q?J=c3=bcrgen_Hestermann?=) Date: Wed, 9 Nov 2016 12:45:02 +0100 Subject: [Lazarus] Anchoring fails on Windows 10 In-Reply-To: <20161108231326.48ffcc6c@limapholos.matflo.wg> References: <20161108164754.57c22ae7@limapholos.matflo.wg> <9d22e8de-0c0b-af00-8dbe-17811d2e4cad@gmx.de> <20161108231326.48ffcc6c@limapholos.matflo.wg> Message-ID: Am 2016-11-08 um 23:13 schrieb Mattias Gaertner via Lazarus: > On Tue, 8 Nov 2016 18:45:56 +0100 > Jürgen Hestermann via Lazarus wrote: >>>> Anybody else having such issues on Windows 10? >>> I tested with a TTreeView and a TProgressBar and it works here with Laz >>> 1.7 at design time and run time. >> On Windows 10? > Yes. > [...] > Does it work with a new project? Although I did not change anything that is related to anchoring it suddenly works on Win 10 too! I have absolutely no idea what made it fail permanently before. Sorry for the noise. From mschnell at lumino.de Wed Nov 9 12:55:40 2016 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 9 Nov 2016 12:55:40 +0100 Subject: [Lazarus] missing "LCLWidgetType" drop down menu In-Reply-To: <7ecda638-c32a-4e9b-565a-f2e530fb2fcc@kluug.net> References: <7c7c86a1-6b6f-69ee-4fd8-021201877cda@kluug.net> <3a0e4c81-7e7f-8865-601d-02833b8bf4a2@lumino.de> <7ecda638-c32a-4e9b-565a-f2e530fb2fcc@kluug.net> Message-ID: <8a29a018-b228-4be5-3b34-9abba0bd2bc1@lumino.de> On 09.11.2016 12:31, Ondrej Pokorny via Lazarus wrote: > > I improved user experience in r53326. Grayed out now... Works, Thanks ! -Michael From mailinglists at geldenhuys.co.uk Wed Nov 9 14:31:07 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 9 Nov 2016 13:31:07 +0000 Subject: [Lazarus] persistent bookmarks in the IDE? Message-ID: <830fa670-4db0-6e94-5c27-776fcfb98662@geldenhuys.co.uk> Hi, Is it possible for Lazarus (trunk) to remember bookmark locations between restarts? Or save bookmarks per project? At the moment I loose all my bookmarks while doing a restart, or quickly switching to another project to lookup something and then switch back to what I was working on. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From lazarus at kluug.net Wed Nov 9 14:36:00 2016 From: lazarus at kluug.net (Ondrej Pokorny) Date: Wed, 9 Nov 2016 14:36:00 +0100 Subject: [Lazarus] persistent bookmarks in the IDE? In-Reply-To: <830fa670-4db0-6e94-5c27-776fcfb98662@geldenhuys.co.uk> References: <830fa670-4db0-6e94-5c27-776fcfb98662@geldenhuys.co.uk> Message-ID: <0a88df72-2175-ab54-54cf-9d3e88de31a1@kluug.net> On 09.11.2016 14:31, Graeme Geldenhuys via Lazarus wrote: > Hi, > > Is it possible for Lazarus (trunk) to remember bookmark locations > between restarts? Or save bookmarks per project? > > At the moment I loose all my bookmarks while doing a restart, or quickly > switching to another project to lookup something and then switch back to > what I was working on. My bookmarks are saved when saving the project. I am not aware of an option to disable/enable it. Ondrej From info at voiceliveeditor.com Wed Nov 9 14:49:17 2016 From: info at voiceliveeditor.com (info at voiceliveeditor.com) Date: Wed, 9 Nov 2016 13:49:17 -0000 Subject: [Lazarus] Slow Graphics in Cocoa Message-ID: <2724409F91FD427FA2828171D449BC9A@ianPC> Hi Hope their is a fix for this. After doing some testing; with placing images from an timagelist on a panel, the Cocoa seems to be 10% as fast as carbon, or carbon is 900% faster than cocoa. I have created a vid to demonstrate the problem. https://www.dropbox.com/s/vr43ztm0vsiml0u/slowcocoa.mp4?dl=0 Anyone else experiencing this slowness in cocoa? I will create a simple test version and upload that does not require any 3rd party components. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nc-gaertnma at netcologne.de Wed Nov 9 14:49:30 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Wed, 9 Nov 2016 14:49:30 +0100 Subject: [Lazarus] persistent bookmarks in the IDE? In-Reply-To: <0a88df72-2175-ab54-54cf-9d3e88de31a1@kluug.net> References: <830fa670-4db0-6e94-5c27-776fcfb98662@geldenhuys.co.uk> <0a88df72-2175-ab54-54cf-9d3e88de31a1@kluug.net> Message-ID: <20161109144930.531b18dd@limapholos.matflo.wg> On Wed, 9 Nov 2016 14:36:00 +0100 Ondrej Pokorny via Lazarus wrote: > On 09.11.2016 14:31, Graeme Geldenhuys via Lazarus wrote: > > Hi, > > > > Is it possible for Lazarus (trunk) to remember bookmark locations > > between restarts? Or save bookmarks per project? > > > > At the moment I loose all my bookmarks while doing a restart, or quickly > > switching to another project to lookup something and then switch back to > > what I was working on. > > My bookmarks are saved when saving the project. I am not aware of an > option to disable/enable it. Correct. Bookmarks are stored in the session (usually the lps file). Mattias From mailinglists at geldenhuys.co.uk Wed Nov 9 14:50:34 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 9 Nov 2016 13:50:34 +0000 Subject: [Lazarus] persistent bookmarks in the IDE? In-Reply-To: <0a88df72-2175-ab54-54cf-9d3e88de31a1@kluug.net> References: <830fa670-4db0-6e94-5c27-776fcfb98662@geldenhuys.co.uk> <0a88df72-2175-ab54-54cf-9d3e88de31a1@kluug.net> Message-ID: <0280412f-bec0-ffde-54bd-e46d2b71e2b9@geldenhuys.co.uk> On 2016-11-09 13:36, Ondrej Pokorny via Lazarus wrote: > My bookmarks are saved when saving the project. I am not aware of an > option to disable/enable it. Good to know the functionality exists. Now to find out why it doesn't work here - both Linux and FreeBSD systems. Do you know where the bookmark are stored? Is it the *.lps (session) file? Regards, Graeme From mailinglists at geldenhuys.co.uk Wed Nov 9 14:51:26 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 9 Nov 2016 13:51:26 +0000 Subject: [Lazarus] persistent bookmarks in the IDE? In-Reply-To: <20161109144930.531b18dd@limapholos.matflo.wg> References: <830fa670-4db0-6e94-5c27-776fcfb98662@geldenhuys.co.uk> <0a88df72-2175-ab54-54cf-9d3e88de31a1@kluug.net> <20161109144930.531b18dd@limapholos.matflo.wg> Message-ID: <7ef6ecf2-3463-e37c-d92a-589f82896797@geldenhuys.co.uk> On 2016-11-09 13:49, Mattias Gaertner via Lazarus wrote: > Bookmarks are stored in the session (usually the lps file). Thanks, I'll dig in there and see what is going wrong. Regards, Graeme From marcov at stack.nl Wed Nov 9 15:57:04 2016 From: marcov at stack.nl (Marco van de Voort) Date: Wed, 9 Nov 2016 15:57:04 +0100 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: References: <06e64487-f0c7-94e1-eefd-4ab97bab5f77@freenet.de> Message-ID: <20161109145704.GA58088@stack.nl> On Tue, Nov 08, 2016 at 09:48:31PM -0700, Lars via Lazarus wrote: > >> port) to the point where it can provide everything needed? > ... > > +1 > > Well the reason chromium is in my line of sight, is because other people > do the work to maintain the browser for you. True, but you also subscribe to an engine with a lot more known vulnerabilities and attack surface that way. The frequent updates that often break interfaces are also an headache. If multi versions installs are not possible or hard, that would complicate keeping old IDEs running. > Creating your own web > browser component is massive amounts of work, whereas chromium is coded by > other people. But deployment and updating is still yours, and a tad more involved. If I would replace lhelp and chm, I wouldn't go that way, but some way with a local webserver (for searching and the like), and just use whatever is installed. The best reason to have some local (whatever how limited) widget is for IDE popups of helptext instead of an external browser. But I think lhelp still has enough leeway, and I think Graeme greatly overexaggerates the problems. From nc-gaertnma at netcologne.de Wed Nov 9 16:02:33 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Wed, 9 Nov 2016 16:02:33 +0100 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: <20161109145704.GA58088@stack.nl> References: <06e64487-f0c7-94e1-eefd-4ab97bab5f77@freenet.de> <20161109145704.GA58088@stack.nl> Message-ID: <20161109160233.2eb4c01d@limapholos.matflo.wg> On Wed, 9 Nov 2016 15:57:04 +0100 Marco van de Voort via Lazarus wrote: >[...] > The best reason to have some local (whatever how limited) widget is for IDE > popups of helptext instead of an external browser. Good point. Mattias From mailinglists at geldenhuys.co.uk Wed Nov 9 16:24:17 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 9 Nov 2016 15:24:17 +0000 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: <20161109145704.GA58088@stack.nl> References: <06e64487-f0c7-94e1-eefd-4ab97bab5f77@freenet.de> <20161109145704.GA58088@stack.nl> Message-ID: On 2016-11-09 14:57, Marco van de Voort via Lazarus wrote: > But I think lhelp still has enough leeway, and I think Graeme greatly > overexaggerates the problems. And my comparison screenshots (from earlier) show the problem as clear as day. Your comment about "LHelp works fine with fpdoc generated CHM" is a moot point. LHelp is also used for shipping your own application with help and a help viewer (Linux, OSX, FreeBSD, Solaris etc don't include CHM help viewers as standard), in which case you will not be using fpdoc to author application help. The inconsistency of HTML rendering components is a real problem. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From listbox at martoks-place.de Wed Nov 9 18:52:26 2016 From: listbox at martoks-place.de (Martok) Date: Wed, 9 Nov 2016 18:52:26 +0100 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: <20161109160233.2eb4c01d@limapholos.matflo.wg> References: <06e64487-f0c7-94e1-eefd-4ab97bab5f77@freenet.de> <20161109145704.GA58088@stack.nl> <20161109160233.2eb4c01d@limapholos.matflo.wg> Message-ID: Am 09.11.2016 um 16:02 schrieb Mattias Gaertner via Lazarus: > On Wed, 9 Nov 2016 15:57:04 +0100 > Marco van de Voort via Lazarus wrote: >> [...] >> The best reason to have some local (whatever how limited) widget is for IDE >> popups of helptext instead of an external browser. That was also one of my reasons, too. It doesn't even have to do everything modern HTML can (on the part of the layout engine, there haven't really been that many changes anyway), but something to view rich content (purposefully not saying 'RichView' here...) would be good to have. HTMLHelp would really just be one of multiple applications for it. Am 09.11.2016 um 16:24 schrieb Graeme Geldenhuys via Lazarus: > The inconsistency of HTML rendering components is a real problem. Yet another reason against the IE5 of this decade. From fjf.vanleeuwen at quicknet.nl Thu Nov 10 19:39:48 2016 From: fjf.vanleeuwen at quicknet.nl (Frans) Date: Thu, 10 Nov 2016 19:39:48 +0100 Subject: [Lazarus] Listboxes disappear after form resize Message-ID: Hi. I have a strange problem with a sizeable form. The form has 2 listboxes that are anchored to the groupbox (leftlistbox and rightlistbox) and a speedbutton in between (rightlistbox). The form is resizeable and that is no problem, until I try to change the number of columns in the listbox, depending on the width of the form after resizing. The zip file contains 3 pictures, the form at starting point, the form after the first resize, both listboxes are gone, and the form after another resize, the listboxes are back again. The formules I use are: procedure TPlayerForm.FormResize(Sender: TObject); begin leftlistbox.Width := leftlistbox.Constraints.MinWidth + (Self.Width - Self.Constraints.MinWidth) div 2; // the rightlistbox changes through the anchors end; procedure TPlayerForm.ListBoxResize(Sender: TObject); begin leftlistbox.Columns := lftlistbox.Width div leftlistbox.Constraints.MinWidth; rightlistbox.Columns := leftlistbox.Columns; end; -- mvg Frans van Leeuwen M 06-51695390 -------------- next part -------------- A non-text attachment was scrubbed... Name: player.zip Type: application/x-zip-compressed Size: 116961 bytes Desc: not available URL: From noreply at z505.com Fri Nov 11 01:33:09 2016 From: noreply at z505.com (Lars) Date: Thu, 10 Nov 2016 17:33:09 -0700 Subject: [Lazarus] WebAssembly In-Reply-To: <342e6a09-9f2b-713c-9b9e-5d9d1340c66f@lumino.de> References: <342e6a09-9f2b-713c-9b9e-5d9d1340c66f@lumino.de> Message-ID: <107fc5004fb746d314b14db30c2425d0.squirrel@gator3286.hostgator.com> On Wed, November 9, 2016 2:38 am, Michael Schnell via Lazarus wrote: > IMHO Silverlight is dying because Java is the winner over C#, due to > Android systems outselling any other OS architecture. > > > Hence WebASM - that seems to be based on Java - might be successful in > pushing the idea of allowing for precompiled byte code embedded in HTML. > If you mean based on java as in it compiles to a virtual machine like thing, actually this was more of a pascal thing, and oberon thing, than Java - java stole the idea from the UCSD-Pascal system, ancient. I wrote about this long ago... And, I could be wrong but I think java also stole from Oberon. i.e. when people credit Java for the idea of JVM, what they really should be crediting is UCSD Pascal, and then Oberon which succeeded it... Oberon is 1990's and maybe late 80's technology, UCSD pascal is ancient. But I'm nit picking. > Regarding fpc/Lazarus, it obviously would be a huge benefit if on top of > fpc's WebAdmin support, the LCL would provide decent support for an > appropriate WidgetType that allows to simply cross-compile a "usual" > Lazarus project to be runnable in a browser. > I'm partial to Marco V.'s post on the lazarus forum I linked.. I think maybe porting lazarus to web assembly might just result in all sorts of kludges. Maybe best to start from scratch. But as I said I'm partial: not fully decided. From noreply at z505.com Fri Nov 11 01:40:03 2016 From: noreply at z505.com (Lars) Date: Thu, 10 Nov 2016 17:40:03 -0700 Subject: [Lazarus] WebAssembly In-Reply-To: <4c881acd-15d3-4851-31e1-49db9228ab3b@lumino.de> References: <342e6a09-9f2b-713c-9b9e-5d9d1340c66f@lumino.de> <20161109115315.3517a3c6@limapholos.matflo.wg> <4c881acd-15d3-4851-31e1-49db9228ab3b@lumino.de> Message-ID: <3e35bb04912248b82c3c25cae648fc22.squirrel@gator3286.hostgator.com> On Wed, November 9, 2016 4:02 am, Michael Schnell via Lazarus wrote: > On 09.11.2016 11:53, Mattias Gaertner via Lazarus wrote: > >> >> WebAsm <> WebAssembly. >> >> >> WebAsm is "A processor for text-based documents (most notably, HTML)". >> >> >> WebAssembly is a subset of JavaScript with some additions, optimized >> for compiling languages like C/C++/Java to JavaSript. Some browser >> vendors said they are working on it. > Thanks for clarification. > > I thought the idea of web assembly was not to compile to javascript, but to compile to byte code.. We already have tons of tools that compile to javascript, so what would be the difference between those tools and web assembly.. i.e. I thought ( could be mistaken ) that web assembly put little chunks of assembly like code in your HTML. Almost like assembly language but higher level. Does it really compile just to plain javascript? I thought the idea was to actually create a new assembly like instruction language and not use javascript language From noreply at z505.com Fri Nov 11 01:47:13 2016 From: noreply at z505.com (Lars) Date: Thu, 10 Nov 2016 17:47:13 -0700 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: <06e71da8-3eab-a3d9-3501-6e2bb8d449c9@geldenhuys.co.uk> References: <6ae6beeae72d5bd668dbea960664f0d1.squirrel@gator3286.hostgator.com> <635fca1f-c3a8-5f43-6765-0897df679929@geldenhuys.co.uk> <4021a401413264ad02b1f70562dc8cc6.squirrel@gator3286.hostgator.com> <06e71da8-3eab-a3d9-3501-6e2bb8d449c9@geldenhuys.co.uk> Message-ID: On Wed, November 9, 2016 3:07 am, Graeme Geldenhuys via Lazarus wrote: > On 2016-11-09 04:43, Lars via Lazarus wrote: > > >> One issue, back in the day, was that you could only use Java >> programming language, right? > > Hence the name "Java Applet" ;-) > > But, could one compile fpc code to javaapplet jvm bytecode? Why no one thought of this idea? And when I say fpc, I mean literally any language not just fpc. We already have tools that convert languages to jvm runnable code, so why not java applets programmed in other languages? From noreply at z505.com Fri Nov 11 01:53:01 2016 From: noreply at z505.com (Lars) Date: Thu, 10 Nov 2016 17:53:01 -0700 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: <26d53b2d-48d4-44a1-a9e7-c1176d7df115@geldenhuys.co.uk> References: <20161021111331.0846d181@limapholos.matflo.wg> <0690e875-8608-c93d-ce39-f86e7a0bf5e3@geldenhuys.co.uk> <20161021120507.33bf5fdd@limapholos.matflo.wg> <20161022233647.63d1d853@limapholos.matflo.wg> <0ccf92ea-c2ce-8c1d-cec1-bf0777619b41@geldenhuys.co.uk> <720ab092ae799b63946c94c8842c0b6e.squirrel@gator3286.hostgator.com> <9630f8207a8a79038ffa00053b12332d.squirrel@gator3286.hostgator.com> <26d53b2d-48d4-44a1-a9e7-c1176d7df115@geldenhuys.co.uk> Message-ID: On Wed, November 9, 2016 3:10 am, Graeme Geldenhuys via Lazarus wrote: > On 2016-11-09 05:13, Lars via Lazarus wrote: > >> I find the documentation, for example, for >> Total Commander, to just be a little bit too Windows 3.1 looking. >> > > I'll bet you a 6-pack of beer that the documentation was written by the > developer himself. That would explain the lack of typography. :) > > But it's not just say Ghislers writing style or formatting, but the general look of the old help systems from windows 95 era. i.e. any chm/hlp system appears to be win 3.1 looking, or if not win 3.1, then win 95 looking. As much as I really appreciate simple text documentation with minimal html bloat, I'm thinking more of the professional $250 software app or $99 software app that needs to ship a documentation system that will make people feel satisfied for their dollar. An old win 3.1/win95 style hlp/chm system just seems a bit too cheap. But, I'm nit picking. I do appreciate simple documentation without eye candy crap. From noreply at z505.com Fri Nov 11 01:58:45 2016 From: noreply at z505.com (Lars) Date: Thu, 10 Nov 2016 17:58:45 -0700 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: <20161109145704.GA58088@stack.nl> References: <06e64487-f0c7-94e1-eefd-4ab97bab5f77@freenet.de> <20161109145704.GA58088@stack.nl> Message-ID: On Wed, November 9, 2016 7:57 am, Marco van de Voort via Lazarus wrote: > The frequent updates that often break interfaces are also an headache. > This is what happened to firefox: xul runner's current state is broken/unknown/scary. I hope the same doesn't happen to chromium. Cef1 has some incompatibilities with cef3 but at least not as bad as the firefox embedded xulrunner state of affairs. > If I would replace lhelp and chm, I wouldn't go that way, but some way > with a local webserver (for searching and the like), and just use whatever > is installed. > A local web server as in running on port 80? The issue I see here is what if someone has apache installed already? The advantage of no web server at all is you have no conflicts with port 80 already running an apache instance. But maybe I misinterpreted what you are saying. From noreply at z505.com Fri Nov 11 02:11:46 2016 From: noreply at z505.com (Lars) Date: Thu, 10 Nov 2016 18:11:46 -0700 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: References: <06e64487-f0c7-94e1-eefd-4ab97bab5f77@freenet.de> <20161109145704.GA58088@stack.nl> <20161109160233.2eb4c01d@limapholos.matflo.wg> Message-ID: >>> The best reason to have some local (whatever how limited) widget is >>> for IDE popups of helptext instead of an external browser. External browser requires alt-tabbing away from the ide which is a pain. A external browser cannot be communicated with once you open the html file. with a local widget, you can communicate with that widget. With an external browser, once you've loaded the page there is no way to communicate. An an external browser doesn't offer a search system if it's a static html file served off line. So then you end up with people just using google and online help and stack exchange, instead of reading documentation. My idea with chromium embedded is to write the documentation for an online web server, but then easily port it to offline documentation served with chromium embedded. No local web server needs to be installed on port 80 conflicting with any other servers on the users computer. Html anchors can be used to scroll to certain parts of the documentation. Or if anchors are not enough, there is always javascript. But, my idea of using chromium embedded is sort of a dream ruined. Because of the large 100+MB dependency it pulls in, as pointed out by others (i.e. Graeme said 300MB, maybe that was exaggeration). A local ngnix server or similar could serve documentation (or even nYume or Aservia) however this requires that a port 80 be tied up, or another port alternative to port 80 which may be blocked by firewall. That I would want to avoid, as it's just another hassle. It's amazing someone hasn't thought of a web server that works off line, that uses no ports, and just runs as some kind of plain Exe not using any http port... Not sure if this is an absurd idea (actually, that's kind of what chromium embedded is). From nc-gaertnma at netcologne.de Fri Nov 11 02:26:50 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Fri, 11 Nov 2016 02:26:50 +0100 Subject: [Lazarus] WebAssembly In-Reply-To: <3e35bb04912248b82c3c25cae648fc22.squirrel@gator3286.hostgator.com> References: <342e6a09-9f2b-713c-9b9e-5d9d1340c66f@lumino.de> <20161109115315.3517a3c6@limapholos.matflo.wg> <4c881acd-15d3-4851-31e1-49db9228ab3b@lumino.de> <3e35bb04912248b82c3c25cae648fc22.squirrel@gator3286.hostgator.com> Message-ID: <20161111022650.009b7283@limapholos.matflo.wg> On Thu, 10 Nov 2016 17:40:03 -0700 Lars via Lazarus wrote: >[...] > I thought the idea of web assembly was not to compile to javascript, but > to compile to byte code.. Yes, Javascript compatible bytecode. Keep in mind that the vendors are still experimenting. So it is not yet clear when it will be ready and how the end product will work on the various browsers. Mattias From nc-gaertnma at netcologne.de Fri Nov 11 02:31:26 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Fri, 11 Nov 2016 02:31:26 +0100 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: References: <06e64487-f0c7-94e1-eefd-4ab97bab5f77@freenet.de> <20161109145704.GA58088@stack.nl> <20161109160233.2eb4c01d@limapholos.matflo.wg> Message-ID: <20161111023126.5c8532d1@limapholos.matflo.wg> On Thu, 10 Nov 2016 18:11:46 -0700 Lars via Lazarus wrote: >[...] > It's amazing someone hasn't thought of a web server that works off line, > that uses no ports, and just runs as some kind of plain Exe not using any > http port... Not sure if this is an absurd idea (actually, that's kind of > what chromium embedded is). Do you mean showing HTML pages in a HTML control and handling links without TCP ports? Mattias From mschnell at lumino.de Fri Nov 11 10:19:56 2016 From: mschnell at lumino.de (Michael Schnell) Date: Fri, 11 Nov 2016 10:19:56 +0100 Subject: [Lazarus] WebAssembly In-Reply-To: <20161111022650.009b7283@limapholos.matflo.wg> References: <342e6a09-9f2b-713c-9b9e-5d9d1340c66f@lumino.de> <20161109115315.3517a3c6@limapholos.matflo.wg> <4c881acd-15d3-4851-31e1-49db9228ab3b@lumino.de> <3e35bb04912248b82c3c25cae648fc22.squirrel@gator3286.hostgator.com> <20161111022650.009b7283@limapholos.matflo.wg> Message-ID: On 11.11.2016 02:26, Mattias Gaertner via Lazarus wrote: > So it is not yet clear when it will be ready and > how the end product will work on the various browsers. Mozilla promises "March 2017". Any information on other brands ? I only found "Microsoft says it is close to shipping the browser preview of WebAssembly on Microsoft Edge and ChakraCore" -> https://mspoweruser.com/microsoft-edge-get-webassembly-browser-preview-soon/ -Michael From mschnell at lumino.de Fri Nov 11 10:23:11 2016 From: mschnell at lumino.de (Michael Schnell) Date: Fri, 11 Nov 2016 10:23:11 +0100 Subject: [Lazarus] WebAssembly In-Reply-To: <107fc5004fb746d314b14db30c2425d0.squirrel@gator3286.hostgator.com> References: <342e6a09-9f2b-713c-9b9e-5d9d1340c66f@lumino.de> <107fc5004fb746d314b14db30c2425d0.squirrel@gator3286.hostgator.com> Message-ID: On 11.11.2016 01:33, Lars via Lazarus wrote: > Maybe best to start from scratch. Regarding the Lazarus paradigm "write once, compile and run everywhere", IMHO not a good idea. -Michael From mailinglists at geldenhuys.co.uk Fri Nov 11 11:54:09 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 11 Nov 2016 10:54:09 +0000 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: References: <20161021111331.0846d181@limapholos.matflo.wg> <0690e875-8608-c93d-ce39-f86e7a0bf5e3@geldenhuys.co.uk> <20161021120507.33bf5fdd@limapholos.matflo.wg> <20161022233647.63d1d853@limapholos.matflo.wg> <0ccf92ea-c2ce-8c1d-cec1-bf0777619b41@geldenhuys.co.uk> <720ab092ae799b63946c94c8842c0b6e.squirrel@gator3286.hostgator.com> <9630f8207a8a79038ffa00053b12332d.squirrel@gator3286.hostgator.com> <26d53b2d-48d4-44a1-a9e7-c1176d7df115@geldenhuys.co.uk> Message-ID: <244ab327-e325-8f17-d226-b9f0068e12c0@geldenhuys.co.uk> On 2016-11-11 00:53, Lars via Lazarus wrote: > I do appreciate simple documentation without eye > candy crap. :) Just take a look at Apple's OSX built-in help (not the online content). It is minimalist and mostly text - with a hint of good typography. It works! Microsoft Windows 7 does very similar to Apple - simple and elegant. You don't need some Telly Tubbies color scheme in your help contents (just because HTML allows for it) - it just distracts from the help itself. I've seen many such [terrible] CHM or HTML help in my days. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From mailinglists at geldenhuys.co.uk Fri Nov 11 11:55:24 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 11 Nov 2016 10:55:24 +0000 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: References: <6ae6beeae72d5bd668dbea960664f0d1.squirrel@gator3286.hostgator.com> <635fca1f-c3a8-5f43-6765-0897df679929@geldenhuys.co.uk> <4021a401413264ad02b1f70562dc8cc6.squirrel@gator3286.hostgator.com> <06e71da8-3eab-a3d9-3501-6e2bb8d449c9@geldenhuys.co.uk> Message-ID: <285297b0-10ba-82d0-16f6-aa74cc23b2ad@geldenhuys.co.uk> On 2016-11-11 00:47, Lars via Lazarus wrote: > But, could one compile fpc code to javaapplet jvm bytecode? FPC 3.x can compile to Java Bytecode, but I've never actually tried it myself. Regards, Graeme From mailinglists at geldenhuys.co.uk Fri Nov 11 12:03:58 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 11 Nov 2016 11:03:58 +0000 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: References: <06e64487-f0c7-94e1-eefd-4ab97bab5f77@freenet.de> <20161109145704.GA58088@stack.nl> <20161109160233.2eb4c01d@limapholos.matflo.wg> Message-ID: On 2016-11-11 01:11, Lars via Lazarus wrote: > port alternative to port 80 which may be blocked by firewall. That I would > want to avoid, as it's just another hassle. You can always use any other port >1024 for that. I've implemented a commercial application that works mostly online, but we wanted a offline version too. So I built a local mini webserver inside the main application. The application launched your default web browser with a URL and port number which the main application served. It worked beautifully. But for help, firing up Chrome of Firefox is just too damn slow, and eats way to much memory. Also you will have to implement your own search (which will be slow over HTML files), table of contents and index pages. Then what about other useful features like bookmarking a help topic, inline annotations (user defined notes added to a help topic at runtime). As for communications with a external [dedicated] help viewer. fpGUI's Docview does that via IPC, Microsoft's WinHelp I think could do it too, OS/2 VIEW help viewer did lots of 2-way communications with applications. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From wkitty42 at windstream.net Fri Nov 11 12:37:36 2016 From: wkitty42 at windstream.net (wkitty42 at windstream.net) Date: Fri, 11 Nov 2016 06:37:36 -0500 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: References: <06e64487-f0c7-94e1-eefd-4ab97bab5f77@freenet.de> <20161109145704.GA58088@stack.nl> <20161109160233.2eb4c01d@limapholos.matflo.wg> Message-ID: On 11/10/2016 08:11 PM, Lars via Lazarus wrote: >>>> The best reason to have some local (whatever how limited) widget is >>>> for IDE popups of helptext instead of an external browser. > > External browser requires alt-tabbing away from the ide which is a pain. A > external browser cannot be communicated with once you open the html file. > with a local widget, you can communicate with that widget. With an > external browser, once you've loaded the page there is no way to > communicate. An an external browser doesn't offer a search system if it's > a static html file served off line. So then you end up with people just > using google and online help and stack exchange, instead of reading > documentation. what's wrong with something like LHelp and using IPC to tell it where to load the next help from that the user has asked for?? from these cheap seats i have way over here, it seems like you are over engineering this... -- 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. From noreply at z505.com Fri Nov 11 23:27:09 2016 From: noreply at z505.com (Lars) Date: Fri, 11 Nov 2016 15:27:09 -0700 Subject: [Lazarus] WebAssembly In-Reply-To: References: <342e6a09-9f2b-713c-9b9e-5d9d1340c66f@lumino.de> <107fc5004fb746d314b14db30c2425d0.squirrel@gator3286.hostgator.com> Message-ID: On Fri, November 11, 2016 2:23 am, Michael Schnell via Lazarus wrote: > On 11.11.2016 01:33, Lars via Lazarus wrote: > >> Maybe best to start from scratch. >> > Regarding the Lazarus paradigm "write once, compile and run everywhere", > IMHO not a good idea. The issue is you are working in a sandbox. Lazarus is designed to take control of the computer using all the dangerous things without any sandbox, such as being able to delete and write to pretty much any file you want that has the correct permissions in place. A sandbox is much more specialized to develop for, because you may only be able to access certain directory with limited files.... So you could modify lazarus to work with this sandbox restriction, but, might be easier to design from scratch. ... I understand the desire to just take existing LCL app and port it to the web browser, but that's a pipe dream, because browsers will be in sandboxes that just don't work like client applications on Ms Windows, BSD/Linux. Another option is just to use a separate widget set and see how that works, such as fpGUI widget. But I guess that means you can't as easily take an existing app and port it. From noreply at z505.com Fri Nov 11 23:46:56 2016 From: noreply at z505.com (Lars) Date: Fri, 11 Nov 2016 15:46:56 -0700 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: <244ab327-e325-8f17-d226-b9f0068e12c0@geldenhuys.co.uk> References: <20161021111331.0846d181@limapholos.matflo.wg> <0690e875-8608-c93d-ce39-f86e7a0bf5e3@geldenhuys.co.uk> <20161021120507.33bf5fdd@limapholos.matflo.wg> <20161022233647.63d1d853@limapholos.matflo.wg> <0ccf92ea-c2ce-8c1d-cec1-bf0777619b41@geldenhuys.co.uk> <720ab092ae799b63946c94c8842c0b6e.squirrel@gator3286.hostgator.com> <9630f8207a8a79038ffa00053b12332d.squirrel@gator3286.hostgator.com> <26d53b2d-48d4-44a1-a9e7-c1176d7df115@geldenhuys.co.uk> <244ab327-e325-8f17-d226-b9f0068e12c0@geldenhuys.co.uk> Message-ID: On Fri, November 11, 2016 3:54 am, Graeme Geldenhuys via Lazarus wrote: > On 2016-11-11 00:53, Lars via Lazarus wrote: > >> I do appreciate simple documentation without eye >> candy crap. > > :) Just take a look at Apple's OSX built-in help (not the online > content). It is minimalist and mostly text - with a hint of good > typography. It works! Microsoft Windows 7 does very similar to Apple - > simple and elegant. I've always liked the website delphibasics .co .uk (or whatever the address is). Would the current help systems be even capable of looking like that? Must be just a few div boxes. Really simple, interesting color shades. No fancy garbage, just simple boxes of text. From noreply at z505.com Sat Nov 12 00:09:30 2016 From: noreply at z505.com (Lars) Date: Fri, 11 Nov 2016 16:09:30 -0700 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: References: <06e64487-f0c7-94e1-eefd-4ab97bab5f77@freenet.de> <20161109145704.GA58088@stack.nl> <20161109160233.2eb4c01d@limapholos.matflo.wg> Message-ID: On Fri, November 11, 2016 4:03 am, Graeme Geldenhuys via Lazarus wrote: > On 2016-11-11 01:11, Lars via Lazarus wrote: > >> port alternative to port 80 which may be blocked by firewall. That I >> would want to avoid, as it's just another hassle. > > You can always use any other port >1024 for that. No issues with default firewalls? Last thing I want, is a customer having to futz around with router firewall, windows firewall, etc. .... > But for help, firing up Chrome of Firefox is just too damn slow, and > eats way to much memory. Also you will have to implement your own search > (which will be slow over HTML files), table of contents and index pages. But isn't that what iota full text search is for, to preindex all the search stuff so no time is spent grepping through html files.... The issue with Iota I found was that it was written in an old fpc style where some things are not proper code, but compiled at that state of fpc development. iota, if you don't know, is a full text search indexing library for fpc. Discussed briefly on the fpc mailing lists eons ago. > Then what about other useful features like bookmarking a help topic, > inline annotations (user defined notes added to a help topic at runtime). > User defined notes, were not available in chm files were they? I thought chm/hlp file were just dumb, fixed help files with no bells an whistles. i.e. total commander style help. With a chrome embedded browser object, you can use the DOM to manipulate the document. That's basically how chrome plugins work in the browser where you can modify the html page and add widgets to someone else's site, on your client side. If you wanted to add notes to html help you could use the DOM to do it and store those extra notes in a database, or something. I'd be interested in how many people do this: add notes to their help, inline. We know that people add notes at the end of the documentation, like the php manual where people add comments to the bottom of the page. I didn't realize there were help systems were you could inline some notes? > As for communications with a external [dedicated] help viewer. fpGUI's > Docview does that via IPC, Microsoft's WinHelp I think could do it too, > OS/2 VIEW help viewer did lots of 2-way communications with applications. > > Which is an interesting question: why hasn't firefox allowed IPC from external apps. Could be a security vulnerability. Maybe just one of those interesting features that could be, should be, would be, but no one has thought of implementing. If firefox had IPC you could navigate to an anchor from an external exe. Also an interesting question is why hasn't adobe got something like this so that adobe files could be used as help files: scroll to a certain part of the pdf file programmatically using IPC, or maybe using an adobe embedded object. I find pdf files just a little too slow, though, and not as responsive, due to them being like a resource intensive graphic. So I suppose pdf files ruin the zippy feeling of a fast help system. From mailinglists at geldenhuys.co.uk Sat Nov 12 00:23:10 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 11 Nov 2016 23:23:10 +0000 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: References: <20161021111331.0846d181@limapholos.matflo.wg> <0690e875-8608-c93d-ce39-f86e7a0bf5e3@geldenhuys.co.uk> <20161021120507.33bf5fdd@limapholos.matflo.wg> <20161022233647.63d1d853@limapholos.matflo.wg> <0ccf92ea-c2ce-8c1d-cec1-bf0777619b41@geldenhuys.co.uk> <720ab092ae799b63946c94c8842c0b6e.squirrel@gator3286.hostgator.com> <9630f8207a8a79038ffa00053b12332d.squirrel@gator3286.hostgator.com> <26d53b2d-48d4-44a1-a9e7-c1176d7df115@geldenhuys.co.uk> <244ab327-e325-8f17-d226-b9f0068e12c0@geldenhuys.co.uk> Message-ID: <1da57f83-2691-ef16-b682-a2c6d987a7af@geldenhuys.co.uk> On 2016-11-11 22:46, Lars via Lazarus wrote: > Would the current help systems be even capable of looking like that? Must > be just a few div boxes. Really simple, interesting color shades. No > fancy garbage, just simple boxes of text. I don't know how much CSS the HTML component in LHelp supports. But if you look at the source of that website, they actually use HTML tables to do most of the layouting. Looking at the following page... http://delphibasics.co.uk/RTL.asp?Name=CurrencyString Also Free Pascal's fpdoc already generates all that same information: * summary line (name, one line description and unit name) * declaration * Description * extra notes * example code * See also (related commands) The fpdoc linear output writers (LaTeX, INF etc) formats the above information quite neatly. Then again, I thought we were talking about application help which could take on a whole different layout compared to technical API documentation. As for the color they used. Yes, they are nice pastel colors, but they don't really add much value. If the headers were more prominent (larger and nicer font), then the colored boxes probably wouldn't be needed. By using colour like that, you are also limiting your audience - eg: what about colour blind people? Just take a look at this web page and see what different color vision deficiency can do to the same image. http://www.color-blindness.com/coblis-color-blindness-simulator/ Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From noreply at z505.com Sat Nov 12 00:34:34 2016 From: noreply at z505.com (Lars) Date: Fri, 11 Nov 2016 16:34:34 -0700 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: References: <06e64487-f0c7-94e1-eefd-4ab97bab5f77@freenet.de> <20161109145704.GA58088@stack.nl> <20161109160233.2eb4c01d@limapholos.matflo.wg> Message-ID: <4367b9a22a874ffe2099c4869539f423.squirrel@gator3286.hostgator.com> On Fri, November 11, 2016 4:37 am, wkitty42--- via Lazarus wrote: > what's wrong with something like LHelp and using IPC to tell it where to > load the next help from that the user has asked for?? > I'll have to experiment with LHelp, thanks > from these cheap seats i have way over here, it seems like you are over > engineering this... > Anyone who pulls in a 150MB-300MB chromium embedded plugin is likely over engineering (not to mention bloatware). I'm critical of my own original post. Would be much better if there was a chromium lite version that you could embed which was only 2MB or 1MB. One plan I had was to simply port an existing html documentation system that runs on a cgi program on a server, over to offline help, with minimal effort. Chromium embedded seemed the way to go because you can literally trick chromium embedded into being a cgi like device, on the client side, without any web server. Whether LHelp can do that, is something I'd have to research. I have some existing projects where the help system is already in place, on a server, and I don't much feel like writing two sets of help systems one that works offline and one that works online, I'd rather just have one system that works online and offline. So I figured CEF3 or CEF1 would be a way to make already existing online documentation, work offline too. From noreply at z505.com Sat Nov 12 00:39:42 2016 From: noreply at z505.com (Lars) Date: Fri, 11 Nov 2016 16:39:42 -0700 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: <1da57f83-2691-ef16-b682-a2c6d987a7af@geldenhuys.co.uk> References: <0690e875-8608-c93d-ce39-f86e7a0bf5e3@geldenhuys.co.uk> <20161021120507.33bf5fdd@limapholos.matflo.wg> <20161022233647.63d1d853@limapholos.matflo.wg> <0ccf92ea-c2ce-8c1d-cec1-bf0777619b41@geldenhuys.co.uk> <720ab092ae799b63946c94c8842c0b6e.squirrel@gator3286.hostgator.com> <9630f8207a8a79038ffa00053b12332d.squirrel@gator3286.hostgator.com> <26d53b2d-48d4-44a1-a9e7-c1176d7df115@geldenhuys.co.uk> <244ab327-e325-8f17-d226-b9f0068e12c0@geldenhuys.co.uk> <1da57f83-2691-ef16-b682-a2c6d987a7af@geldenhuys.co.uk> Message-ID: <57b8b29a98e48dd7c74e8d7c66d82d0e.squirrel@gator3286.hostgator.com> On Fri, November 11, 2016 4:23 pm, Graeme Geldenhuys via Lazarus wrote: > On 2016-11-11 22:46, Lars via Lazarus wrote: > >> Would the current help systems be even capable of looking like that? >> Must >> be just a few div boxes. Really simple, interesting color shades. No >> fancy garbage, just simple boxes of text. > > I don't know how much CSS the HTML component in LHelp supports. But if > you look at the source of that website, they actually use HTML tables Holy batman, they are using tables? Wow.. I was sure it was a Div box based website but they are using classic tables. Interesting. > By using colour like that, you are also limiting your audience - eg: > what about colour blind people? Would be interesting if there was a firefox/chrome plugin that converted a website to be all black and white to help people, or maybe grayscale. But good point. From mailinglists at geldenhuys.co.uk Sat Nov 12 00:52:21 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 11 Nov 2016 23:52:21 +0000 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: References: <06e64487-f0c7-94e1-eefd-4ab97bab5f77@freenet.de> <20161109145704.GA58088@stack.nl> <20161109160233.2eb4c01d@limapholos.matflo.wg> Message-ID: <255f6c45-fe65-0c06-22d3-b0c622828b25@geldenhuys.co.uk> On 2016-11-11 23:09, Lars via Lazarus wrote: >> You can always use any other port >1024 for that. > > No issues with default firewalls? Last thing I want, is a customer having > to futz around with router firewall, windows firewall, etc. It was 4 years ago, but as far as I remember, we didn't have any firewall issues on Windows. > But isn't that what iota full text search is for, to preindex all the > search stuff so no time is spent grepping through html files.... Yeah, but deployment is going to be a pain isn't it? I know of iota, but I don't know how it works. I would imagine it needs to run continuously in the background? ps: I believe the is a FTS indexer as part of FCL as well. Though I think it was written for databases, not for HTML files. > User defined notes, were not available in chm files were they? I thought > chm/hlp file were just dumb, fixed help files with no bells an whistles. Now there's an interesting question. :) WinHelp supported both Annotations and Bookmarks, though the annotations were not inline - it simply showed a paperclip icon or something that you had to click to see the user defined notes, and was limited to one note per help topic. Window's CHM viewer only support bookmarks (they call it Favourites). So it actually has less features than WinHelp did. :) DocView supports inline annotations, bookmarks, full text search, advanced search terms (eg: search for this but don't include that, search by phrase, or fine something spelled similar to search term you entered). Docview also allows multiple annotations per help topic. The Bookmarks, Annotations and Advanced Search features are not part of the INF file format, docview implements those. Full Text Search comes standard with INF though - any word in the whole INF file is only stored once (all others are simply pointers to the word lookup table). This is also why INF is so compact (eg: one help file will be 3MB in INF, but that same help content will be a 12MB CHM file) On a side note: I use Docview's annotations support a lot! My Free Pascal RTL and FCL help is full of my own comments, code examples etc. I also use it to note down errors in the help (eg: spelling mistakes, grammar, examples) and then later when I have time, report those on Mantis as they are then easy to find again. > I didn't realize there were help systems were you could inline some notes? Take a look here: http://fpgui.sourceforge.net/screenshots_apps.shtml In the first screenshot, note all the green text. They are inline annotation examples. You can simply click them to edit them too. The yellow text is the highlighted search terms it found in that page. Both colors are user configurable, and so too is the font and page background color. In the "Search Results" list box, the numbers behind the help topics are a search rating value. The higher the value, the more precise the search result was (eg: the search term appeared more than once in that help topic). Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From mailinglists at geldenhuys.co.uk Sat Nov 12 00:56:55 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 11 Nov 2016 23:56:55 +0000 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: <57b8b29a98e48dd7c74e8d7c66d82d0e.squirrel@gator3286.hostgator.com> References: <20161021120507.33bf5fdd@limapholos.matflo.wg> <20161022233647.63d1d853@limapholos.matflo.wg> <0ccf92ea-c2ce-8c1d-cec1-bf0777619b41@geldenhuys.co.uk> <720ab092ae799b63946c94c8842c0b6e.squirrel@gator3286.hostgator.com> <9630f8207a8a79038ffa00053b12332d.squirrel@gator3286.hostgator.com> <26d53b2d-48d4-44a1-a9e7-c1176d7df115@geldenhuys.co.uk> <244ab327-e325-8f17-d226-b9f0068e12c0@geldenhuys.co.uk> <1da57f83-2691-ef16-b682-a2c6d987a7af@geldenhuys.co.uk> <57b8b29a98e48dd7c74e8d7c66d82d0e.squirrel@gator3286.hostgator.com> Message-ID: On 2016-11-11 23:39, Lars via Lazarus wrote: > Would be interesting if there was a firefox/chrome plugin that converted a > website to be all black and white to help people, or maybe grayscale. But > good point. Opera 12.x (and earlier) had that built in. Newer versions of Opera (based on Chrome) doesn't support that any more - and neither does Chrome or Firefox. Regards, Graeme From marcov at stack.nl Sun Nov 13 00:07:50 2016 From: marcov at stack.nl (Marco van de Voort) Date: Sun, 13 Nov 2016 00:07:50 +0100 Subject: [Lazarus] Help System with Chromium Embedded component In-Reply-To: References: <06e64487-f0c7-94e1-eefd-4ab97bab5f77@freenet.de> Message-ID: <20161112230750.GA42668@stack.nl> On Tue, Nov 08, 2016 at 09:48:31PM -0700, Lars via Lazarus wrote: > > Well the reason chromium is in my line of sight, is because other people > do the work to maintain the browser for you. Creating your own web > browser component is massive amounts of work, whereas chromium is coded by > other people. True you have to write wrappers around it, but you also end > up with a standard component where there are already plenty of c++ > examples to learn from, and you are supported by a massive team over at > chromium. Whereas writing your own browser component requires constantly > playing "catch up", implementing every feature needed which chromium had 5 > years ago. In the earlier reply I missed the most crucial part. There is /NO/ catchup. We are not developing a browser. Just something that can display the HTML subset that we generate cq support. From michael at freepascal.org Sun Nov 13 19:52:54 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Sun, 13 Nov 2016 19:52:54 +0100 (CET) Subject: [Lazarus] Modal windows on Cocoa Message-ID: Hi, I am not sure whether this is a bug of the cocoa widgetset, or whether this is a general limitation of the Mac. Imagine a main form, which shows a modal form. The modal form shows a message dialog (ShowMessage or MessageDlg, it makes no difference). This works perfectly on Linux and Windows. If you do this on a Mac, then the program hangs: there is no way to press the OK button in the message dialog. Is this a limitation of the Mac ? I have never seen a Mac program do this kind of thing, so I could imagine that this is a limitation, but admittedly my experience on the Mac is not as big as on PC... I made a small sample program to demonstrate the issue: http://www.freepascal.org/~michael/modalbug.zip If this is supposed to work, and it's actually a bug in the cocoa widgetset I will post it to the bugtracker. Michael. From zeljko at holobit.net Sun Nov 13 20:22:10 2016 From: zeljko at holobit.net (zeljko) Date: Sun, 13 Nov 2016 20:22:10 +0100 Subject: [Lazarus] {Spam?} Re: Modal windows on Cocoa In-Reply-To: References: Message-ID: <5f2e2da6-ac30-fe0f-22d9-2d7702c01b73@holobit.net> On 13.11.2016 19:52, Michael Van Canneyt via Lazarus wrote: > > Hi, > > I am not sure whether this is a bug of the cocoa widgetset, or whether this > is a general limitation of the Mac. > > Imagine a main form, which shows a modal form. The modal form shows a > message dialog (ShowMessage or MessageDlg, it makes no difference). > > This works perfectly on Linux and Windows. > > If you do this on a Mac, then the program hangs: there is no way to press > the OK button in the message dialog. > > Is this a limitation of the Mac ? I have never seen a Mac program do > this kind of thing, so I could imagine > that this is a limitation, but admittedly my experience on the Mac is > not as big as on PC... I'm still using Qt-4.8.6 (QtCarbon 32bit) for production under mac and it does not have single problem with such windows, also tested with Qt-5.6.2 (QtCocoa 64bit) and there it works correct too, so doesn't look like limitation :) zeljko From lazarus at kluug.net Sun Nov 13 21:37:50 2016 From: lazarus at kluug.net (Ondrej Pokorny) Date: Sun, 13 Nov 2016 21:37:50 +0100 Subject: [Lazarus] TPageControl OnChange calling issue In-Reply-To: <4c2aaa88-6c76-f8a4-a963-98dcd001d332@lumino.de> References: <6dd35aa2-24e5-0eee-f02e-ca8feeff84a9@gmx.de> <4c2aaa88-6c76-f8a4-a963-98dcd001d332@lumino.de> Message-ID: <13980c6d-d846-9e0b-2135-b4b110521b58@kluug.net> On 05.10.2016 14:07, Michael Schnell via Lazarus wrote: > > > On 05.10.2016 12:40, Ondrej Pokorny via Lazarus wrote: >> >> I am against. LCL is designed to be Delphi-compatible so the default >> events are what they are and they behave how they behave. > This of course is granted by a property that is not existing in Delphi > and defaults to the Delphi behavior. Unfortunately this will probably be impossible to make for all LCL-controls systematically. But we can make it for TPageControl - add a new option nboDelphiOnChange (or whatever) that defaults to Delphi OnChange behavior. If not set it will be the old OnChange behavior. Or they other way round: nboOldOnChange? Or do you have any other name suggestions? I am pretty bad at this :) Such an option will make updating legacy code easier. + Bart: what do you think? Ondrej From bartjunk64 at gmail.com Sun Nov 13 22:24:46 2016 From: bartjunk64 at gmail.com (Bart) Date: Sun, 13 Nov 2016 22:24:46 +0100 Subject: [Lazarus] TPageControl OnChange calling issue In-Reply-To: <13980c6d-d846-9e0b-2135-b4b110521b58@kluug.net> References: <6dd35aa2-24e5-0eee-f02e-ca8feeff84a9@gmx.de> <4c2aaa88-6c76-f8a4-a963-98dcd001d332@lumino.de> <13980c6d-d846-9e0b-2135-b4b110521b58@kluug.net> Message-ID: On 11/13/16, Ondrej Pokorny via Lazarus wrote: > Unfortunately this will probably be impossible to make for all > LCL-controls systematically. But we can make it for TPageControl - add a > new option nboDelphiOnChange (or whatever) that defaults to Delphi > OnChange behavior. If not set it will be the old OnChange behavior. Or > they other way round: nboOldOnChange? > > Or do you have any other name suggestions? I am pretty bad at this :) > Such an option will make updating legacy code easier. > + Bart: what do you think? AFAICS Delphi does not have TPageControl.Options, so since this is already not Delphi compatible, I don't mind if we add such an option. Others? Bart From larrydalton71 at gmail.com Mon Nov 14 06:04:38 2016 From: larrydalton71 at gmail.com (Larry Dalton) Date: Sun, 13 Nov 2016 23:04:38 -0600 Subject: [Lazarus] Open Office dbase Message-ID: <5C42CB16-9CD8-4A91-8B19-05DD511CD6AD@gmail.com> I have an application that creates dbase files and writes information to them. I now need a procedure that will open the newly filled table so that it can be manually edited and printed. Some of the users are on Linux and some on Windows 7 and later. A couple of them are using Excel on the Windows boxes while the rest are using OpenOffice Libre. What is the best way to open those applications to the newly created tables with Lazarus? Sent from my iPhone -------------- next part -------------- An HTML attachment was scrubbed... URL: From lacak at zoznam.sk Mon Nov 14 07:16:03 2016 From: lacak at zoznam.sk (LacaK) Date: Mon, 14 Nov 2016 07:16:03 +0100 Subject: [Lazarus] Open Office dbase In-Reply-To: <5C42CB16-9CD8-4A91-8B19-05DD511CD6AD@gmail.com> References: <5C42CB16-9CD8-4A91-8B19-05DD511CD6AD@gmail.com> Message-ID: <2ffcbf76-8a75-014c-3526-415396179a00@zoznam.sk> You can use TDBF component or TODBCConnection (from FCL DB) with dBase or FoxPro driver (I do not known if exists for Linux) -Laco. > > I have an application that creates dbase files and writes information > to them. I now need a procedure that will open the newly filled table > so that it can be manually edited and printed. Some of the users are > on Linux and some on Windows 7 and later. A couple of them are using > Excel on the Windows boxes while the rest are using OpenOffice Libre. > What is the best way to open those applications to the newly created > tables with Lazarus? > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at freepascal.org Mon Nov 14 08:11:25 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 14 Nov 2016 08:11:25 +0100 (CET) Subject: [Lazarus] {Spam?} Re: Modal windows on Cocoa In-Reply-To: <5f2e2da6-ac30-fe0f-22d9-2d7702c01b73@holobit.net> References: <5f2e2da6-ac30-fe0f-22d9-2d7702c01b73@holobit.net> Message-ID: On Sun, 13 Nov 2016, zeljko wrote: > On 13.11.2016 19:52, Michael Van Canneyt via Lazarus wrote: >> >> Hi, >> >> I am not sure whether this is a bug of the cocoa widgetset, or whether this >> is a general limitation of the Mac. >> >> Imagine a main form, which shows a modal form. The modal form shows a >> message dialog (ShowMessage or MessageDlg, it makes no difference). >> >> This works perfectly on Linux and Windows. >> >> If you do this on a Mac, then the program hangs: there is no way to press >> the OK button in the message dialog. >> >> Is this a limitation of the Mac ? I have never seen a Mac program do >> this kind of thing, so I could imagine >> that this is a limitation, but admittedly my experience on the Mac is >> not as big as on PC... > > I'm still using Qt-4.8.6 (QtCarbon 32bit) for production under mac and it > does not have single problem with such windows, also tested with Qt-5.6.2 > (QtCocoa 64bit) and there it works correct too, so doesn't look like > limitation :) I didn't know that Qt could be used for mac. It made me realize that I assumed I was using Cocoa, so I checked, and it turns out it is Carbon, not cocoa :/ When I tried to change it, the IDE sends me to 'Additions and overrides' But when I press 'Set LCLWidgetType', nothing visible happens, and the IDE becomes unresponsive. (Presumably some dropdown list is hidden behind the modal project options dialog...) I need to switch to another application and back to the IDE, then it becomes responsive again. Since the IDE is built using Carbon, it seems safe to assume there is a bug in the Carbon widgetset. Michael. From lazarus at kluug.net Mon Nov 14 08:13:25 2016 From: lazarus at kluug.net (Ondrej Pokorny) Date: Mon, 14 Nov 2016 08:13:25 +0100 Subject: [Lazarus] {Spam?} Re: Modal windows on Cocoa In-Reply-To: References: <5f2e2da6-ac30-fe0f-22d9-2d7702c01b73@holobit.net> Message-ID: On 14.11.2016 8:11, Michael Van Canneyt via Lazarus wrote: > When I tried to change it, the IDE sends me to 'Additions and overrides' > But when I press 'Set LCLWidgetType', nothing visible happens, and the > IDE becomes unresponsive. (Presumably some dropdown list is hidden behind > the modal project options dialog...) > > I need to switch to another application and back to the IDE, then it > becomes > responsive again. Since the IDE is built using Carbon, it seems safe to > assume there is a bug in the Carbon widgetset. This is a bug in 1.6.0. It's been already fixed so wait for 1.6.2 or use 1.6 fixes branch. I assume the modal problem is the same bug as well. Ondrej From michael at freepascal.org Mon Nov 14 08:18:24 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 14 Nov 2016 08:18:24 +0100 (CET) Subject: [Lazarus] {Spam?} Re: Modal windows on Cocoa In-Reply-To: References: <5f2e2da6-ac30-fe0f-22d9-2d7702c01b73@holobit.net> Message-ID: On Mon, 14 Nov 2016, Ondrej Pokorny via Lazarus wrote: > On 14.11.2016 8:11, Michael Van Canneyt via Lazarus wrote: >> When I tried to change it, the IDE sends me to 'Additions and overrides' >> But when I press 'Set LCLWidgetType', nothing visible happens, and the >> IDE becomes unresponsive. (Presumably some dropdown list is hidden behind >> the modal project options dialog...) >> >> I need to switch to another application and back to the IDE, then it >> becomes >> responsive again. Since the IDE is built using Carbon, it seems safe to >> assume there is a bug in the Carbon widgetset. > > This is a bug in 1.6.0. It's been already fixed so wait for 1.6.2 or use > 1.6 fixes branch. I assume the modal problem is the same bug as well. Good news. When is 1.6.2 expected ? Michael. From zeljko at holobit.net Mon Nov 14 08:47:49 2016 From: zeljko at holobit.net (zeljko) Date: Mon, 14 Nov 2016 08:47:49 +0100 Subject: [Lazarus] TPageControl OnChange calling issue In-Reply-To: References: <6dd35aa2-24e5-0eee-f02e-ca8feeff84a9@gmx.de> <4c2aaa88-6c76-f8a4-a963-98dcd001d332@lumino.de> <13980c6d-d846-9e0b-2135-b4b110521b58@kluug.net> Message-ID: <6ec753e1-5b90-ab50-6852-ba9bc08a54a7@holobit.net> On 13.11.2016 22:24, Bart via Lazarus wrote: > On 11/13/16, Ondrej Pokorny via Lazarus wrote: > > >> Unfortunately this will probably be impossible to make for all >> LCL-controls systematically. But we can make it for TPageControl - add a >> new option nboDelphiOnChange (or whatever) that defaults to Delphi >> OnChange behavior. If not set it will be the old OnChange behavior. Or >> they other way round: nboOldOnChange? >> >> Or do you have any other name suggestions? I am pretty bad at this :) >> Such an option will make updating legacy code easier. >> + Bart: what do you think? > > > AFAICS Delphi does not have TPageControl.Options, so since this is > already not Delphi compatible, I don't mind if we add such an option. > > Others? nboLazarusOnChange :) +1 zeljko > > Bart > From lazarus at kluug.net Mon Nov 14 09:01:03 2016 From: lazarus at kluug.net (Ondrej Pokorny) Date: Mon, 14 Nov 2016 09:01:03 +0100 Subject: [Lazarus] {Spam?} Re: Modal windows on Cocoa In-Reply-To: References: <5f2e2da6-ac30-fe0f-22d9-2d7702c01b73@holobit.net> Message-ID: On 14.11.2016 8:18, Michael Van Canneyt via Lazarus wrote: > Good news. When is 1.6.2 expected ? It's been already tagged so expect it soon. 1.6.2 took so long because we waited for FPC 3.0.2. Ondrej From nc-gaertnma at netcologne.de Mon Nov 14 10:10:52 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Mon, 14 Nov 2016 10:10:52 +0100 Subject: [Lazarus] {Spam?} Re: Modal windows on Cocoa In-Reply-To: References: <5f2e2da6-ac30-fe0f-22d9-2d7702c01b73@holobit.net> Message-ID: <20161114101052.1415f0ba@limapholos.matflo.wg> On Mon, 14 Nov 2016 09:01:03 +0100 Ondrej Pokorny via Lazarus wrote: > On 14.11.2016 8:18, Michael Van Canneyt via Lazarus wrote: > > Good news. When is 1.6.2 expected ? > > It's been already tagged so expect it soon. 1.6.2 took so long because > we waited for FPC 3.0.2. And stopped waiting and use 3.0.0 for 1.6.2. Mattias From mschnell at lumino.de Mon Nov 14 11:26:13 2016 From: mschnell at lumino.de (Michael Schnell) Date: Mon, 14 Nov 2016 11:26:13 +0100 Subject: [Lazarus] WebAssembly In-Reply-To: References: <342e6a09-9f2b-713c-9b9e-5d9d1340c66f@lumino.de> <107fc5004fb746d314b14db30c2425d0.squirrel@gator3286.hostgator.com> Message-ID: <3aee1a07-bd8a-d8d9-9050-0e21318ad828@lumino.de> On 11.11.2016 23:27, Lars via Lazarus wrote: > > I understand the desire to just take existing LCL app and port it to the > web browser, but that's a pipe dream, because browsers will be in > sandboxes that just don't work like client applications on Ms Windows, > BSD/Linux. Not really. Of course it's obvious that stuff like file access can't be done in the virtual machine (or maybe it only can be done if the browser's parameters are set to allow to do so, which supposedly normally is not given). The real (pipe) dream is a behavior similar to the "pipe dream" Silverlight promised for C#: Take a C# application that can run on a desktop (or any mobile device) and add certain definitions to the project (source code and/or project settings) and with this split the application in a part that runs on the server (behind the Web Server) and another part that runs in the browser. The communication between the parts is done automatically by the infrastructure. Here file access etc (usually) will be desired at the server site and not in the "sandbox". Of course this is a far goal, but a more manual way, having the programmer move the "browser" part in it's own units compilable to WebAssmbly and runnable in the "Sandbox", and to add code to call the communication functionality would be a decent step. > Another option is just to use a separate widget set and see how that > works, such as fpGUI widget. But I guess that means you can't as easily > take an existing app and port it. Of course this would be a decent *additional* option (as FireMonkey is with Delphi XE), but the "Lazarus" way would be to allow the user to go on using the GUI builder (s)he is trained to use in the best possible way. I just found that Lazarus now shows "Restriction" notes for all element used in the GUI builder to take account for different possible targets (WidgetTypes). Once this feature is decently supported a check for "sandbox-runability" can be provided. -Michael From mschnell at lumino.de Mon Nov 14 11:39:47 2016 From: mschnell at lumino.de (Michael Schnell) Date: Mon, 14 Nov 2016 11:39:47 +0100 Subject: [Lazarus] TPageControl OnChange calling issue In-Reply-To: <13980c6d-d846-9e0b-2135-b4b110521b58@kluug.net> References: <6dd35aa2-24e5-0eee-f02e-ca8feeff84a9@gmx.de> <4c2aaa88-6c76-f8a4-a963-98dcd001d332@lumino.de> <13980c6d-d846-9e0b-2135-b4b110521b58@kluug.net> Message-ID: <29741c31-96af-d911-c4cd-f628036deac3@lumino.de> On 13.11.2016 21:37, Ondrej Pokorny via Lazarus wrote: > On 05.10.2016 14:07, Michael Schnell via Lazarus wrote: > If not set it will be the old OnChange behavior. Or they other way > round: nboOldOnChange? > > Or do you have any other name suggestions? I suppose it will not be a Boolean but the user can select (two) options with "speaking" names describing the technical effect ... -Michael From lazarus at kluug.net Mon Nov 14 14:46:43 2016 From: lazarus at kluug.net (Ondrej Pokorny) Date: Mon, 14 Nov 2016 14:46:43 +0100 Subject: [Lazarus] TPageControl OnChange calling issue In-Reply-To: <29741c31-96af-d911-c4cd-f628036deac3@lumino.de> References: <6dd35aa2-24e5-0eee-f02e-ca8feeff84a9@gmx.de> <4c2aaa88-6c76-f8a4-a963-98dcd001d332@lumino.de> <13980c6d-d846-9e0b-2135-b4b110521b58@kluug.net> <29741c31-96af-d911-c4cd-f628036deac3@lumino.de> Message-ID: On 14.11.2016 11:39, Michael Schnell via Lazarus wrote: > On 13.11.2016 21:37, Ondrej Pokorny via Lazarus wrote: >> On 05.10.2016 14:07, Michael Schnell via Lazarus wrote: >> If not set it will be the old OnChange behavior. Or they other way >> round: nboOldOnChange? >> >> Or do you have any other name suggestions? > I suppose it will not be a Boolean but the user can select (two) > options with "speaking" names describing the technical effect ... I don't want to make a separate property for this but create a new enum value for the Options property. IMO it shouldn't be a problem if it is documented. Ondrej From zeljko at holobit.net Mon Nov 14 15:08:49 2016 From: zeljko at holobit.net (zeljko) Date: Mon, 14 Nov 2016 15:08:49 +0100 Subject: [Lazarus] TPageControl OnChange calling issue In-Reply-To: References: <6dd35aa2-24e5-0eee-f02e-ca8feeff84a9@gmx.de> <4c2aaa88-6c76-f8a4-a963-98dcd001d332@lumino.de> <13980c6d-d846-9e0b-2135-b4b110521b58@kluug.net> <29741c31-96af-d911-c4cd-f628036deac3@lumino.de> Message-ID: <43328498-1adc-f07e-988b-287751aa2006@holobit.net> On 14.11.2016 14:46, Ondrej Pokorny via Lazarus wrote: > On 14.11.2016 11:39, Michael Schnell via Lazarus wrote: >> On 13.11.2016 21:37, Ondrej Pokorny via Lazarus wrote: >>> On 05.10.2016 14:07, Michael Schnell via Lazarus wrote: >>> If not set it will be the old OnChange behavior. Or they other way >>> round: nboOldOnChange? >>> >>> Or do you have any other name suggestions? >> I suppose it will not be a Boolean but the user can select (two) >> options with "speaking" names describing the technical effect ... > > I don't want to make a separate property for this but create a new enum > value for the Options property. IMO it shouldn't be a problem if it is > documented. +1 for new Options property instead of separate property. zeljko From lazarus at kluug.net Mon Nov 14 15:32:07 2016 From: lazarus at kluug.net (Ondrej Pokorny) Date: Mon, 14 Nov 2016 15:32:07 +0100 Subject: [Lazarus] TextHint rewrite Message-ID: <43ab1ee1-a33c-310e-2e55-4b61a1ab3290@kluug.net> Let me continue the "Memo.Lines.Add seems to be slow with Lazarus 1.6" - TextHint discussion: 1.) Unfortunately it's not possible to create the custom paint event "PaintAfterInterface" for all TWinControls on Win32. So it doesn't make sense to implement it. 2.) Some of Lazarus developers don't want to delete the TextHint emulation. -> For now I rewrote the TextHint emulation a little bit. I hope it's better since I at least decoupled the properties from the emulation. Ondrej From bartjunk64 at gmail.com Mon Nov 14 19:25:45 2016 From: bartjunk64 at gmail.com (Bart) Date: Mon, 14 Nov 2016 19:25:45 +0100 Subject: [Lazarus] TextHint rewrite In-Reply-To: <43ab1ee1-a33c-310e-2e55-4b61a1ab3290@kluug.net> References: <43ab1ee1-a33c-310e-2e55-4b61a1ab3290@kluug.net> Message-ID: On 11/14/16, Ondrej Pokorny via Lazarus wrote: > 1.) Unfortunately it's not possible to create the custom paint event > "PaintAfterInterface" for all TWinControls on Win32. So it doesn't make > sense to implement it. > 2.) Some of Lazarus developers don't want to delete the TextHint emulation. > > -> For now I rewrote the TextHint emulation a little bit. I hope it's > better since I at least decoupled the properties from the emulation. The good news is that GTK 3.2 also supports such a thing natively, which means that maybe we can move this to widgetset code in the future. Bart From m-w-vogel at gmx.de Mon Nov 14 20:37:12 2016 From: m-w-vogel at gmx.de (Michael W. Vogel) Date: Mon, 14 Nov 2016 20:37:12 +0100 Subject: [Lazarus] TPageControl OnChange calling issue In-Reply-To: <43328498-1adc-f07e-988b-287751aa2006@holobit.net> References: <6dd35aa2-24e5-0eee-f02e-ca8feeff84a9@gmx.de> <4c2aaa88-6c76-f8a4-a963-98dcd001d332@lumino.de> <13980c6d-d846-9e0b-2135-b4b110521b58@kluug.net> <29741c31-96af-d911-c4cd-f628036deac3@lumino.de> <43328498-1adc-f07e-988b-287751aa2006@holobit.net> Message-ID: <0d13e7c4-86a5-3ae2-8e84-c59b73f22871@gmx.de> Am 14.11.2016 um 15:08 schrieb zeljko via Lazarus: > +1 for new Options property instead of separate property. > > zeljko +1 Michl From lazarus at kluug.net Tue Nov 15 07:41:23 2016 From: lazarus at kluug.net (Ondrej Pokorny) Date: Tue, 15 Nov 2016 07:41:23 +0100 Subject: [Lazarus] TPageControl OnChange calling issue In-Reply-To: <0d13e7c4-86a5-3ae2-8e84-c59b73f22871@gmx.de> References: <6dd35aa2-24e5-0eee-f02e-ca8feeff84a9@gmx.de> <4c2aaa88-6c76-f8a4-a963-98dcd001d332@lumino.de> <13980c6d-d846-9e0b-2135-b4b110521b58@kluug.net> <29741c31-96af-d911-c4cd-f628036deac3@lumino.de> <43328498-1adc-f07e-988b-287751aa2006@holobit.net> <0d13e7c4-86a5-3ae2-8e84-c59b73f22871@gmx.de> Message-ID: Then there's the problem with what behavior should be default. If we say LCL is VCL compatible then it is clear, but the more I think about it the more I feel Delphi behavior is just strange. Probably thinking is not appropriate here... The same problem is with TComboBox Style=csDropDownList. If ItemIndex is changed from code, OnChange is not fired. Now LCL is VCL compatible but it's the same case. Unfortunately TComboBox doesn't have an Options property. Ondrej From mschnell at lumino.de Tue Nov 15 11:09:17 2016 From: mschnell at lumino.de (Michael Schnell) Date: Tue, 15 Nov 2016 11:09:17 +0100 Subject: [Lazarus] TPageControl OnChange calling issue In-Reply-To: References: <6dd35aa2-24e5-0eee-f02e-ca8feeff84a9@gmx.de> <4c2aaa88-6c76-f8a4-a963-98dcd001d332@lumino.de> <13980c6d-d846-9e0b-2135-b4b110521b58@kluug.net> <29741c31-96af-d911-c4cd-f628036deac3@lumino.de> <43328498-1adc-f07e-988b-287751aa2006@holobit.net> <0d13e7c4-86a5-3ae2-8e84-c59b73f22871@gmx.de> Message-ID: On 15.11.2016 07:41, Ondrej Pokorny via Lazarus wrote: > Then there's the problem with what behavior should be default. That supposedly can easily be defined by the general "mode" setting. -Michael From gaborboros at yahoo.com Tue Nov 15 15:11:26 2016 From: gaborboros at yahoo.com (Gabor Boros) Date: Tue, 15 Nov 2016 15:11:26 +0100 Subject: [Lazarus] How to utilize goRowMoving with TDBGird? Message-ID: <62f66d7f-e3cc-84a6-6c14-47690deb0789@yahoo.com> Hi All, I need a record reordering feature with TDBGrid, worked out a half-solution with drag and drop and later found TStringGrid have a goRowMoving option. Just want the effect of it and the FromIndex and ToIndex row numbers. And TCustomDBGrid.ColRowMoved(IsColumn: Boolean; FromIndex, ToIndex: Integer) exists. Any easy way to access this feature from a DBGrid? Gabor From nc-gaertnma at netcologne.de Tue Nov 15 15:42:06 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Tue, 15 Nov 2016 15:42:06 +0100 Subject: [Lazarus] Lazarus Release 1.6.2 Message-ID: <20161115154206.25fd71bc@limapholos.matflo.wg> The Lazarus team is glad to announce the release of Lazarus 1.6.2. This is a bugfix release. This release was built with FPC 3.0.0. The previous release Lazarus 1.6 was built with FPC 3.0.0 too. Here is the list of fixes for Lazarus 1.6.x: http://wiki.freepascal.org/Lazarus_1.6_fixes_branch Here is the list of changes for Lazarus and Free Pascal: http://wiki.lazarus.freepascal.org/Lazarus_1.6.0_release_notes http://wiki.lazarus.freepascal.org/User_Changes_3.0.0 The release is available for download on SourceForge: http://sourceforge.net/projects/lazarus/files/ Choose your CPU, OS, distro and then the "Lazarus 1.6.2" directory. Checksums for the SourceForge files: http://www.lazarus-ide.org/index.php?page=checksums#1_6_2 Minimum requirements: Windows: 98, 2k, XP, Vista, 7, 8, 8.1 and 10, 32 or 64bit. Win98 and WinNT IDE needs FPC 2.6.4 and building with flag -dWIN9XPLATFORM. FreeBSD/Linux: gtk 2.8 or qt4.5, 32 or 64bit. Mac OS X: 10.5 to 10.11, LCL only 32bit, non LCL apps can be 64bit. The svn tag is http://svn.freepascal.org/svn/lazarus/tags/lazarus_1_6_2 For people who are blocked by SF, the Lazarus releases from SourceForge are mirrored at: ftp://freepascal.dfmk.hu/pub/lazarus/releases/ and later at (after some time for synchronization) http://michael-ep3.physik.uni-halle.de/Lazarus/releases/ and http://mirrors.iwi.me/lazarus/ Mattias From laz at vgdata.dk Tue Nov 15 16:37:32 2016 From: laz at vgdata.dk (Kaj Mikkelsen) Date: Tue, 15 Nov 2016 16:37:32 +0100 Subject: [Lazarus] fpConnect Message-ID: <49a297c3-7b99-fd8c-74a8-3201f55bc8a5@vgdata.dk> Hi I need a method to tell whether a specific port is open on a remote host. Ihave written a function for it, but it seems that fpConnect always returns 0. What am I missing? /Kaj Function TMainForm.OpenPort( IP:String;Port:Integer): Boolean; Var Sock: LongInt; IPAddr: sockaddr; begin sock := fpsocket(AF_INET, SOCK_DGRAM, 0); IPAddr.sin_family := AF_INET; IPAddr.sin_addr.s_addr := StrToHostAddr(IP).s_addr; IPAddr.sin_port := htons(port); if (fpConnect(sock, at IPAddr,SizeOf(IPAddr)) = 0) then Begin Result := True; CloseSocket(sock); End Else Begin Result := False; end; end; From nc-gaertnma at netcologne.de Tue Nov 15 16:52:05 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Tue, 15 Nov 2016 16:52:05 +0100 Subject: [Lazarus] fpConnect In-Reply-To: <49a297c3-7b99-fd8c-74a8-3201f55bc8a5@vgdata.dk> References: <49a297c3-7b99-fd8c-74a8-3201f55bc8a5@vgdata.dk> Message-ID: <20161115165205.366a2da4@limapholos.matflo.wg> On Tue, 15 Nov 2016 16:37:32 +0100 Kaj Mikkelsen via Lazarus wrote: > Hi > > I need a method to tell whether a specific port is open on a remote host. Please define "open". Mattias From laz at vgdata.dk Tue Nov 15 17:14:04 2016 From: laz at vgdata.dk (Kaj Mikkelsen) Date: Tue, 15 Nov 2016 17:14:04 +0100 Subject: [Lazarus] fpConnect In-Reply-To: <20161115165205.366a2da4@limapholos.matflo.wg> References: <49a297c3-7b99-fd8c-74a8-3201f55bc8a5@vgdata.dk> <20161115165205.366a2da4@limapholos.matflo.wg> Message-ID: Forgot to mention that I run Lazarus on Linux mint 17.3 By open I mean, that the host is ready to accept connections. Like if you run nmap -p 22 xxx.xxx.xxx.xxx to se if the host is accepting SSH connections. /Kaj On 2016-11-15 16:52, Mattias Gaertner via Lazarus wrote: > On Tue, 15 Nov 2016 16:37:32 +0100 > Kaj Mikkelsen via Lazarus wrote: > >> Hi >> >> I need a method to tell whether a specific port is open on a remote host. > Please define "open". > > Mattias From luca at wetron.es Tue Nov 15 17:48:07 2016 From: luca at wetron.es (Luca Olivetti) Date: Tue, 15 Nov 2016 17:48:07 +0100 Subject: [Lazarus] Lazarus Release 1.6.2 In-Reply-To: <20161115154206.25fd71bc@limapholos.matflo.wg> References: <20161115154206.25fd71bc@limapholos.matflo.wg> Message-ID: El 15/11/16 a les 15:42, Mattias Gaertner via Lazarus ha escrit: > The Lazarus team is glad to announce the release of Lazarus 1.6.2. This > is a bugfix release. > > This release was built with FPC 3.0.0. Is it supposed to work even with 2.6.4? I have to investigate why but a TDBLookupComboBox doesn't work anymore (with fpc 2.64/win32). Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From bartjunk64 at gmail.com Tue Nov 15 18:28:00 2016 From: bartjunk64 at gmail.com (Bart) Date: Tue, 15 Nov 2016 18:28:00 +0100 Subject: [Lazarus] TPageControl OnChange calling issue In-Reply-To: References: <6dd35aa2-24e5-0eee-f02e-ca8feeff84a9@gmx.de> <4c2aaa88-6c76-f8a4-a963-98dcd001d332@lumino.de> <13980c6d-d846-9e0b-2135-b4b110521b58@kluug.net> <29741c31-96af-d911-c4cd-f628036deac3@lumino.de> <43328498-1adc-f07e-988b-287751aa2006@holobit.net> <0d13e7c4-86a5-3ae2-8e84-c59b73f22871@gmx.de> Message-ID: On 11/15/16, Michael Schnell via Lazarus wrote: > That supposedly can easily be defined by the general "mode" setting. Mode switches are about coding (how the compiler should behave), not about how components should behave once compiled. Bart From bartjunk64 at gmail.com Tue Nov 15 18:29:11 2016 From: bartjunk64 at gmail.com (Bart) Date: Tue, 15 Nov 2016 18:29:11 +0100 Subject: [Lazarus] TPageControl OnChange calling issue In-Reply-To: References: <6dd35aa2-24e5-0eee-f02e-ca8feeff84a9@gmx.de> <4c2aaa88-6c76-f8a4-a963-98dcd001d332@lumino.de> <13980c6d-d846-9e0b-2135-b4b110521b58@kluug.net> <29741c31-96af-d911-c4cd-f628036deac3@lumino.de> <43328498-1adc-f07e-988b-287751aa2006@holobit.net> <0d13e7c4-86a5-3ae2-8e84-c59b73f22871@gmx.de> Message-ID: On 11/15/16, Ondrej Pokorny via Lazarus wrote: > Then there's the problem with what behavior should be default. If we say > LCL is VCL compatible then it is clear, but the more I think about it > the more I feel Delphi behavior is just strange. Probably thinking is > not appropriate here... I agree, stop thinking ;-) For the time being it miht be best to follow VCL behaviour... Bart From luca at wetron.es Tue Nov 15 18:46:43 2016 From: luca at wetron.es (Luca Olivetti) Date: Tue, 15 Nov 2016 18:46:43 +0100 Subject: [Lazarus] Lazarus Release 1.6.2 In-Reply-To: References: <20161115154206.25fd71bc@limapholos.matflo.wg> Message-ID: El 15/11/16 a les 17:48, Luca Olivetti via Lazarus ha escrit: > El 15/11/16 a les 15:42, Mattias Gaertner via Lazarus ha escrit: >> The Lazarus team is glad to announce the release of Lazarus 1.6.2. This >> is a bugfix release. >> >> This release was built with FPC 3.0.0. > > Is it supposed to work even with 2.6.4? > I have to investigate why but a TDBLookupComboBox doesn't work anymore > (with fpc 2.64/win32). I tried under linux 64 bits/gtk, with fpc 3.0.0 the TDbLookupComboBox works, with 2.6.4 it doesn't. The symptom is the same: the combobox has the correct number of options but all of them are blank. If it's supposed to work with 2.6.4 I can file a bug report. Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From luca at wetron.es Tue Nov 15 19:12:10 2016 From: luca at wetron.es (Luca Olivetti) Date: Tue, 15 Nov 2016 19:12:10 +0100 Subject: [Lazarus] Lazarus Release 1.6.2 In-Reply-To: References: <20161115154206.25fd71bc@limapholos.matflo.wg> Message-ID: <163a9a30-443e-e44a-e771-15a6495d36ae@wetron.es> El 15/11/16 a les 18:46, Luca Olivetti via Lazarus ha escrit: > El 15/11/16 a les 17:48, Luca Olivetti via Lazarus ha escrit: >> El 15/11/16 a les 15:42, Mattias Gaertner via Lazarus ha escrit: >>> The Lazarus team is glad to announce the release of Lazarus 1.6.2. This >>> is a bugfix release. >>> >>> This release was built with FPC 3.0.0. >> >> Is it supposed to work even with 2.6.4? >> I have to investigate why but a TDBLookupComboBox doesn't work anymore >> (with fpc 2.64/win32). > > I tried under linux 64 bits/gtk, with fpc 3.0.0 the TDbLookupComboBox > works, with 2.6.4 it doesn't. > The symptom is the same: the combobox has the correct number of options > but all of them are blank. > If it's supposed to work with 2.6.4 I can file a bug report. transplanting lcl/include/dblookup.inc from lazarus 1.4 to 1.6 "fixes" the issue (which is funny, since the new one apparently has some ifdefs that only modify the behavior with fpc < 3.0.0). Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From luca at wetron.es Tue Nov 15 19:24:03 2016 From: luca at wetron.es (Luca Olivetti) Date: Tue, 15 Nov 2016 19:24:03 +0100 Subject: [Lazarus] Lazarus Release 1.6.2 In-Reply-To: <163a9a30-443e-e44a-e771-15a6495d36ae@wetron.es> References: <20161115154206.25fd71bc@limapholos.matflo.wg> <163a9a30-443e-e44a-e771-15a6495d36ae@wetron.es> Message-ID: <38949df1-924b-157f-0391-099275008589@wetron.es> El 15/11/16 a les 19:12, Luca Olivetti via Lazarus ha escrit: > El 15/11/16 a les 18:46, Luca Olivetti via Lazarus ha escrit: >> El 15/11/16 a les 17:48, Luca Olivetti via Lazarus ha escrit: >>> El 15/11/16 a les 15:42, Mattias Gaertner via Lazarus ha escrit: >>>> The Lazarus team is glad to announce the release of Lazarus 1.6.2. This >>>> is a bugfix release. >>>> >>>> This release was built with FPC 3.0.0. >>> >>> Is it supposed to work even with 2.6.4? >>> I have to investigate why but a TDBLookupComboBox doesn't work anymore >>> (with fpc 2.64/win32). >> >> I tried under linux 64 bits/gtk, with fpc 3.0.0 the TDbLookupComboBox >> works, with 2.6.4 it doesn't. >> The symptom is the same: the combobox has the correct number of options >> but all of them are blank. >> If it's supposed to work with 2.6.4 I can file a bug report. > > transplanting lcl/include/dblookup.inc from lazarus 1.4 to 1.6 "fixes" > the issue (which is funny, since the new one apparently has some ifdefs > that only modify the behavior with fpc < 3.0.0). OK, I'm using a TSdfDataset, maybe it has the same bug as TMemDataset as mentioned in dblookup.inc (but then I don't understand why it worked with lazarus 1.4). FWIF, this appears to fix it: =================================================================== --- lcl/include/dblookup.inc (revision 53370) +++ lcl/include/dblookup.inc (working copy) @@ -274,7 +274,7 @@ Bookmark := ListLinkDataSet.GetBookmark; //in fpc 2.6.4, TMemDataset does not supports BlockRead. Issues 26356, 27959 {$IF FPC_FULLVERSION < 30000} - DatasetSupportsBlockRead := not IsClass(ListLinkDataSet, 'TMemDataset'); + DatasetSupportsBlockRead := not IsClass(ListLinkDataSet, 'TMemDataset') and not IsClass(ListLinkDataSet, 'TFixedFormatDataSet'); if DatasetSupportsBlockRead then ListLinkDataSet.BlockReadSize := 1 else -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From zeljko at holobit.net Tue Nov 15 19:27:14 2016 From: zeljko at holobit.net (zeljko) Date: Tue, 15 Nov 2016 19:27:14 +0100 Subject: [Lazarus] {Spam?} Re: Lazarus Release 1.6.2 In-Reply-To: <38949df1-924b-157f-0391-099275008589@wetron.es> References: <20161115154206.25fd71bc@limapholos.matflo.wg> <163a9a30-443e-e44a-e771-15a6495d36ae@wetron.es> <38949df1-924b-157f-0391-099275008589@wetron.es> Message-ID: <52c557ca-02c4-18ff-ae4d-ed488dca6236@holobit.net> > > OK, I'm using a TSdfDataset, maybe it has the same bug as TMemDataset as > mentioned in dblookup.inc (but then I don't understand why it worked > with lazarus 1.4). > FWIF, this appears to fix it: > > =================================================================== > --- lcl/include/dblookup.inc (revision 53370) > +++ lcl/include/dblookup.inc (working copy) > @@ -274,7 +274,7 @@ > Bookmark := ListLinkDataSet.GetBookmark; > //in fpc 2.6.4, TMemDataset does not supports BlockRead. Issues > 26356, 27959 > {$IF FPC_FULLVERSION < 30000} > - DatasetSupportsBlockRead := not IsClass(ListLinkDataSet, 'TMemDataset'); > + DatasetSupportsBlockRead := not IsClass(ListLinkDataSet, > 'TMemDataset') and not IsClass(ListLinkDataSet, 'TFixedFormatDataSet'); > if DatasetSupportsBlockRead then > ListLinkDataSet.BlockReadSize := 1 > else Please open an issue about problem and attach: 1.Example project 2.Patch zeljko From lazarus at kluug.net Tue Nov 15 19:27:42 2016 From: lazarus at kluug.net (Ondrej Pokorny) Date: Tue, 15 Nov 2016 19:27:42 +0100 Subject: [Lazarus] Lazarus Release 1.6.2 In-Reply-To: <38949df1-924b-157f-0391-099275008589@wetron.es> References: <20161115154206.25fd71bc@limapholos.matflo.wg> <163a9a30-443e-e44a-e771-15a6495d36ae@wetron.es> <38949df1-924b-157f-0391-099275008589@wetron.es> Message-ID: <4ba3d804-36f0-0483-271f-1d6bbf5d8bb8@kluug.net> Thank you for your efforts - please send the patch to mantis so that DB maintainers don't oversee it! Ondrej From luca at wetron.es Tue Nov 15 19:42:10 2016 From: luca at wetron.es (Luca Olivetti) Date: Tue, 15 Nov 2016 19:42:10 +0100 Subject: [Lazarus] Lazarus Release 1.6.2 In-Reply-To: <4ba3d804-36f0-0483-271f-1d6bbf5d8bb8@kluug.net> References: <20161115154206.25fd71bc@limapholos.matflo.wg> <163a9a30-443e-e44a-e771-15a6495d36ae@wetron.es> <38949df1-924b-157f-0391-099275008589@wetron.es> <4ba3d804-36f0-0483-271f-1d6bbf5d8bb8@kluug.net> Message-ID: El 15/11/16 a les 19:27, Ondrej Pokorny via Lazarus ha escrit: > Thank you for your efforts - please send the patch to mantis so that DB > maintainers don't oversee it! > Done: http://bugs.freepascal.org/view.php?id=30931 Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From badsectoracula at gmail.com Tue Nov 15 19:52:58 2016 From: badsectoracula at gmail.com (Kostas Michalopoulos) Date: Tue, 15 Nov 2016 20:52:58 +0200 Subject: [Lazarus] Lazarus Release 1.6.2 In-Reply-To: References: <20161115154206.25fd71bc@limapholos.matflo.wg> <163a9a30-443e-e44a-e771-15a6495d36ae@wetron.es> <38949df1-924b-157f-0391-099275008589@wetron.es> <4ba3d804-36f0-0483-271f-1d6bbf5d8bb8@kluug.net> Message-ID: The main site seems to still serve the 1.6.0 download. On Tue, Nov 15, 2016 at 8:42 PM, Luca Olivetti via Lazarus < lazarus at lists.lazarus-ide.org> wrote: > El 15/11/16 a les 19:27, Ondrej Pokorny via Lazarus ha escrit: > >> Thank you for your efforts - please send the patch to mantis so that DB >> maintainers don't oversee it! >> >> > > Done: > > http://bugs.freepascal.org/view.php?id=30931 > > Bye > -- > Luca Olivetti > Wetron Automation Technology http://www.wetron.es/ > Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 > -- > _______________________________________________ > Lazarus mailing list > Lazarus at lists.lazarus-ide.org > http://lists.lazarus-ide.org/listinfo/lazarus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lazarus at mfriebe.de Tue Nov 15 19:56:51 2016 From: lazarus at mfriebe.de (Martin Frb) Date: Tue, 15 Nov 2016 18:56:51 +0000 Subject: [Lazarus] Lazarus Release 1.6.2 In-Reply-To: References: <20161115154206.25fd71bc@limapholos.matflo.wg> <163a9a30-443e-e44a-e771-15a6495d36ae@wetron.es> <38949df1-924b-157f-0391-099275008589@wetron.es> <4ba3d804-36f0-0483-271f-1d6bbf5d8bb8@kluug.net> Message-ID: <7ceb2bc0-a12c-3dcc-7310-e7b1728488b5@mfriebe.de> On 15/11/2016 18:52, Kostas Michalopoulos via Lazarus wrote: > The main site seems to still serve the 1.6.0 download. > Yes there is always some delay, as different people are involved in all the steps. From luca at wetron.es Tue Nov 15 20:01:48 2016 From: luca at wetron.es (Luca Olivetti) Date: Tue, 15 Nov 2016 20:01:48 +0100 Subject: [Lazarus] Lazarus Release 1.6.2 In-Reply-To: References: <20161115154206.25fd71bc@limapholos.matflo.wg> <163a9a30-443e-e44a-e771-15a6495d36ae@wetron.es> <38949df1-924b-157f-0391-099275008589@wetron.es> <4ba3d804-36f0-0483-271f-1d6bbf5d8bb8@kluug.net> Message-ID: <1ba10b77-9cb9-9842-626c-a9ea7cc8c3f0@wetron.es> El 15/11/16 a les 19:52, Kostas Michalopoulos via Lazarus ha escrit: > The main site seems to still serve the 1.6.0 download. I usually update my copy from svn http://svn.freepascal.org/svn/lazarus/tags/lazarus_1_6_2 Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From reggiebrooks at cox.net Tue Nov 15 21:11:31 2016 From: reggiebrooks at cox.net (reggiebrooks at cox.net) Date: Tue, 15 Nov 2016 15:11:31 -0500 Subject: [Lazarus] Lazarus Release 1.6.2 Message-ID: Can this 1.6.2 release be installed over an existing 1.6.0 installation, or would I have to uninstall the 1.6.0 first? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nc-gaertnma at netcologne.de Tue Nov 15 22:10:56 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Tue, 15 Nov 2016 22:10:56 +0100 Subject: [Lazarus] Lazarus Release 1.6.2 In-Reply-To: References: Message-ID: <20161115221056.1429fa4c@limapholos.matflo.wg> On Tue, 15 Nov 2016 15:11:31 -0500 Reggie Brooks via Lazarus wrote: > Can this 1.6.2 release be installed over an existing 1.6.0 installation, or would I have to uninstall the 1.6.0 first? The dmg/deb/rpm/zip can be installed over an existing 1.6.0 without uninstall. I didn't try the Windows installer. Martin? Mattias From badsectoracula at gmail.com Tue Nov 15 22:19:41 2016 From: badsectoracula at gmail.com (Kostas Michalopoulos) Date: Tue, 15 Nov 2016 23:19:41 +0200 Subject: [Lazarus] Lazarus Release 1.6.2 In-Reply-To: <20161115221056.1429fa4c@limapholos.matflo.wg> References: <20161115221056.1429fa4c@limapholos.matflo.wg> Message-ID: The installer had an "Uninstall" button to uninstalled the previous version. I used that then used Tools -> Build Lazarus with option to rebuild the IDE so that it'll have the packages i have installed and it worked fine. On Tue, Nov 15, 2016 at 11:10 PM, Mattias Gaertner via Lazarus < lazarus at lists.lazarus-ide.org> wrote: > On Tue, 15 Nov 2016 15:11:31 -0500 > Reggie Brooks via Lazarus wrote: > > > Can this 1.6.2 release be installed over an existing 1.6.0 installation, > or would I have to uninstall the 1.6.0 first? > > The dmg/deb/rpm/zip can be installed over an existing 1.6.0 without > uninstall. > I didn't try the Windows installer. Martin? > > Mattias > -- > _______________________________________________ > Lazarus mailing list > Lazarus at lists.lazarus-ide.org > http://lists.lazarus-ide.org/listinfo/lazarus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lazarus at mfriebe.de Wed Nov 16 01:07:20 2016 From: lazarus at mfriebe.de (Martin Frb) Date: Wed, 16 Nov 2016 00:07:20 +0000 Subject: [Lazarus] Lazarus Release 1.6.2 In-Reply-To: <20161115221056.1429fa4c@limapholos.matflo.wg> References: <20161115221056.1429fa4c@limapholos.matflo.wg> Message-ID: <9a216be8-29c5-020a-c066-666edf390918@mfriebe.de> On 15/11/2016 21:10, Mattias Gaertner via Lazarus wrote: > On Tue, 15 Nov 2016 15:11:31 -0500 > Reggie Brooks via Lazarus wrote: > >> Can this 1.6.2 release be installed over an existing 1.6.0 installation, or would I have to uninstall the 1.6.0 first? > The dmg/deb/rpm/zip can be installed over an existing 1.6.0 without > uninstall. > I didn't try the Windows installer. Martin? > It should work. The only issue that can arise (but usually between major releases) is, if units moved to another package. then old ppu can be problematic (build clean all, of the ide might help) From mschnell at lumino.de Wed Nov 16 10:30:01 2016 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 16 Nov 2016 10:30:01 +0100 Subject: [Lazarus] TPageControl OnChange calling issue In-Reply-To: References: <6dd35aa2-24e5-0eee-f02e-ca8feeff84a9@gmx.de> <4c2aaa88-6c76-f8a4-a963-98dcd001d332@lumino.de> <13980c6d-d846-9e0b-2135-b4b110521b58@kluug.net> <29741c31-96af-d911-c4cd-f628036deac3@lumino.de> <43328498-1adc-f07e-988b-287751aa2006@holobit.net> <0d13e7c4-86a5-3ae2-8e84-c59b73f22871@gmx.de> Message-ID: <8a3a5dfd-847b-15fe-2e86-51a39c8bdca1@lumino.de> On 15.11.2016 18:28, Bart via Lazarus wrote: > > Mode switches are about coding (how the compiler should behave), not > about how components should behave once compiled. > Of course I do know that they are used in that way. I just wanted to say that the Delphi compatibility modes *could* be used to define the *default* setting of this property. at compile time. Seems rather logical to me. -Michael From lazarus at kluug.net Wed Nov 16 10:33:21 2016 From: lazarus at kluug.net (Ondrej Pokorny) Date: Wed, 16 Nov 2016 10:33:21 +0100 Subject: [Lazarus] TPageControl OnChange calling issue In-Reply-To: <8a3a5dfd-847b-15fe-2e86-51a39c8bdca1@lumino.de> References: <6dd35aa2-24e5-0eee-f02e-ca8feeff84a9@gmx.de> <4c2aaa88-6c76-f8a4-a963-98dcd001d332@lumino.de> <13980c6d-d846-9e0b-2135-b4b110521b58@kluug.net> <29741c31-96af-d911-c4cd-f628036deac3@lumino.de> <43328498-1adc-f07e-988b-287751aa2006@holobit.net> <0d13e7c4-86a5-3ae2-8e84-c59b73f22871@gmx.de> <8a3a5dfd-847b-15fe-2e86-51a39c8bdca1@lumino.de> Message-ID: On 16.11.2016 10:30, Michael Schnell via Lazarus wrote: > On 15.11.2016 18:28, Bart via Lazarus wrote: >> >> Mode switches are about coding (how the compiler should behave), not >> about how components should behave once compiled. >> > Of course I do know that they are used in that way. I just wanted to > say that the Delphi compatibility modes *could* be used to define the > *default* setting of this property. at compile time. > > Seems rather logical to me. No, this is not technically possible. The mode settings have unit-scope. TPageControl/TCustomTabControl are in unit ComCtrls that is always built with objfpc mode. Ondrej From mschnell at lumino.de Wed Nov 16 10:35:34 2016 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 16 Nov 2016 10:35:34 +0100 Subject: [Lazarus] TPageControl OnChange calling issue In-Reply-To: References: <6dd35aa2-24e5-0eee-f02e-ca8feeff84a9@gmx.de> <4c2aaa88-6c76-f8a4-a963-98dcd001d332@lumino.de> <13980c6d-d846-9e0b-2135-b4b110521b58@kluug.net> <29741c31-96af-d911-c4cd-f628036deac3@lumino.de> <43328498-1adc-f07e-988b-287751aa2006@holobit.net> <0d13e7c4-86a5-3ae2-8e84-c59b73f22871@gmx.de> <8a3a5dfd-847b-15fe-2e86-51a39c8bdca1@lumino.de> Message-ID: On 16.11.2016 10:33, Ondrej Pokorny via Lazarus wrote: > The mode settings have unit-scope. TPageControl/TCustomTabControl are > in unit ComCtrls that is always built with objfpc mode. I see. Thanks, -Michael From badsectoracula at gmail.com Wed Nov 16 18:38:16 2016 From: badsectoracula at gmail.com (Kostas Michalopoulos) Date: Wed, 16 Nov 2016 19:38:16 +0200 Subject: [Lazarus] TPageControl OnChange calling issue In-Reply-To: References: <6dd35aa2-24e5-0eee-f02e-ca8feeff84a9@gmx.de> <4c2aaa88-6c76-f8a4-a963-98dcd001d332@lumino.de> <13980c6d-d846-9e0b-2135-b4b110521b58@kluug.net> <29741c31-96af-d911-c4cd-f628036deac3@lumino.de> <43328498-1adc-f07e-988b-287751aa2006@holobit.net> <0d13e7c4-86a5-3ae2-8e84-c59b73f22871@gmx.de> <8a3a5dfd-847b-15fe-2e86-51a39c8bdca1@lumino.de> Message-ID: If the existing functionality differs from Delphi, i say to keep the existing functionality as the default. After all what is more important? Breaking existing Lazarus users' code or potentially having a Delphi code migration become slightly harder because a project will need to change a property (also isn't stuff like this why the IDE has options to import Delphi projects/units/forms/etc?). On Wed, Nov 16, 2016 at 11:35 AM, Michael Schnell via Lazarus < lazarus at lists.lazarus-ide.org> wrote: > On 16.11.2016 10:33, Ondrej Pokorny via Lazarus wrote: > >> The mode settings have unit-scope. TPageControl/TCustomTabControl are in >> unit ComCtrls that is always built with objfpc mode. >> > I see. > > Thanks, > -Michael > > -- > _______________________________________________ > Lazarus mailing list > Lazarus at lists.lazarus-ide.org > http://lists.lazarus-ide.org/listinfo/lazarus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tc at epidata.info Fri Nov 18 08:50:56 2016 From: tc at epidata.info (Torsten Bonde Christiansen) Date: Fri, 18 Nov 2016 08:50:56 +0100 Subject: [Lazarus] SynEdit - marking a line Message-ID: <9f028506-a790-6704-f120-b8c466e336eb@epidata.info> Hi List. I have just recently started playing with SynEdit and all it's features, but so far things have been going good. The examples in lazarus are fine and have helped a lot! However i would like to mark a whole line, much like done in in the IDE when placing breakpoints etc.? I would be glad if someone could help me in the right direction. :) Regards Torsten Bonde Christiansen From noreply at z505.com Fri Nov 18 12:36:55 2016 From: noreply at z505.com (Lars) Date: Fri, 18 Nov 2016 04:36:55 -0700 Subject: [Lazarus] LHelp or help systems that also work on.. Message-ID: <3eeaa008601061d9a75cfbd754e180d9.squirrel@gator3286.hostgator.com> Hi, Since I use both Lazarus and Delphi and never just use one or the other, is there any help system that works in both delphi and Lazarus? i.e. anyone port LHelp to delphi so delphi apps can have a similar help system? Or any other help systems that are portable between Laz and Delphi? I haven't studied much, but my guess is LHelp was specifically built for Lazarus and never considered Delphi, due to the name "L Help" which stands for maybe lazarus help. Assumptions here... From andrewd207 at aol.com Fri Nov 18 13:08:34 2016 From: andrewd207 at aol.com (Andrew Haines) Date: Fri, 18 Nov 2016 07:08:34 -0500 Subject: [Lazarus] LHelp or help systems that also work on.. In-Reply-To: <3eeaa008601061d9a75cfbd754e180d9.squirrel@gator3286.hostgator.com> References: <3eeaa008601061d9a75cfbd754e180d9.squirrel@gator3286.hostgator.com> Message-ID: On 11/18/2016 06:36 AM, Lars via Lazarus wrote: > Hi, > > Since I use both Lazarus and Delphi and never just use one or the other, > is there any help system that works in both delphi and Lazarus? i.e. > anyone port LHelp to delphi so delphi apps can have a similar help system? > Or any other help systems that are portable between Laz and Delphi? > > I haven't studied much, but my guess is LHelp was specifically built for > Lazarus and never considered Delphi, due to the name "L Help" which stands > for maybe lazarus help. Assumptions here... > > lhelp uses IPC to communicate so it wouldn't be too bad to write a Delphi unit to control it. Compiling lhelp though is a fpc only job. https://github.com/graemeg/lazarus/blob/upstream/components/chmhelp/packages/help/lhelpcontrol.pas Regards, Andrew From lazarus at mfriebe.de Fri Nov 18 13:51:21 2016 From: lazarus at mfriebe.de (Martin Frb) Date: Fri, 18 Nov 2016 12:51:21 +0000 Subject: [Lazarus] SynEdit - marking a line In-Reply-To: <9f028506-a790-6704-f120-b8c466e336eb@epidata.info> References: <9f028506-a790-6704-f120-b8c466e336eb@epidata.info> Message-ID: On 18/11/2016 07:50, Torsten Bonde Christiansen via Lazarus wrote: > Hi List. > > I have just recently started playing with SynEdit and all it's > features, but so far things have been going good. > > The examples in lazarus are fine and have helped a lot! > > However i would like to mark a whole line, much like done in in the > IDE when placing breakpoints etc.? > > I would be glad if someone could help me in the right direction. :) Search for OnSpecialLine Markup (or OnSpecialLineColor, if it is just background color) The code in this event should be fast. It will be called many times (everytime any part of a line is painted). So calculate and store the needed info somewhere else, and then in the event, only compare the line number with the stored value. From mailinglists at geldenhuys.co.uk Fri Nov 18 14:16:47 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 18 Nov 2016 13:16:47 +0000 Subject: [Lazarus] LHelp or help systems that also work on.. In-Reply-To: <3eeaa008601061d9a75cfbd754e180d9.squirrel@gator3286.hostgator.com> References: <3eeaa008601061d9a75cfbd754e180d9.squirrel@gator3286.hostgator.com> Message-ID: On 2016-11-18 11:36, Lars via Lazarus wrote: > Since I use both Lazarus and Delphi and never just use one or the other, > is there any help system that works in both delphi and Lazarus? Yes, Docview and INF help can be used in both cases. I already posted a full example project for Lazarus LCL applications in the Lazarus Forums. For Delphi applications you can do the following. Simply set the HelpContext values for each component or form - as you normally would. Then implement a global help event handler as shown below. This simply catches the help request, then launches DocView with the correct parameters to display the help topic in question. ps: There is a known bug in Delphi 7 where Application.OnHelp is never called. Later Delphi versions have fixed this bug. If the application is compiled with Delphi 7, then you need to simply catch the WM_HELP message in the form, and call AppHelp() explicitly. ======================================== function TForm1.AppHelp(Command: Word; Data: Integer; var CallHelp: Boolean): Boolean; const cEXE = 'c:\apps\docview.exe myapp.inf -n %d'; var SI: TStartupInfo; PI: TProcessInformation; cmd: string; begin if Command = HELP_CONTEXT then CallHelp := False else begin Result := True; CallHelp := True; // don't do anything ourselves. Exit; end; // if we got here, we must display some help. cmd := Format(cEXE, [Data]); GetStartupInfo(SI); // do whatever other setup info you want CreateProcess(nil, PChar(cmd), nil, nil, False, 0, nil, nil, SI, PI); Result := True; end; procedure TForm1.FormCreate(Sender: TObject); begin Application.HelpFile := 'myapp.inf'; Application.OnHelp := AppHelp; end; ========================================== Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From mailinglists at geldenhuys.co.uk Fri Nov 18 14:31:59 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 18 Nov 2016 13:31:59 +0000 Subject: [Lazarus] LHelp or help systems that also work on.. In-Reply-To: References: <3eeaa008601061d9a75cfbd754e180d9.squirrel@gator3286.hostgator.com> Message-ID: <398ce43c-3ee0-b0f4-6ab7-c5937b342412@geldenhuys.co.uk> On 2016-11-18 13:16, Graeme Geldenhuys via Lazarus wrote: > ps: > There is a known bug in Delphi 7 where Application.OnHelp is never > called. Later Delphi versions have fixed this bug. If the application > is compiled with Delphi 7, then you need to simply catch the WM_HELP > message in the form, and call AppHelp() explicitly. Apparently both D6 and D7's Application.OnHelp was broken. Here is an alternative fix for those versions of Delphi. http://web.archive.org/web/20100611210430/http://helpware.net/downloads/index.htm Scroll down to the "Delphi 6,7,.. OnHelp Fix" and download the example zip which includes the D6OnHelpFix.pas unit that implements the fix. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From kashken at csteldridge.com Sat Nov 19 00:01:37 2016 From: kashken at csteldridge.com (Ken Kashmarek) Date: Fri, 18 Nov 2016 16:01:37 -0700 (MST) Subject: [Lazarus] Quad precision library for Free Pascal Message-ID: <1479510097442-4050382.post@n3.nabble.com> Does anyone know of or have implemented a quad precision (128-bit) library for Free Pascal. I see there are some available for C or GCC but not Free Pascal directly. Your feedback is appreciated Ken -- View this message in context: http://free-pascal-lazarus.989080.n3.nabble.com/Quad-precision-library-for-Free-Pascal-tp4050382.html Sent from the Free Pascal - Lazarus mailing list archive at Nabble.com. From terry at haimann.us Sat Nov 19 04:25:14 2016 From: terry at haimann.us (Terry A. Haimann) Date: Fri, 18 Nov 2016 21:25:14 -0600 Subject: [Lazarus] Lazarus and MySQL 5.7 Message-ID: <1479525914.4974.3.camel@Hercules> What version of Lazarus can connect to MySQL 5.7 using TSqlConnector? My laptop has 1.6 and does not seem to be able to connect using that component. Thx, Terry From mailinglists at geldenhuys.co.uk Sat Nov 19 11:40:31 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Sat, 19 Nov 2016 10:40:31 +0000 Subject: [Lazarus] Lazarus and MySQL 5.7 In-Reply-To: <1479525914.4974.3.camel@Hercules> References: <1479525914.4974.3.camel@Hercules> Message-ID: <8de0a37c-2fe3-95a7-9b57-dcce68582b8a@geldenhuys.co.uk> On 2016-11-19 03:25, Terry A. Haimann via Lazarus wrote: > What version of Lazarus can connect to MySQL 5.7 using TSqlConnector? Technically it's got nothing to do with the Lazarus version, but rather the FPC version. FPC is the one where the database components are defined, in the FCL. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From noreply at z505.com Sat Nov 19 23:24:39 2016 From: noreply at z505.com (Lars) Date: Sat, 19 Nov 2016 15:24:39 -0700 Subject: [Lazarus] LHelp or help systems that also work on.. In-Reply-To: References: <3eeaa008601061d9a75cfbd754e180d9.squirrel@gator3286.hostgator.com> Message-ID: On Fri, November 18, 2016 5:08 am, Andrew Haines via Lazarus wrote: > lhelp uses IPC to communicate so it wouldn't be too bad to write a Delphi > unit to control it. Compiling lhelp though is a fpc only job. > > https://github.com/graemeg/lazarus/blob/upstream/components/chmhelp/packa > ges/help/lhelpcontrol.pas > Thanks for the tip. So I see many people are using SimpleIPC. Has anyone come across any problems. When I tried it when it very first came out almost days or weeks after the first release of it, I noticed some duplicate messages being passed. Not sure if it was my problem or the IPC unit problem. Seemed like a really neat tool, SimpleIPC. From noreply at z505.com Sat Nov 19 23:33:15 2016 From: noreply at z505.com (Lars) Date: Sat, 19 Nov 2016 15:33:15 -0700 Subject: [Lazarus] LHelp or help systems that also work on.. In-Reply-To: References: <3eeaa008601061d9a75cfbd754e180d9.squirrel@gator3286.hostgator.com> Message-ID: <3a05dfc9cfdd1229fcc7e7a753a2ad3f.squirrel@gator3286.hostgator.com> On Sat, November 19, 2016 3:24 pm, Lars wrote: > On Fri, November 18, 2016 5:08 am, Andrew Haines via Lazarus wrote: > >> lhelp uses IPC to communicate so it wouldn't be too bad to write a >> Delphi >> unit to control it. p.s. in addition to my last message, wouldn't SimpleIPC need to be ported to delphi then.. or at least some of it's mechanism. Would be neat if simpleipc was available in delphi so fpc programs could communicate to delphi programs. If only simpleipc was standardized and available in all languages ;-) From andrewd207 at aol.com Sun Nov 20 03:37:44 2016 From: andrewd207 at aol.com (Andrew Haines) Date: Sat, 19 Nov 2016 21:37:44 -0500 Subject: [Lazarus] LHelp or help systems that also work on.. In-Reply-To: <3a05dfc9cfdd1229fcc7e7a753a2ad3f.squirrel@gator3286.hostgator.com> References: <3eeaa008601061d9a75cfbd754e180d9.squirrel@gator3286.hostgator.com> <3a05dfc9cfdd1229fcc7e7a753a2ad3f.squirrel@gator3286.hostgator.com> Message-ID: On 11/19/2016 05:33 PM, Lars via Lazarus wrote: > On Sat, November 19, 2016 3:24 pm, Lars wrote: >> On Fri, November 18, 2016 5:08 am, Andrew Haines via Lazarus wrote: >> >>> lhelp uses IPC to communicate so it wouldn't be too bad to write a >>> Delphi >>> unit to control it. > p.s. in addition to my last message, wouldn't SimpleIPC need to be ported > to delphi then.. or at least some of it's mechanism. > > Would be neat if simpleipc was available in delphi so fpc programs could > communicate to delphi programs. If only simpleipc was standardized and > available in all languages ;-) Looking at the simpleipc unit I see TMsgHeader = Packed record Version : Byte; MsgType : TMessageType; MsgLen : Integer; end; I guess the message content, assuming any following data, is after MsgLen. This would be easy to implement. Regards, Andrew Haines From noreply at z505.com Sun Nov 20 04:50:45 2016 From: noreply at z505.com (Lars) Date: Sat, 19 Nov 2016 20:50:45 -0700 Subject: [Lazarus] stale pipe workarounds Message-ID: <0c6e272edf3ccfed48eac0cd4282b874.squirrel@gator3286.hostgator.com> Hi while researching help systems I came across the code which uses IPC to communicate and see that people are adding stale pipe work arounds. So this can't be resolved in the ipc code itself and must be in the application? Just wondering why these work arounds are needed and when they occur. The stale pipe code work around is at https://github.com/graemeg/lazarus/blob/upstream/components/chmhelp/packages/help/lhelpcontrol.pas So does anyone who uses IPC have to be aware of this and add the work around to all ipc code in all applications? Or it only happens in certain cases? It just makes me scared that there is this hack/fix needed. From andrewd207 at aol.com Sun Nov 20 07:01:13 2016 From: andrewd207 at aol.com (Andrew Haines) Date: Sun, 20 Nov 2016 01:01:13 -0500 Subject: [Lazarus] stale pipe workarounds In-Reply-To: <0c6e272edf3ccfed48eac0cd4282b874.squirrel@gator3286.hostgator.com> References: <0c6e272edf3ccfed48eac0cd4282b874.squirrel@gator3286.hostgator.com> Message-ID: <23900dfe-71ef-7ad4-3e0b-f9ce9be013e0@aol.com> On 11/19/2016 10:50 PM, Lars via Lazarus wrote: > Hi while researching help systems I came across the code which uses IPC to > communicate and see that people are adding stale pipe work arounds. > > So this can't be resolved in the ipc code itself and must be in the > application? Just wondering why these work arounds are needed and when > they occur. The stale pipe code work around is at > > https://github.com/graemeg/lazarus/blob/upstream/components/chmhelp/packages/help/lhelpcontrol.pas > > So does anyone who uses IPC have to be aware of this and add the work > around to all ipc code in all applications? Or it only happens in certain > cases? It just makes me scared that there is this hack/fix needed. FPC now has this stale pipe detection included. The fix was added to the code lazarus uses until the next official version of FPC was released and went into the develop version of fpc in early 2012. At this point it could probably be removed form lazarus since there have been multiple releases of fpc since then. https://github.com/graemeg/freepascal/blob/master/packages/fcl-process/src/unix/simpleipc.inc#L97 https://github.com/graemeg/freepascal/commit/439236b9df1e952ad0fc1da42f05851dfea459ac Regards, Andrew Haines From noreply at z505.com Sun Nov 20 07:16:22 2016 From: noreply at z505.com (Lars) Date: Sat, 19 Nov 2016 23:16:22 -0700 Subject: [Lazarus] LHelp or help systems that also work on.. In-Reply-To: References: <3eeaa008601061d9a75cfbd754e180d9.squirrel@gator3286.hostgator.com> Message-ID: <873e270205e1d3575070dcc093548095.squirrel@gator3286.hostgator.com> On Fri, November 18, 2016 6:16 am, Graeme Geldenhuys via Lazarus wrote: > On 2016-11-18 11:36, Lars via Lazarus wrote: > >> Since I use both Lazarus and Delphi and never just use one or the >> other, is there any help system that works in both delphi and Lazarus? > > Yes, Docview and INF help can be used in both cases. Docview is an fpGui based project? If so that would be interesting and maybe my ticket into finally looking at some fpGui code From mailinglists at geldenhuys.co.uk Sun Nov 20 10:41:53 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Sun, 20 Nov 2016 09:41:53 +0000 Subject: [Lazarus] LHelp or help systems that also work on.. In-Reply-To: <873e270205e1d3575070dcc093548095.squirrel@gator3286.hostgator.com> References: <3eeaa008601061d9a75cfbd754e180d9.squirrel@gator3286.hostgator.com> <873e270205e1d3575070dcc093548095.squirrel@gator3286.hostgator.com> Message-ID: On 2016-11-20 06:16, Lars via Lazarus wrote: > Docview is an fpGui based project? Yes, and it comes standard with fpGUI. I've also created some pre-built binaries, available on SourceForge for download. Regards, Graeme From mailinglists at geldenhuys.co.uk Sun Nov 20 11:05:27 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Sun, 20 Nov 2016 10:05:27 +0000 Subject: [Lazarus] stale pipe workarounds In-Reply-To: <0c6e272edf3ccfed48eac0cd4282b874.squirrel@gator3286.hostgator.com> References: <0c6e272edf3ccfed48eac0cd4282b874.squirrel@gator3286.hostgator.com> Message-ID: <12877b5c-7fa2-b4a1-b1b7-a38a0a2dc31b@geldenhuys.co.uk> On 2016-11-20 03:50, Lars via Lazarus wrote: > It just makes me scared that there is this hack/fix needed. No need to worry, the Lazarus code is outdated. That fix is already in FPC 2.6.4 too, and any FPC release after that. I've been using SimplyIPC for many things and it has worked very well. eg: Implementing a single instance application feature. The second instance will detected the IPC comms, and use it to tell the first instance what to do (eg: open another file), then the second instance will terminate. I've also implemented a visual logging/debugging program, using simpleIPC, to overcome some shortcomings of Lazarus+GDB debugging. Think Raize Software's CodeSite product for Delphi (but not as advanced). In this tool I did notice one issue with SimpleIPC under Windows only. When I fired 100's of log events per second, under Windows, I lost some messages. I believe I did file a bug report on this. It was some 5-6 years ago, and it was a very specific case. For day-to-day usage, SimpleIPC works perfectly though. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From michael at freepascal.org Sun Nov 20 12:02:27 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Sun, 20 Nov 2016 12:02:27 +0100 (CET) Subject: [Lazarus] stale pipe workarounds In-Reply-To: <12877b5c-7fa2-b4a1-b1b7-a38a0a2dc31b@geldenhuys.co.uk> References: <0c6e272edf3ccfed48eac0cd4282b874.squirrel@gator3286.hostgator.com> <12877b5c-7fa2-b4a1-b1b7-a38a0a2dc31b@geldenhuys.co.uk> Message-ID: On Sun, 20 Nov 2016, Graeme Geldenhuys via Lazarus wrote: > On 2016-11-20 03:50, Lars via Lazarus wrote: >> It just makes me scared that there is this hack/fix needed. > > > No need to worry, the Lazarus code is outdated. That fix is already in > FPC 2.6.4 too, and any FPC release after that. > > I've been using SimplyIPC for many things and it has worked very well. > eg: Implementing a single instance application feature. The second > instance will detected the IPC comms, and use it to tell the first > instance what to do (eg: open another file), then the second instance > will terminate. > > I've also implemented a visual logging/debugging program, using > simpleIPC, to overcome some shortcomings of Lazarus+GDB debugging. Think > Raize Software's CodeSite product for Delphi (but not as advanced). In > this tool I did notice one issue with SimpleIPC under Windows only. When > I fired 100's of log events per second, under Windows, I lost some > messages. I believe I did file a bug report on this. It was some 5-6 > years ago, and it was a very specific case. For day-to-day usage, > SimpleIPC works perfectly though. The windows issue should meanwhile have been fixed, all platforms now use a queue. Michael. From juergen.hestermann at gmx.de Sun Nov 20 18:10:21 2016 From: juergen.hestermann at gmx.de (=?UTF-8?Q?J=c3=bcrgen_Hestermann?=) Date: Sun, 20 Nov 2016 18:10:21 +0100 Subject: [Lazarus] TEdit initial display width Message-ID: <5260de85-fd6c-53a7-8b85-13ef1370e709@gmx.de> I have a form Form1 with an TEdit component Edit1 on it. Edit1 is anchored to Form1 on the left and on the right. I create the Form and set its width on the fly with the following code: ------------------------------------------------------------------------ Form1 := TForm1.Create(Nil); with Form1 do begin Left := 10; Width := 800; WindowState := wsNormal; with Edit1 do begin Text := 'Very long text ....... aaaaaaaaaaaaaa bbbbbbbbbbbbbb cccccccccccccc .......... Very long text'; SelectAll; end; ShowModal; ... end; ------------------------------------------------------------------------ In the designer the width of Form1 is about 500 but I set it to the larger width 800 in the code. Because of the anchoring Edit1 has the same width now. But still, if the text of Edit1 is longer than 500, then the initial display shows an offset as if the width is 500 although there is plenty of space (800) for the long text. When moving around with the cursor I can shift the text to make everything visible but this is not done directly after ShowModal. Is this a known bug? Exists an workaround for it? From bartjunk64 at gmail.com Sun Nov 20 18:14:14 2016 From: bartjunk64 at gmail.com (Bart) Date: Sun, 20 Nov 2016 18:14:14 +0100 Subject: [Lazarus] TEdit initial display width In-Reply-To: <5260de85-fd6c-53a7-8b85-13ef1370e709@gmx.de> References: <5260de85-fd6c-53a7-8b85-13ef1370e709@gmx.de> Message-ID: On 11/20/16, Jürgen Hestermann via Lazarus wrote: > But still, if the text of Edit1 is longer than 500, > then the initial display shows an offset as if > the width is 500 although there is plenty > of space (800) for the long text. Maybe related to http://bugs.freepascal.org/view.php?id=30686 ? A workaround is then to QueueAsyncCall the call to SelectAll ... Bart From giuliano.colla at fastwebnet.it Mon Nov 21 01:30:28 2016 From: giuliano.colla at fastwebnet.it (Giuliano Colla) Date: Mon, 21 Nov 2016 01:30:28 +0100 Subject: [Lazarus] Lazarus and MySQL 5.7 In-Reply-To: <8de0a37c-2fe3-95a7-9b57-dcce68582b8a@geldenhuys.co.uk> References: <1479525914.4974.3.camel@Hercules> <8de0a37c-2fe3-95a7-9b57-dcce68582b8a@geldenhuys.co.uk> Message-ID: <764ed7b4-ab35-98ad-8639-19f099353197@fastwebnet.it> An HTML attachment was scrubbed... URL: From mailinglists at geldenhuys.co.uk Mon Nov 21 10:33:37 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 21 Nov 2016 09:33:37 +0000 Subject: [Lazarus] Lazarus and MySQL 5.7 In-Reply-To: <764ed7b4-ab35-98ad-8639-19f099353197@fastwebnet.it> References: <1479525914.4974.3.camel@Hercules> <8de0a37c-2fe3-95a7-9b57-dcce68582b8a@geldenhuys.co.uk> <764ed7b4-ab35-98ad-8639-19f099353197@fastwebnet.it> Message-ID: <3c581bc7-3581-4d91-3614-f6dcd646184d@geldenhuys.co.uk> On 2016-11-21 00:30, Giuliano Colla via Lazarus wrote: > Lazarus 1.6 includes the package SQLDBLaz which provides support for MySQL from > versions 4.0 to 5.6. Yes, and that "Lazarus Packages" is simply a IDE wrapper around the components included by FPC's fcl-db code. You don't need Lazarus to use any components or classes introduced by FPC. > Looking into the sources, version 5.7 is already there, but the package doesn't > support it It is pretty straight forward to create a new "registered component" line in the Lazarus packages [SqlDBLaz], which in turn will register a icon/component in Lazarus's component palette. Too many developers don't seem to understand the underlying workings of components or classes. If they don't see it in the component palette they don't know how to use it. It is just sad how "RAD development" has dumbed down so many developers. > SQLConnector1.ConnectorType := 'MYSQL 5.7'; // programmatically because the OI doesn't have it > MySQL57Connection1 := TMySQL57Connection.Create(Self); // programmatically because you can't drop it into the form Glad to see you figured it out (RAD didn't get the better of you). Now lets hope others can learn from that. :) Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From mschnell at lumino.de Mon Nov 21 11:29:15 2016 From: mschnell at lumino.de (Michael Schnell) Date: Mon, 21 Nov 2016 11:29:15 +0100 Subject: [Lazarus] Quad precision library for Free Pascal In-Reply-To: <1479510097442-4050382.post@n3.nabble.com> References: <1479510097442-4050382.post@n3.nabble.com> Message-ID: <827e890f-5850-2509-2b3c-72f32b10a787@lumino.de> On 19.11.2016 00:01, Ken Kashmarek via Lazarus wrote: > Does anyone know of or have implemented a quad precision (128-bit) library > for Free Pascal. I see there are some available for C or GCC but not Free > Pascal directly. > > Your feedback is appreciated I read many threads about arbitrary precision fixed point and floating point libraries or FPC, especially in the German Lazarus Forum. Supposedly a rather "official" one is part of the Delphi Jedi project. But I would rather use a proven C library rapped in a DLL/so. -Michael From info at voiceliveeditor.com Mon Nov 21 11:51:33 2016 From: info at voiceliveeditor.com (info at voiceliveeditor.com) Date: Mon, 21 Nov 2016 10:51:33 -0000 Subject: [Lazarus] Quad precision library for Free Pascal In-Reply-To: <827e890f-5850-2509-2b3c-72f32b10a787@lumino.de> References: <1479510097442-4050382.post@n3.nabble.com> <827e890f-5850-2509-2b3c-72f32b10a787@lumino.de> Message-ID: <4C44CAA0735E46FF81D03C8DF5A75158@ianPC> Would this thread be of any use ? http://forum.lazarus.freepascal.org/index.php?topic=27021.0 From denisgolovan at yandex.ru Mon Nov 21 12:19:13 2016 From: denisgolovan at yandex.ru (denisgolovan) Date: Mon, 21 Nov 2016 14:19:13 +0300 Subject: [Lazarus] Quad precision library for Free Pascal In-Reply-To: <1479510097442-4050382.post@n3.nabble.com> References: <1479510097442-4050382.post@n3.nabble.com> Message-ID: <1145531479727153@web8m.yandex.ru> http://www.jhauser.us/arithmetic/SoftFloat.html Looks pretty easy to make .obj/.o wrappers for FPC. See f128* files. Also it's quite portable and lacks excessive abstraction layers. Just basic arithmetics though. 19.11.2016, 02:02, "Ken Kashmarek via Lazarus" : > Does anyone know of or have implemented a quad precision (128-bit) library > for Free Pascal. I see there are some available for C or GCC but not Free > Pascal directly. > > Your feedback is appreciated > > Ken > > -- > View this message in context: http://free-pascal-lazarus.989080.n3.nabble.com/Quad-precision-library-for-Free-Pascal-tp4050382.html > Sent from the Free Pascal - Lazarus mailing list archive at Nabble.com. > -- > _______________________________________________ > Lazarus mailing list > Lazarus at lists.lazarus-ide.org > http://lists.lazarus-ide.org/listinfo/lazarus -- Regards, Denis Golovan From silvioprog at gmail.com Mon Nov 21 19:14:10 2016 From: silvioprog at gmail.com (silvioprog) Date: Mon, 21 Nov 2016 15:14:10 -0300 Subject: [Lazarus] Is the TODO list working? Message-ID: Hello, I've tried to see some TODOs in my code, but it seems the TODO list windows isn't working, however I don't know if it is happening only with my Lazarus copy. Could anybody confirm if it is working properly? Thank you! Environment: Lazarus 1.7 r53323 FPC 3.1.1 x86_64-linux-gtk 2 -- Silvio Clécio -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvioprog at gmail.com Mon Nov 21 19:20:52 2016 From: silvioprog at gmail.com (silvioprog) Date: Mon, 21 Nov 2016 15:20:52 -0300 Subject: [Lazarus] Is the TODO list working? In-Reply-To: References: Message-ID: Oops, On Mon, Nov 21, 2016 at 3:14 PM, silvioprog wrote: [...] > > ... it seems the TODO list windows isn't working, however I don't know ... > I meant: "... it seems the TODO list window isn't working, it always return an empty list, however I don't know ..." -- Silvio Clécio -------------- next part -------------- An HTML attachment was scrubbed... URL: From giuliano.colla at fastwebnet.it Tue Nov 22 01:37:47 2016 From: giuliano.colla at fastwebnet.it (Giuliano Colla) Date: Tue, 22 Nov 2016 01:37:47 +0100 Subject: [Lazarus] Lazarus and MySQL 5.7 In-Reply-To: <3c581bc7-3581-4d91-3614-f6dcd646184d@geldenhuys.co.uk> References: <1479525914.4974.3.camel@Hercules> <8de0a37c-2fe3-95a7-9b57-dcce68582b8a@geldenhuys.co.uk> <764ed7b4-ab35-98ad-8639-19f099353197@fastwebnet.it> <3c581bc7-3581-4d91-3614-f6dcd646184d@geldenhuys.co.uk> Message-ID: Il 21/11/2016 10:33, Graeme Geldenhuys via Lazarus ha scritto: > It is pretty straight forward to create a new "registered component" > line in the Lazarus packages [SqlDBLaz], which in turn will register a > icon/component in Lazarus's component palette. Actually it took me almost a full quarter of an hour to do it. The most of the time was spent to draw the proper Icon, not too much different from the others, and to detect a typo. I'm lazy and I like RAD tools, because finding all the published properties neatly listed in the OI saves me time and mistakes. I cannot contribute the patch right now because I didn't make it on an SVN version, but whoever is interested can get a patched version of SqlDBLaz for Lazarus 1.6 supporting MySql 5.7 from this link: /www.bononiadocta.it/Lazarus/Sqldb.tar.bz2 Just use it to replace the sqldb folder in the $PATH$TO$LAZARUS/components folder and rebuild the IDE. Giuliano -------------- next part -------------- An HTML attachment was scrubbed... URL: From giuliano.colla at fastwebnet.it Tue Nov 22 01:52:25 2016 From: giuliano.colla at fastwebnet.it (Giuliano Colla) Date: Tue, 22 Nov 2016 01:52:25 +0100 Subject: [Lazarus] Lazarus and MySQL 5.7 In-Reply-To: References: <1479525914.4974.3.camel@Hercules> <8de0a37c-2fe3-95a7-9b57-dcce68582b8a@geldenhuys.co.uk> <764ed7b4-ab35-98ad-8639-19f099353197@fastwebnet.it> <3c581bc7-3581-4d91-3614-f6dcd646184d@geldenhuys.co.uk> Message-ID: <547b6267-dd19-7e2f-31a2-be31fedbe488@fastwebnet.it> Sorry, the link below is broken. This is the good one: http://www.bononiadocta.it/Lazarus/Sqldb.tar.bz2 Il 22/11/2016 01:37, Giuliano Colla ha scritto: > I cannot contribute the patch right now because I didn't make it on an > SVN version, but whoever is interested can get a patched version of > SqlDBLaz for Lazarus 1.6 supporting MySql 5.7 from this link: > > /www.bononiadocta.it/Lazarus/Sqldb.tar.bz2 > > Just use it to replace the sqldb folder in the > $PATH$TO$LAZARUS/components folder and rebuild the IDE. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lacak at zoznam.sk Tue Nov 22 07:34:00 2016 From: lacak at zoznam.sk (LacaK) Date: Tue, 22 Nov 2016 07:34:00 +0100 Subject: [Lazarus] Lazarus and MySQL 5.7 In-Reply-To: <547b6267-dd19-7e2f-31a2-be31fedbe488@fastwebnet.it> References: <1479525914.4974.3.camel@Hercules> <8de0a37c-2fe3-95a7-9b57-dcce68582b8a@geldenhuys.co.uk> <764ed7b4-ab35-98ad-8639-19f099353197@fastwebnet.it> <3c581bc7-3581-4d91-3614-f6dcd646184d@geldenhuys.co.uk> <547b6267-dd19-7e2f-31a2-be31fedbe488@fastwebnet.it> Message-ID: <40ab87e7-98a9-b54b-ab87-34f89dc4feaf@zoznam.sk> Hi, Please create bug report on http://bugs.freepascal.org and attach your modified files (at least ;-)) -Laco. > > Sorry, the link below is broken. > > This is the good one: > > http://www.bononiadocta.it/Lazarus/Sqldb.tar.bz2 > > > Il 22/11/2016 01:37, Giuliano Colla ha scritto: >> I cannot contribute the patch right now because I didn't make it on >> an SVN version, but whoever is interested can get a patched version >> of SqlDBLaz for Lazarus 1.6 supporting MySql 5.7 from this link: >> >> /www.bononiadocta.it/Lazarus/Sqldb.tar.bz2 >> >> Just use it to replace the sqldb folder in the >> $PATH$TO$LAZARUS/components folder and rebuild the IDE. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at z505.com Tue Nov 22 14:53:33 2016 From: noreply at z505.com (Lars) Date: Tue, 22 Nov 2016 06:53:33 -0700 Subject: [Lazarus] Lazarus and MySQL 5.7 In-Reply-To: <3c581bc7-3581-4d91-3614-f6dcd646184d@geldenhuys.co.uk> References: <1479525914.4974.3.camel@Hercules> <8de0a37c-2fe3-95a7-9b57-dcce68582b8a@geldenhuys.co.uk> <764ed7b4-ab35-98ad-8639-19f099353197@fastwebnet.it> <3c581bc7-3581-4d91-3614-f6dcd646184d@geldenhuys.co.uk> Message-ID: <34143a63bce9f06f5732f9c3b4cf3f9c.squirrel@gator3286.hostgator.com> On Mon, November 21, 2016 2:33 am, Graeme Geldenhuys via Lazarus wrote: > On 2016-11-21 00:30, Giuliano Colla via Lazarus wrote: > >> Lazarus 1.6 includes the package SQLDBLaz which provides support for >> MySQL from >> versions 4.0 to 5.6. > > Yes, and that "Lazarus Packages" is simply a IDE wrapper around the > components included by FPC's fcl-db code. You don't need Lazarus to use any > components or classes introduced by FPC. > > >> Looking into the sources, version 5.7 is already there, but the package >> doesn't support it > > It is pretty straight forward to create a new "registered component" > line in the Lazarus packages [SqlDBLaz], which in turn will register a > icon/component in Lazarus's component palette. > > Too many developers don't seem to understand the underlying workings of > components or classes. If they don't see it in the component palette they > don't know how to use it. It is just sad how "RAD development" has dumbed > down so many developers. > But this is one issue with components is once you create your own rolled component, it becomes a non standard component available in only your IDE and no one elses... Every time I think about inheriting a component and creating my own, I stop myself and try to just use the built in component palette ones wherever possible.... As sort of a "I know the standard components will always be there" but my own rolled components may not.. if I do a fresh install of an IDE on another system, etc. Then it requires using non standard components. But as for mysql, obviously once someone ports the component it will become standard and be shipped with the ide. I'm speaking of other cases. Like say inheriting a button and creating my own... then I'm using a non standard component and it makes me scared. Just what I've found anyway, that the biggest scariest thing about creating your own components, is they are now non standard not shipped with the IDE. I first realized this when I needed a button that had new behavior in Delphi.. so I created my own. Then I realized that any time I install the IDE on a system, I now have the headache of having to install a non standard component in order to use it. As powerful as creating your own components is, it also comes with some drawbacks. From mailinglists at geldenhuys.co.uk Tue Nov 22 15:54:34 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Tue, 22 Nov 2016 14:54:34 +0000 Subject: [Lazarus] Lazarus and MySQL 5.7 In-Reply-To: <34143a63bce9f06f5732f9c3b4cf3f9c.squirrel@gator3286.hostgator.com> References: <1479525914.4974.3.camel@Hercules> <8de0a37c-2fe3-95a7-9b57-dcce68582b8a@geldenhuys.co.uk> <764ed7b4-ab35-98ad-8639-19f099353197@fastwebnet.it> <3c581bc7-3581-4d91-3614-f6dcd646184d@geldenhuys.co.uk> <34143a63bce9f06f5732f9c3b4cf3f9c.squirrel@gator3286.hostgator.com> Message-ID: On 2016-11-22 13:53, Lars via Lazarus wrote: > I first realized this when I needed a button that had new behavior in > Delphi.. so I created my own. Then I realized that any time I install the > IDE on a system, I now have the headache of having to install a non > standard component in order to use it. That comes down to the fact that the Delphi, Lazarus and MSEide built-in form designers can't handle component that aren't registered with the IDE. You have no such problem with fpGUI's Visual Forms Designer. [kind of off-topic to what I suggested in my previous post] Either way, I don't think it is that bad using custom components you wrote, based on standard components. Such components source code will normally be included with your own applications so no problems compiling the app. Using 100's of 3rd party components (so often seen in Delphi projects) is a timebomb though. Even worse, if you didn't have the full source code of those 3rd party components. We got bitten badly by that in the D7 and Kylix 3 days. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From luizamericop at gmail.com Tue Nov 22 18:28:31 2016 From: luizamericop at gmail.com (Luiz Americo Pereira Camara) Date: Tue, 22 Nov 2016 14:28:31 -0300 Subject: [Lazarus] Clarification about VirtualTreeView repositories (lazarus-ccr/virtualtreeview-new deprecation) Message-ID: Currently there are three repositories of VirtualTreeView LCL port. In Lazarus-CCR: virtualtreeview: first port, long unmaintained virtualtreeview-new: original repository of the current port In GitHub: https://github.com/blikblum/VirtualTreeView-Lazarus : active repository of current port Some history how we got that: http://forum.lazarus.freepascal.org/index.php/topic,26581.msg174292.html#msg174292 In order to bring some sanity, i added a note in the Lazarus-CCR/virtualtreeview-new repository about its deprecation.The idea is to remove in the near future. The development history, for any need, will be kept at https://github.com/blikblum/VirtualTreeView-Lazarus-History I don't own rights about of Lazarus-CCR/virtualtreeview repository so not comfortable in taking any decision about it. I will let for Lazarus-CCR admins decide what to do with it Luiz -------------- next part -------------- An HTML attachment was scrubbed... URL: From denisgolovan at yandex.ru Tue Nov 22 18:33:43 2016 From: denisgolovan at yandex.ru (denisgolovan) Date: Tue, 22 Nov 2016 20:33:43 +0300 Subject: [Lazarus] Clarification about VirtualTreeView repositories (lazarus-ccr/virtualtreeview-new deprecation) In-Reply-To: References: Message-ID: <331981479836023@web37m.yandex.ru> An HTML attachment was scrubbed... URL: From nc-gaertnma at netcologne.de Tue Nov 22 18:46:31 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Tue, 22 Nov 2016 18:46:31 +0100 Subject: [Lazarus] Is the TODO list working? In-Reply-To: References: Message-ID: <20161122184631.356a336c@limapholos.matflo.wg> On Mon, 21 Nov 2016 15:20:52 -0300 silvioprog via Lazarus wrote: > Oops, > > On Mon, Nov 21, 2016 at 3:14 PM, silvioprog wrote: > [...] > > > > ... it seems the TODO list windows isn't working, however I don't know ... > > > > I meant: "... it seems the TODO list window isn't working, it always return > an empty list, however I don't know ..." It works here. http://wiki.lazarus.freepascal.org/IDE_Window:_ToDo_List Mattias From werner.pamler at freenet.de Tue Nov 22 18:44:17 2016 From: werner.pamler at freenet.de (Werner Pamler) Date: Tue, 22 Nov 2016 18:44:17 +0100 Subject: [Lazarus] Clarification about VirtualTreeView repositories (lazarus-ccr/virtualtreeview-new deprecation) In-Reply-To: References: Message-ID: <3dc3b4a9-5430-f8eb-dc07-15fa9b78bb3f@freenet.de> Am 22.11.2016 um 18:28 schrieb Luiz Americo Pereira Camara via Lazarus: > Currently there are three repositories of VirtualTreeView LCL port. > > In Lazarus-CCR: > > virtualtreeview: first port, long unmaintained > virtualtreeview-new: original repository of the current port > > In GitHub: > https://github.com/blikblum/VirtualTreeView-Lazarus : active > repository of current port > > Some history how we got that: > http://forum.lazarus.freepascal.org/index.php/topic,26581.msg174292.html#msg174292 > > In order to bring some sanity, i added a note in the > Lazarus-CCR/virtualtreeview-new repository about its deprecation.The > idea is to remove in the near future. The development history, for any > need, will be kept at > https://github.com/blikblum/VirtualTreeView-Lazarus-History > > I don't own rights about of Lazarus-CCR/virtualtreeview repository so > not comfortable in taking any decision about it. I will let for > Lazarus-CCR admins decide what to do with it > Luiz, I like your idea to add a non-commented hint to the main source file. So every user will get notified at compilation that he is using an unsupported version. Shouldn't we do the same with - ZVDateTimeCtrls (in in Lazarus/components/DateTimeCtrls - csvdocument (is in fpc sources/packages(fp-base) - lclextension (belongs to VTV somehow) ? There are other folders such as acs, kontrols, htmlport, and probably some more which seem to have active maintainers somewhere on github as well. What to do with them? From nc-gaertnma at netcologne.de Tue Nov 22 18:53:16 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Tue, 22 Nov 2016 18:53:16 +0100 Subject: [Lazarus] Clarification about VirtualTreeView repositories (lazarus-ccr/virtualtreeview-new deprecation) In-Reply-To: References: Message-ID: <20161122185316.4cc324e3@limapholos.matflo.wg> On Tue, 22 Nov 2016 14:28:31 -0300 Luiz Americo Pereira Camara via Lazarus wrote: > Currently there are three repositories of VirtualTreeView LCL port. > > In Lazarus-CCR: > > virtualtreeview: first port, long unmaintained > virtualtreeview-new: original repository of the current port Proposal: Delete files in those folders and add README.txt pointing to new repository. Mattias From lazarus at kluug.net Tue Nov 22 18:58:21 2016 From: lazarus at kluug.net (Ondrej Pokorny) Date: Tue, 22 Nov 2016 18:58:21 +0100 Subject: [Lazarus] Clarification about VirtualTreeView repositories (lazarus-ccr/virtualtreeview-new deprecation) In-Reply-To: <20161122185316.4cc324e3@limapholos.matflo.wg> References: <20161122185316.4cc324e3@limapholos.matflo.wg> Message-ID: On 22.11.2016 18:53, Mattias Gaertner via Lazarus wrote: > On Tue, 22 Nov 2016 14:28:31 -0300 > Luiz Americo Pereira Camara via Lazarus > wrote: > >> Currently there are three repositories of VirtualTreeView LCL port. >> >> In Lazarus-CCR: >> >> virtualtreeview: first port, long unmaintained >> virtualtreeview-new: original repository of the current port > Proposal: > Delete files in those folders and add README.txt pointing to new > repository. What will be the new one and only repository? The one on GitHub or a new in Lazarus/components? Ondrej From luizamericop at gmail.com Tue Nov 22 19:02:40 2016 From: luizamericop at gmail.com (Luiz Americo Pereira Camara) Date: Tue, 22 Nov 2016 15:02:40 -0300 Subject: [Lazarus] Clarification about VirtualTreeView repositories (lazarus-ccr/virtualtreeview-new deprecation) In-Reply-To: References: <20161122185316.4cc324e3@limapholos.matflo.wg> Message-ID: 2016-11-22 14:58 GMT-03:00 Ondrej Pokorny via Lazarus < lazarus at lists.lazarus-ide.org>: > On 22.11.2016 18:53, Mattias Gaertner via Lazarus wrote: > >> Proposal: >> Delete files in those folders and add README.txt pointing to new >> repository. >> > > What will be the new one and only repository? The one on GitHub or a new > in Lazarus/components? > > GitHub. Is necessary to sync with main repository Luiz -------------- next part -------------- An HTML attachment was scrubbed... URL: From luizamericop at gmail.com Tue Nov 22 19:05:36 2016 From: luizamericop at gmail.com (Luiz Americo Pereira Camara) Date: Tue, 22 Nov 2016 15:05:36 -0300 Subject: [Lazarus] Clarification about VirtualTreeView repositories (lazarus-ccr/virtualtreeview-new deprecation) In-Reply-To: <3dc3b4a9-5430-f8eb-dc07-15fa9b78bb3f@freenet.de> References: <3dc3b4a9-5430-f8eb-dc07-15fa9b78bb3f@freenet.de> Message-ID: 2016-11-22 14:44 GMT-03:00 Werner Pamler via Lazarus < lazarus at lists.lazarus-ide.org>: > > Luiz, I like your idea to add a non-commented hint to the main source > file. So every user will get notified at compilation that he is using an > unsupported version. > > Shouldn't we do the same with > - ZVDateTimeCtrls (in in Lazarus/components/DateTimeCtrls > - csvdocument (is in fpc sources/packages(fp-base) > The maintainers or CCR admins should look at it > - lclextension (belongs to VTV somehow) ? > Someone else created a copy of it. I think who did must decide what to do Luiz -------------- next part -------------- An HTML attachment was scrubbed... URL: From bartjunk64 at gmail.com Tue Nov 22 22:34:30 2016 From: bartjunk64 at gmail.com (Bart) Date: Tue, 22 Nov 2016 22:34:30 +0100 Subject: [Lazarus] Is the TODO list working? In-Reply-To: <20161122184631.356a336c@limapholos.matflo.wg> References: <20161122184631.356a336c@limapholos.matflo.wg> Message-ID: On 11/22/16, Mattias Gaertner via Lazarus wrote: > http://wiki.lazarus.freepascal.org/IDE_Window:_ToDo_List Most of my ToDo's are in //ToDo: format, which I see is not handled. I must admit I never tried that package. Bart From werner.pamler at freenet.de Tue Nov 22 23:44:07 2016 From: werner.pamler at freenet.de (Werner Pamler) Date: Tue, 22 Nov 2016 23:44:07 +0100 Subject: [Lazarus] Clarification about VirtualTreeView repositories (lazarus-ccr/virtualtreeview-new deprecation) In-Reply-To: References: <3dc3b4a9-5430-f8eb-dc07-15fa9b78bb3f@freenet.de> Message-ID: <45364672-deee-c3c9-9be5-d5c77a7dfe3d@freenet.de> Am 22.11.2016 um 19:05 schrieb Luiz Americo Pereira Camara via Lazarus: > > 2016-11-22 14:44 GMT-03:00 Werner Pamler via Lazarus > >: > > > Luiz, I like your idea to add a non-commented hint to the main > source file. So every user will get notified at compilation that > he is using an unsupported version. > > Shouldn't we do the same with > - ZVDateTimeCtrls (in in Lazarus/components/DateTimeCtrls > - csvdocument (is in fpc sources/packages(fp-base) > > > The maintainers or CCR admins should look at it Who is CCR admin? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at geldenhuys.co.uk Wed Nov 23 12:05:36 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 23 Nov 2016 11:05:36 +0000 Subject: [Lazarus] Is the whole of Lazarus-CCR moving to Github? Message-ID: <58fe6a98-a349-8d12-c5a9-d128357a8fe1@geldenhuys.co.uk> Hi, Two days ago I got an invite to join the Lazarus CCR organization on Github - probably because I'm the maintainer of DCPCrypt on Lazarus CCR on SourceForge. The invitation came from 'lainz'. Umm, I wanted to post the GitHub link, now I see they hid (or removed) all the repositories. https://github.com/lazarusccr What is going on? Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From juha.manninen62 at gmail.com Wed Nov 23 14:13:26 2016 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Wed, 23 Nov 2016 15:13:26 +0200 Subject: [Lazarus] Is the whole of Lazarus-CCR moving to Github? In-Reply-To: <58fe6a98-a349-8d12-c5a9-d128357a8fe1@geldenhuys.co.uk> References: <58fe6a98-a349-8d12-c5a9-d128357a8fe1@geldenhuys.co.uk> Message-ID: On Wed, Nov 23, 2016 at 1:05 PM, Graeme Geldenhuys via Lazarus wrote: > What is going on? :) Lainz got over-enthusiastic and forked the whole CCR repo. Later the forks were deleted and the lazarusccr GitHub organization was recreated. Now it is for projects for anybody who wants to maintain stuff there. http://forum.lazarus.freepascal.org/index.php/topic,34297.msg229638.html#msg229638 Juha From mailinglists at geldenhuys.co.uk Wed Nov 23 15:14:11 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 23 Nov 2016 14:14:11 +0000 Subject: [Lazarus] Is the whole of Lazarus-CCR moving to Github? In-Reply-To: References: <58fe6a98-a349-8d12-c5a9-d128357a8fe1@geldenhuys.co.uk> Message-ID: On 2016-11-23 13:13, Juha Manninen via Lazarus wrote: > Now it is for projects for anybody who wants to maintain stuff there. Thanks for explaining. You guys do realise that SourceForge does support Git repositories, and in fact DCPCrypt is already in a Git repository in Lazarus-CCR on SourceForge: https://sourceforge.net/p/lazarus-ccr/_list/git …and a directly link to DCPCrypt: https://sourceforge.net/p/lazarus-ccr/dcpcrypt/ci/master/tree/ So if it is purely down to moving the 100’s of Lazarus CCR projects out of a single SubVersion repository and into smaller and separate Git repositories (a good move), you could have done that in SourceForge. Saying that, I am a big fan of GitHub too. ;-) Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From silvioprog at gmail.com Wed Nov 23 18:25:44 2016 From: silvioprog at gmail.com (silvioprog) Date: Wed, 23 Nov 2016 14:25:44 -0300 Subject: [Lazarus] Is the TODO list working? In-Reply-To: References: <20161122184631.356a336c@limapholos.matflo.wg> Message-ID: Oops, On Tue, Nov 22, 2016 at 11:46 PM, silvioprog wrote: [...] > Can you do more two tests?: > I meant "could you do more two tests?". ^^' -- Silvio Clécio -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvioprog at gmail.com Wed Nov 23 04:06:33 2016 From: silvioprog at gmail.com (silvioprog) Date: Wed, 23 Nov 2016 00:06:33 -0300 Subject: [Lazarus] Is the TODO list working? In-Reply-To: References: <20161122184631.356a336c@limapholos.matflo.wg> Message-ID: On Tue, Nov 22, 2016 at 6:34 PM, Bart via Lazarus < lazarus at lists.lazarus-ide.org> wrote: > On 11/22/16, Mattias Gaertner via Lazarus > wrote: > > > http://wiki.lazarus.freepascal.org/IDE_Window:_ToDo_List > > Most of my ToDo's are in //ToDo: format, which I see is not handled. > > I must admit I never tried that package. > > Bart I can see three valid TODOs (please see attached picture), but only when I add the unit to the lpi. The problem happen when I have the unit declared only in the lpr uses clause. So, for Delphi compatibility it should look TODOs in the opened units at the source editor tabs too. (Lazarus is flexible, so it would be nice to have an extra option: search TODOs at project's folder too :-) ) -- Silvio Clécio -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 01.png Type: image/png Size: 75322 bytes Desc: not available URL: From md at delfire.net Wed Nov 23 19:15:39 2016 From: md at delfire.net (Marcos Douglas B. Santos) Date: Wed, 23 Nov 2016 16:15:39 -0200 Subject: [Lazarus] Is the TODO list working? In-Reply-To: References: <20161122184631.356a336c@limapholos.matflo.wg> Message-ID: On Wed, Nov 23, 2016 at 1:06 AM, silvioprog via Lazarus wrote: > I can see three valid TODOs (please see attached picture), but only when I > add the unit to the lpi. The problem happen when I have the unit declared > only in the lpr uses clause. > > So, for Delphi compatibility it should look TODOs in the opened units at the > source editor tabs too. > > (Lazarus is flexible, so it would be nice to have an extra option: search > TODOs at project's folder too :-) ) +1 Perhaps search in all path that project uses. I have many projects with no unit included. I just point paths. — Marcos Douglas From l.rame at griensu.com Wed Nov 23 19:27:21 2016 From: l.rame at griensu.com (=?UTF-8?Q?Leonardo_M._Ram=c3=a9?=) Date: Wed, 23 Nov 2016 15:27:21 -0300 Subject: [Lazarus] Cannot cross build from Linux x86_64 to i386 Message-ID: Hi, I've built FPC 3.1.1 (ppc386) from trunk then I'm trying to build a project from Lazarus and I'm getting this: /usr/lib32/libc_nonshared.a(elf-init.oS): En la función `__libc_csu_init': I'm on XUbuntu 16.04 64bits. P.S.: I created /usr/bin/i386-linux-as with this content: #!/bin/bash as --32 "$@" and /usr/bin/i386-linux-ld: #!/bin/bash ld -melf_i386 "$@" Regards, -- Leonardo M. Ramé Medical IT - Griensu S.A. Av. Colón 636 - Piso 8 Of. A X5000EPT -- Córdoba Tel.: +54(351)4246924 +54(351)4247788 +54(351)4247979 int. 19 Cel.: +54 9 (011) 40871877 From l.rame at griensu.com Wed Nov 23 20:23:46 2016 From: l.rame at griensu.com (=?UTF-8?Q?Leonardo_M._Ram=c3=a9?=) Date: Wed, 23 Nov 2016 16:23:46 -0300 Subject: [Lazarus] Cannot cross build from Linux x86_64 to i386 In-Reply-To: References: Message-ID: <39d978ec-4dda-c59f-4b0c-7b10cc97618c@griensu.com> El 23/11/16 a las 15:27, Leonardo M. Ramé via Lazarus escribió: > Hi, I've built FPC 3.1.1 (ppc386) from trunk then I'm trying to build a > project from Lazarus and I'm getting this: > > /usr/lib32/libc_nonshared.a(elf-init.oS): En la función `__libc_csu_init': > > > I'm on XUbuntu 16.04 64bits. > > > P.S.: I created /usr/bin/i386-linux-as with this content: > > #!/bin/bash > as --32 "$@" > > and /usr/bin/i386-linux-ld: > > #!/bin/bash > ld -melf_i386 "$@" > > > Regards, > Fixed by copying /usr/lib32/crtn.o and /usr/lib/crti.o to /usr/lib/i386-linux-gnu -- Leonardo M. Ramé Medical IT - Griensu S.A. Av. Colón 636 - Piso 8 Of. A X5000EPT -- Córdoba Tel.: +54(351)4246924 +54(351)4247788 +54(351)4247979 int. 19 Cel.: +54 9 (011) 40871877 From nc-gaertnma at netcologne.de Thu Nov 24 01:44:30 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Thu, 24 Nov 2016 01:44:30 +0100 Subject: [Lazarus] Is the TODO list working? In-Reply-To: References: <20161122184631.356a336c@limapholos.matflo.wg> Message-ID: <20161124014430.7eb6de2b@limapholos.matflo.wg> On Wed, 23 Nov 2016 00:06:33 -0300 silvioprog via Lazarus wrote: >[...] > So, for Delphi compatibility it should look TODOs in the opened units at > the source editor tabs too. Feel free to add an option to search in source editor units too. Mattias From nc-gaertnma at netcologne.de Thu Nov 24 01:45:29 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Thu, 24 Nov 2016 01:45:29 +0100 Subject: [Lazarus] Is the TODO list working? In-Reply-To: References: <20161122184631.356a336c@limapholos.matflo.wg> Message-ID: <20161124014529.55cfb915@limapholos.matflo.wg> On Tue, 22 Nov 2016 22:34:30 +0100 Bart via Lazarus wrote: > On 11/22/16, Mattias Gaertner via Lazarus wrote: > > > http://wiki.lazarus.freepascal.org/IDE_Window:_ToDo_List > > Most of my ToDo's are in //ToDo: format, which I see is not handled. I updated the wiki page. It supports //, {} and (**). Mattias From nc-gaertnma at netcologne.de Thu Nov 24 01:46:51 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Thu, 24 Nov 2016 01:46:51 +0100 Subject: [Lazarus] Is the TODO list working? In-Reply-To: References: <20161122184631.356a336c@limapholos.matflo.wg> Message-ID: <20161124014651.6097ae1f@limapholos.matflo.wg> On Wed, 23 Nov 2016 16:15:39 -0200 "Marcos Douglas B. Santos via Lazarus" wrote: >[...] > Perhaps search in all path that project uses. > I have many projects with no unit included. I just point paths. It now searches in all used project units, excluding used packages. Formerly it only searched in the units listed in the project inspector. Mattias From md at delfire.net Thu Nov 24 12:01:52 2016 From: md at delfire.net (Marcos Douglas B. Santos) Date: Thu, 24 Nov 2016 09:01:52 -0200 Subject: [Lazarus] Is the TODO list working? In-Reply-To: <20161124014651.6097ae1f@limapholos.matflo.wg> References: <20161122184631.356a336c@limapholos.matflo.wg> <20161124014651.6097ae1f@limapholos.matflo.wg> Message-ID: On Wed, Nov 23, 2016 at 10:46 PM, Mattias Gaertner via Lazarus wrote: > > It now searches in all used project units, excluding used packages. > Formerly it only searched in the units listed in the project inspector Hmm, I didn't know... Thanks for that. -- Marcos Douglas From silvioprog at gmail.com Fri Nov 25 06:24:31 2016 From: silvioprog at gmail.com (silvioprog) Date: Fri, 25 Nov 2016 02:24:31 -0300 Subject: [Lazarus] Is the TODO list working? In-Reply-To: <20161124014651.6097ae1f@limapholos.matflo.wg> References: <20161122184631.356a336c@limapholos.matflo.wg> <20161124014651.6097ae1f@limapholos.matflo.wg> Message-ID: On Wed, Nov 23, 2016 at 9:46 PM, Mattias Gaertner via Lazarus < lazarus at lists.lazarus-ide.org> wrote: [...] > Formerly it only searched in the units listed in the project inspector. > > Mattias I sent a patch (issue #31006 ) extending IDEIntf and allowing the ToDo window to find units opened as tabs at source editor. It's easy to test: 1. open Lazarus keeping its default new project opened; 2. choose some unit (declaring some ToDo) outside project and drop that to the project, now it is just a tab at source editor; 3. open the ToDo window and finally you can see that unit's ToDo (or any opened). It works in same way on Delphi, and it would be nice if Lazarus could provide this same functionality. :-) -- Silvio Clécio -------------- next part -------------- An HTML attachment was scrubbed... URL: From nc-gaertnma at netcologne.de Fri Nov 25 13:57:27 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Fri, 25 Nov 2016 13:57:27 +0100 Subject: [Lazarus] Is the TODO list working? In-Reply-To: References: <20161122184631.356a336c@limapholos.matflo.wg> <20161124014651.6097ae1f@limapholos.matflo.wg> Message-ID: <20161125135727.29571271@limapholos.matflo.wg> On Fri, 25 Nov 2016 02:24:31 -0300 silvioprog via Lazarus wrote: > On Wed, Nov 23, 2016 at 9:46 PM, Mattias Gaertner via Lazarus < > lazarus at lists.lazarus-ide.org> wrote: > [...] > > > Formerly it only searched in the units listed in the project inspector. > > > > Mattias > > > I sent a patch (issue #31006 ) > extending IDEIntf and allowing the ToDo window to find units opened as tabs > at source editor. It's easy to test: > > 1. open Lazarus keeping its default new project opened; > 2. choose some unit (declaring some ToDo) outside project and drop that to > the project, now it is just a tab at source editor; What do you mean with "drop that to the project"? > 3. open the ToDo window and finally you can see that unit's ToDo (or any > opened). > > It works in same way on Delphi, and it would be nice if Lazarus could > provide this same functionality. :-) Mattias From nc-gaertnma at netcologne.de Fri Nov 25 15:07:06 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Fri, 25 Nov 2016 15:07:06 +0100 Subject: [Lazarus] stale pipe workarounds In-Reply-To: <23900dfe-71ef-7ad4-3e0b-f9ce9be013e0@aol.com> References: <0c6e272edf3ccfed48eac0cd4282b874.squirrel@gator3286.hostgator.com> <23900dfe-71ef-7ad4-3e0b-f9ce9be013e0@aol.com> Message-ID: <20161125150706.141a5924@limapholos.matflo.wg> On Sun, 20 Nov 2016 01:01:13 -0500 Andrew Haines via Lazarus wrote: >[...] > FPC now has this stale pipe detection included. The fix was added to the > code lazarus uses until the next official version of FPC was released > and went into the develop version of fpc in early 2012. At this point it > could probably be removed form lazarus since there have been multiple > releases of fpc since then. > > https://github.com/graemeg/freepascal/blob/master/packages/fcl-process/src/unix/simpleipc.inc#L97 Yes, it was already in FPC 2.6.4. So, the lhelpcontrol $IF FPC_FULLVERSION<20700 is wrong. I removed the old workaround. Mattias From silvioprog at gmail.com Sat Nov 26 04:52:16 2016 From: silvioprog at gmail.com (silvioprog) Date: Sat, 26 Nov 2016 00:52:16 -0300 Subject: [Lazarus] Is the TODO list working? In-Reply-To: <20161125135727.29571271@limapholos.matflo.wg> References: <20161122184631.356a336c@limapholos.matflo.wg> <20161124014651.6097ae1f@limapholos.matflo.wg> <20161125135727.29571271@limapholos.matflo.wg> Message-ID: On Fri, Nov 25, 2016 at 9:57 AM, Mattias Gaertner via Lazarus < lazarus at lists.lazarus-ide.org> wrote: [...] > What do you mean with "drop that to the project"? Oops, sorry, I meant when a user drag some unit (even units from other projects) from his system file manager and drop to the source editor. So I reopened the issue sending a new patch applying a big upgrade in the ToDo list window. (ps. I don't know why but I'm not receiving all e-mails from the Lazarus list, I was lucky I've opened the archives link and saw your message there :-/ - http://lists.lazarus-ide.org/pipermail/lazarus/2016-November /thread.html) -- Silvio Clécio -------------- next part -------------- An HTML attachment was scrubbed... URL: From nc-gaertnma at netcologne.de Sat Nov 26 14:47:50 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Sat, 26 Nov 2016 14:47:50 +0100 Subject: [Lazarus] Lazarus and MySQL 5.7 In-Reply-To: <1479525914.4974.3.camel@Hercules> References: <1479525914.4974.3.camel@Hercules> Message-ID: <20161126144750.23172cd6@limapholos.matflo.wg> On Fri, 18 Nov 2016 21:25:14 -0600 "Terry A. Haimann via Lazarus" wrote: > What version of Lazarus can connect to MySQL 5.7 using TSqlConnector? > My laptop has 1.6 and does not seem to be able to connect using that > component. I added TMySQL57Connection to trunk (1.7). Mattias From jesusrmx at gmail.com Mon Nov 28 10:06:47 2016 From: jesusrmx at gmail.com (Jesus Reyes A.) Date: Mon, 28 Nov 2016 03:06:47 -0600 Subject: [Lazarus] ActiveX, TOLEControl In-Reply-To: <58079A47.1000507@avidsoft.com.hk> References: <89ca3774-acbe-d663-a909-23cd488f0eff@zoznam.sk> <58073B15.60909@avidsoft.com.hk> <461cdd29-32ba-da33-5cb5-bb6dbf5c713e@zoznam.sk> <58079A47.1000507@avidsoft.com.hk> Message-ID: En Wed, 19 Oct 2016 11:07:35 -0500, Dennis via Lazarus escribió: > > > LacaK via Lazarus wrote: >> >>> >>> >>>> Hi *, >>>> >>>> I need help with OCX component (not visual I guess), which I need use >>>> in Lazarus application (to control another application, which >>>> supplies this OCX control). >>>> I have imported type library using importtl.exe (new unit was created >>>> successfully) >>>> >>>> Then in program I have created instance: >>>> v := CreateOleObject('SCAPS.ScSamlightClientCtrl'); >>>> or >>>> intf := CreateComObject(CLASS_ScSamlightClientCtrl) as >>>> _DSamlight_client_ctrl_ocx; >>> What is the type of your V or intf variable? >> >> V: OLEVariant; >> intf: _DSamlight_client_ctrl_ocx; >> >>> I am wild guessing maybe they are not proper referenced type so the >>> object is created and then immediately freed. >> >> There is something strange behind scene. I have tried various methods: > I remember in Delphi, I sometimes have to call CoInitialize and > CoUninitialize. > Not sure if FPC has to do the same. > Have you tried that? > > Dennis -- Usando el cliente de correo de Opera: http://www.opera.com/mail/ From mailinglists at geldenhuys.co.uk Mon Nov 28 11:01:20 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 28 Nov 2016 10:01:20 +0000 Subject: [Lazarus] Non-visual component tray Message-ID: Finally somebody has implemented a non-visual component tray add-on (sitting next to your visual designed form). Something I've been saying for years - and that should come standard with Delphi and Lazarus. https://github.com/lynatan/ComponentTray Non-visual components don't belong on the designer form itself. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From hnb.code at gmail.com Mon Nov 28 11:19:32 2016 From: hnb.code at gmail.com (Maciej Izak) Date: Mon, 28 Nov 2016 11:19:32 +0100 Subject: [Lazarus] Non-visual component tray In-Reply-To: References: Message-ID: 2016-11-28 11:01 GMT+01:00 Graeme Geldenhuys via Lazarus < lazarus at lists.lazarus-ide.org>: > Non-visual components don't belong on the designer form itself. It is simple to do with Sparta docked solution. -- Best regards, Maciej Izak -------------- next part -------------- An HTML attachment was scrubbed... URL: From lazarus at kluug.net Mon Nov 28 11:42:12 2016 From: lazarus at kluug.net (Ondrej Pokorny) Date: Mon, 28 Nov 2016 11:42:12 +0100 Subject: [Lazarus] Non-visual component tray In-Reply-To: References: Message-ID: On 28.11.2016 11:01, Graeme Geldenhuys via Lazarus wrote: > Finally somebody has implemented a non-visual component tray add-on > (sitting next to your visual designed form). Good that it's a Lazarus solution! > Something I've been saying for years - and that should come standard with Delphi and Lazarus. Patches are welcome. Ondrej From mailinglists at geldenhuys.co.uk Mon Nov 28 11:55:40 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 28 Nov 2016 10:55:40 +0000 Subject: [Lazarus] Non-visual component tray In-Reply-To: References: Message-ID: <0749b3cb-ba64-baa2-44bf-afa21bc56841@geldenhuys.co.uk> On 2016-11-28 10:42, Ondrej Pokorny via Lazarus wrote: > Good that it's a Lazarus solution! Sorry, I should have mentioned the link is a Delphi add-on. The point of my post was to show the good idea, and to inspire somebody to implement it for Lazarus. I don't use VCL or LCL for years now, so there is no benefit for me any more. Regards, Graeme From nc-gaertnma at netcologne.de Mon Nov 28 12:36:27 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Mon, 28 Nov 2016 12:36:27 +0100 Subject: [Lazarus] Non-visual component tray In-Reply-To: References: Message-ID: <20161128123627.36d35cc5@limapholos.matflo.wg> On Mon, 28 Nov 2016 11:19:32 +0100 Maciej Izak via Lazarus wrote: > 2016-11-28 11:01 GMT+01:00 Graeme Geldenhuys via Lazarus < > lazarus at lists.lazarus-ide.org>: > > > Non-visual components don't belong on the designer form itself. > > > It is simple to do with Sparta docked solution. Should be simple to do with a non docked IDE as well. For example as floating window. And when it works as floating window it will work with anchordocking too. And then it should be a small step to use it in Sparta docked designer. Mattias From hnb.code at gmail.com Mon Nov 28 12:45:48 2016 From: hnb.code at gmail.com (Maciej Izak) Date: Mon, 28 Nov 2016 12:45:48 +0100 Subject: [Lazarus] Non-visual component tray In-Reply-To: <20161128123627.36d35cc5@limapholos.matflo.wg> References: <20161128123627.36d35cc5@limapholos.matflo.wg> Message-ID: 2016-11-28 12:36 GMT+01:00 Mattias Gaertner via Lazarus < lazarus at lists.lazarus-ide.org>: > Should be simple to do with a non docked IDE as well. For example as > floating window. > And when it works as floating window it will work with anchordocking > too. > And then it should be a small step to use it in Sparta docked designer. > Might be :). Note: as start point to hide in designer non-visual components could be used (introduced by Sparta) IDEComponentsMaster located in ComponentEditors (ideintf). -- Best regards, Maciej Izak -------------- next part -------------- An HTML attachment was scrubbed... URL: From juergen.hestermann at gmx.de Mon Nov 28 13:38:11 2016 From: juergen.hestermann at gmx.de (=?UTF-8?Q?J=c3=bcrgen_Hestermann?=) Date: Mon, 28 Nov 2016 13:38:11 +0100 Subject: [Lazarus] IDE, indentation after inserting from clipboard Message-ID: <338e2f7b-8241-f5e6-4b38-e23e5d403919@gmx.de> In the editor of the IDE, when I put the cursor somewhere and paste multiple lines from the clipboard then only the first line is indented (starts where the cursor is) but all following lines are not indented (start from column 0). For example, if I have this code snippet in the clipboard: case X of 1 : else end; { of case } and paste it at column 4 then I get case X of 1: else end; { of case } instead of case X of 1 : else end; { of case } so I have to indent lines 2-4 manually each time I paste it. Is that how it should be? I would like to have the whole block indented in the same way as the first column. From nc-gaertnma at netcologne.de Mon Nov 28 14:50:09 2016 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Mon, 28 Nov 2016 14:50:09 +0100 Subject: [Lazarus] IDE, indentation after inserting from clipboard In-Reply-To: <338e2f7b-8241-f5e6-4b38-e23e5d403919@gmx.de> References: <338e2f7b-8241-f5e6-4b38-e23e5d403919@gmx.de> Message-ID: <20161128145009.4df8c834@limapholos.matflo.wg> On Mon, 28 Nov 2016 13:38:11 +0100 Jürgen Hestermann via Lazarus wrote: > In the editor of the IDE, when I put the cursor somewhere and paste multiple lines from the clipboard > then only the first line is indented (starts where the cursor is) but all following lines are not indented > (start from column 0). > For example, if I have this code snippet in the clipboard: > > case X of > 1 : > else > end; { of case } > > and paste it at column 4 then I get > > case X of > 1: > else > end; { of case } > > instead of > > case X of > 1 : > else > end; { of case } > > so I have to indent lines 2-4 manually each time I paste it. > Is that how it should be? > I would like to have the whole block indented in the same way as the first column. Not yet implemented. At the moment pasting at Col>1 pastes the text without reformatting. When you paste at Col 1, and you have option 'Codetools/General/On paste from clipboard' enabled the IDE will auto indent/unindent the pasted text, each line the same amount. Otherwise it pastes without reformatting the text. Mattias From lacak at zoznam.sk Mon Nov 28 15:12:13 2016 From: lacak at zoznam.sk (LacaK) Date: Mon, 28 Nov 2016 15:12:13 +0100 Subject: [Lazarus] Lazarus and MySQL 5.7 In-Reply-To: <20161126144750.23172cd6@limapholos.matflo.wg> References: <1479525914.4974.3.camel@Hercules> <20161126144750.23172cd6@limapholos.matflo.wg> Message-ID: <55da57cd-8619-09e9-2b65-44d3d483c0da@zoznam.sk> >> What version of Lazarus can connect to MySQL 5.7 using TSqlConnector? >> My laptop has 1.6 and does not seem to be able to connect using that >> component. > I added TMySQL57Connection to trunk (1.7). Thank you Mattias. -Laco. From juergen.hestermann at gmx.de Mon Nov 28 18:27:41 2016 From: juergen.hestermann at gmx.de (=?UTF-8?Q?J=c3=bcrgen_Hestermann?=) Date: Mon, 28 Nov 2016 18:27:41 +0100 Subject: [Lazarus] IDE, indentation after inserting from clipboard In-Reply-To: <20161128145009.4df8c834@limapholos.matflo.wg> References: <338e2f7b-8241-f5e6-4b38-e23e5d403919@gmx.de> <20161128145009.4df8c834@limapholos.matflo.wg> Message-ID: <7ec7ef57-05c4-1930-017d-15fc92ed1ff9@gmx.de> Am 2016-11-28 um 14:50 schrieb Mattias Gaertner via Lazarus: > On Mon, 28 Nov 2016 13:38:11 +0100 > Jürgen Hestermann via Lazarus wrote: > >> In the editor of the IDE, when I put the cursor somewhere and paste multiple lines from the clipboard >> then only the first line is indented (starts where the cursor is) but all following lines are not indented >> (start from column 0). >> For example, if I have this code snippet in the clipboard: >> case X of >> 1 : >> else >> end; { of case } >> and paste it at column 4 then I get >> case X of >> 1: >> else >> end; { of case } >> instead of >> case X of >> 1 : >> else >> end; { of case } >> so I have to indent lines 2-4 manually each time I paste it. >> Is that how it should be? >> I would like to have the whole block indented in the same way as the first column. > Not yet implemented. Okay. I was not sure whether it can be enabled by some option. > At the moment pasting at Col>1 pastes the text without reformatting. > When you paste at Col 1, and you have option 'Codetools/General/On > paste from clipboard' enabled the IDE will auto indent/unindent the > pasted text, each line the same amount. This would not help much as I want to specify the indentation of the whole block by positioning the cursor somewhere. I would not have to change the indentation after pasting then. Thanks for the explanation. From donald at ziesig.org Mon Nov 28 23:30:52 2016 From: donald at ziesig.org (Donald Ziesig) Date: Mon, 28 Nov 2016 17:30:52 -0500 Subject: [Lazarus] High Res Screen, problems with IDE Message-ID: <1e02ae38-62c0-3bc1-fda3-710f850a21b5@ziesig.org> Hi Everyone! I have recently upgraded my linux machine to a laptop with high screen resolution (1920 x 1080) that for most programs is beautiful. Unfortunately, parts of the Lazarus IDE do not respect the screen resolution (in at least one case only in the vertical direction!). For example, the Menu Editor only resolves the horizontal resolution, resulting to the following display: The Component Palette fails in both directions, as in: If anyone can give me a hint as to where I should look for the code that causes this, I will be glad to try to patch it appropriately. Thanks, Don Ziesig P.S. Lazarus is not the only program that has similar problems, the Postgres Admin III program has a similar problem with vertical resolution when it displays table data, but that's not as critical. The problems may be caused by Linux itself, but there are enough programs that display properly that I can't be sure. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: jikijepjalnopcne.png Type: image/png Size: 22647 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mlegfkmidjkmkfib.png Type: image/png Size: 53073 bytes Desc: not available URL: From mailinglists at geldenhuys.co.uk Tue Nov 29 11:21:10 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Tue, 29 Nov 2016 10:21:10 +0000 Subject: [Lazarus] High Res Screen, problems with IDE In-Reply-To: <1e02ae38-62c0-3bc1-fda3-710f850a21b5@ziesig.org> References: <1e02ae38-62c0-3bc1-fda3-710f850a21b5@ziesig.org> Message-ID: <8a782d3f-2287-71bc-6d1b-384f2b9cfc9b@geldenhuys.co.uk> On 2016-11-28 22:30, Donald Ziesig via Lazarus wrote: > with high screen resolution (1920 x 1080) These days that's not such a high resolution, so in itself that should not cause a problem. I run at double that resolution without problems. What is your desktop DPI setting at? [~]$ xdpyinfo | grep res Present resolution: 96x96 dots per inch I would expect Lazarus IDE [in this day and age] to take DPI values in account and scale accordingly, and not always expect them to be hard-coded at 96 dpi. Greater than 96dpi is more and more common place these days. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From erwin at deseine.nl Tue Nov 29 14:18:24 2016 From: erwin at deseine.nl (Erwin van den Bosch) Date: Tue, 29 Nov 2016 14:18:24 +0100 Subject: [Lazarus] High Res Screen, problems with IDE In-Reply-To: <8a782d3f-2287-71bc-6d1b-384f2b9cfc9b@geldenhuys.co.uk> References: <1e02ae38-62c0-3bc1-fda3-710f850a21b5@ziesig.org> <8a782d3f-2287-71bc-6d1b-384f2b9cfc9b@geldenhuys.co.uk> Message-ID: <0825449f-bf42-100d-33a4-cdc887a35493@deseine.nl> I have a macbook pro with (very) high resolution running kubuntu linux. And Lazarus doesn't look good. All bitmaps are tiny. Some lazarus forms are to small so you have to resize them first. The component bar is not high enough so you almost can't see or click on the components. I can't resize lazarus mainform. Codings works great but it's hard to design/edit forms. They are also very small. I have a QT based Lazarus but it's QT4 and still not QT5. I think QT5 handles high res screens better. regards, Erwin Op 29-11-2016 om 11:21 schreef Graeme Geldenhuys via Lazarus: > On 2016-11-28 22:30, Donald Ziesig via Lazarus wrote: >> with high screen resolution (1920 x 1080) > These days that's not such a high resolution, so in itself that should > not cause a problem. I run at double that resolution without problems. > > What is your desktop DPI setting at? > > [~]$ xdpyinfo | grep res > Present > resolution: 96x96 dots per inch > > > I would expect Lazarus IDE [in this day and age] to take DPI values in > account and scale accordingly, and not always expect them to be > hard-coded at 96 dpi. Greater than 96dpi is more and more common place > these days. > > > Regards, > Graeme > From david.copeland at jsidata.ca Tue Nov 29 15:07:24 2016 From: david.copeland at jsidata.ca (David Copeland) Date: Tue, 29 Nov 2016 09:07:24 -0500 Subject: [Lazarus] High Res Screen, problems with IDE In-Reply-To: <0825449f-bf42-100d-33a4-cdc887a35493@deseine.nl> References: <1e02ae38-62c0-3bc1-fda3-710f850a21b5@ziesig.org> <8a782d3f-2287-71bc-6d1b-384f2b9cfc9b@geldenhuys.co.uk> <0825449f-bf42-100d-33a4-cdc887a35493@deseine.nl> Message-ID: <39279e59-cbbd-2f9e-fc35-22b6e8775e98@jsidata.ca> I have similar issues on a ThinkPad W550s laptop with a 2880x1620 display, running OpenSuse (13.2). Here I currently have the font DPI setting at 204. But no problems at all on my desktop system with 1920x1080 displays. (DPI setting is default of 96). Dave. On 29/11/16 08:18 AM, Erwin van den Bosch via Lazarus wrote: > I have a macbook pro with (very) high resolution running kubuntu > linux. And Lazarus doesn't look good. > All bitmaps are tiny. Some lazarus forms are to small so you have to > resize them first. The component bar is not high enough so you almost > can't see or click on the components. I can't resize lazarus mainform. > > Codings works great but it's hard to design/edit forms. They are also > very small. > > I have a QT based Lazarus but it's QT4 and still not QT5. I think QT5 > handles high res screens better. > > regards, > Erwin -- David Copeland JSI Data Systems Limited 613-727-9353 www.jsidata.ca From juha.manninen62 at gmail.com Tue Nov 29 15:30:59 2016 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Tue, 29 Nov 2016 16:30:59 +0200 Subject: [Lazarus] High Res Screen, problems with IDE In-Reply-To: <1e02ae38-62c0-3bc1-fda3-710f850a21b5@ziesig.org> References: <1e02ae38-62c0-3bc1-fda3-710f850a21b5@ziesig.org> Message-ID: Incidentally there is discussion in developer mailing list about making Lazarus DPI aware. I also hope it can be done for the next major release (1.8 maybe). Screen resolutions keep growing, the problem is getting worse. Juha -------------- next part -------------- An HTML attachment was scrubbed... URL: From erwin at deseine.nl Tue Nov 29 16:43:44 2016 From: erwin at deseine.nl (Erwin van den Bosch) Date: Tue, 29 Nov 2016 16:43:44 +0100 Subject: [Lazarus] High Res Screen, problems with IDE In-Reply-To: References: <1e02ae38-62c0-3bc1-fda3-710f850a21b5@ziesig.org> Message-ID: <105356c7-1090-d0f2-1d04-845c107b2c90@deseine.nl> Op 29-11-2016 om 15:30 schreef Juha Manninen via Lazarus: > Incidentally there is discussion in developer mailing list about > making Lazarus DPI aware. Where can I read/subscribe to this list? regards, Erwin From juha.manninen62 at gmail.com Tue Nov 29 16:57:31 2016 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Tue, 29 Nov 2016 17:57:31 +0200 Subject: [Lazarus] High Res Screen, problems with IDE In-Reply-To: <105356c7-1090-d0f2-1d04-845c107b2c90@deseine.nl> References: <1e02ae38-62c0-3bc1-fda3-710f850a21b5@ziesig.org> <105356c7-1090-d0f2-1d04-845c107b2c90@deseine.nl> Message-ID: On Tue, Nov 29, 2016 at 5:43 PM, Erwin van den Bosch via Lazarus wrote: > Where can I read/subscribe to this list? It is by invitation only. Start providing patches diligently, finally you will be invited. :) Ok, it will take some time... does not help for reading this DPI issue. Juha From juha.manninen62 at gmail.com Tue Nov 29 16:59:02 2016 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Tue, 29 Nov 2016 17:59:02 +0200 Subject: [Lazarus] High Res Screen, problems with IDE In-Reply-To: References: <1e02ae38-62c0-3bc1-fda3-710f850a21b5@ziesig.org> <105356c7-1090-d0f2-1d04-845c107b2c90@deseine.nl> Message-ID: ... but we will write here when there is a plan. From roelof at smelt.is Tue Nov 29 17:17:04 2016 From: roelof at smelt.is (Roelof Smelt) Date: Tue, 29 Nov 2016 16:17:04 -0000 Subject: [Lazarus] High Res Screen, problems with IDE In-Reply-To: <105356c7-1090-d0f2-1d04-845c107b2c90@deseine.nl> References: <1e02ae38-62c0-3bc1-fda3-710f850a21b5@ziesig.org> <105356c7-1090-d0f2-1d04-845c107b2c90@deseine.nl> Message-ID: <00e301d24a5c$06983250$13c896f0$@smelt.is> Hello Erwin, I guess you already saw the last link in this and other posts? Best regards, Roelof Smelt -----Original Message----- From: Lazarus [mailto:lazarus-bounces at lists.lazarus-ide.org] On Behalf Of Erwin van den Bosch via Lazarus Sent: 29. nóvember 2016 15:44 To: Lazarus mailing list Cc: Erwin van den Bosch Subject: Re: [Lazarus] High Res Screen, problems with IDE Op 29-11-2016 om 15:30 schreef Juha Manninen via Lazarus: > Incidentally there is discussion in developer mailing list about > making Lazarus DPI aware. Where can I read/subscribe to this list? regards, Erwin -- _______________________________________________ Lazarus mailing list Lazarus at lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus From erwin at deseine.nl Tue Nov 29 19:00:36 2016 From: erwin at deseine.nl (Erwin van den Bosch) Date: Tue, 29 Nov 2016 19:00:36 +0100 Subject: [Lazarus] High Res Screen, problems with IDE In-Reply-To: <00e301d24a5c$06983250$13c896f0$@smelt.is> References: <1e02ae38-62c0-3bc1-fda3-710f850a21b5@ziesig.org> <105356c7-1090-d0f2-1d04-845c107b2c90@deseine.nl> <00e301d24a5c$06983250$13c896f0$@smelt.is> Message-ID: <766bce49-ab4f-cd90-ee02-69e22903d6d0@deseine.nl> What link? It was about the developer list not this list. regards, Erwin Op 29-11-2016 om 17:17 schreef Roelof Smelt via Lazarus: > Hello Erwin, > > I guess you already saw the last link in this and other posts? > > > Best regards, > Roelof Smelt > > -----Original Message----- > From: Lazarus [mailto:lazarus-bounces at lists.lazarus-ide.org] On Behalf Of Erwin van den Bosch via Lazarus > Sent: 29. nóvember 2016 15:44 > To: Lazarus mailing list > Cc: Erwin van den Bosch > Subject: Re: [Lazarus] High Res Screen, problems with IDE > > Op 29-11-2016 om 15:30 schreef Juha Manninen via Lazarus: >> Incidentally there is discussion in developer mailing list about >> making Lazarus DPI aware. > Where can I read/subscribe to this list? > > regards, > Erwin > -- > _______________________________________________ > Lazarus mailing list > Lazarus at lists.lazarus-ide.org > http://lists.lazarus-ide.org/listinfo/lazarus > From erwin at deseine.nl Tue Nov 29 20:05:50 2016 From: erwin at deseine.nl (Erwin van den Bosch) Date: Tue, 29 Nov 2016 20:05:50 +0100 Subject: [Lazarus] High Res Screen, problems with IDE In-Reply-To: References: <1e02ae38-62c0-3bc1-fda3-710f850a21b5@ziesig.org> <105356c7-1090-d0f2-1d04-845c107b2c90@deseine.nl> Message-ID: Op 29-11-2016 om 16:57 schreef Juha Manninen via Lazarus: > On Tue, Nov 29, 2016 at 5:43 PM, Erwin van den Bosch via Lazarus > wrote: >> Where can I read/subscribe to this list? > It is by invitation only. Doesn't sound like an "open" development group of enthusiasts. :-( > Ok, it will take some time... does not help for reading this DPI issue. The current problems with Lazarus-IDE as I see it: - The IDE looks like something from the year 2002. If new users look at the IDE then they might think that you can only develop old fashion ugly programs with it. - IDE doesn't look good on high dpi screen. Form designing is hard on high dpi screens. - The debugger is bad. (can't inspect objects) - Multiplatform isn't working. No GTK3, no QT5, no Cocoa on the Mac, no 64 bits on the Mac. They only platform that really works is Windows. (but we had Delphi already) - It might be better to drop all those native widgets sets (and the LCL) if you can't get it to work and put your development energy in the QT framework for all platforms. - Development is still in subversion SVN. I hate SVN (and i'm not alone). Please switch to GIT. Nobody is using SVN. Even Microsoft is using GIT! (well...sometimes). - Stop trying to be compatible with Delphi. Delphi is a non standard. Try to make something better then Delphi. - Stop thinking "one size fits all". Lazarus is getting more and more behind supporting new technologies. It's just to much to cope with (or too few fpc/lazarus developers). - Not important but drop the name Lazarus. I hate religious names. Just pick something from Star Wars or Star Trek or some other high tech science fiction. Nerds and geeks will understand this :-). Lazarus in Dutch is a drunken man. Everyone start looking odd if I'm saying "I'm developing in Lazarus". Just a few things you can send to the developers list. Maybe some of my points make sense, maybe not, but whatever you main developers do: "keep the fun going!" regards, Erwin -------------- next part -------------- An HTML attachment was scrubbed... URL: From juha.manninen62 at gmail.com Tue Nov 29 22:56:33 2016 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Tue, 29 Nov 2016 23:56:33 +0200 Subject: [Lazarus] High Res Screen, problems with IDE In-Reply-To: References: <1e02ae38-62c0-3bc1-fda3-710f850a21b5@ziesig.org> <105356c7-1090-d0f2-1d04-845c107b2c90@deseine.nl> Message-ID: On Tue, Nov 29, 2016 at 9:05 PM, Erwin van den Bosch via Lazarus wrote: > Doesn't sound like an "open" development group of enthusiasts. :-( People have rights for private communication. Also Lazarus developers have such rights. I even have private mails which I am NOT going to show you. How do you feel about that? :) > The current problems with Lazarus-IDE as I see it: > [...] > Just a few things you can send to the developers list. > Maybe some of my points make sense, maybe not, but whatever you main > developers do: > "keep the fun going!" Yes, sure! BTW, your wish list kind of proves that a separate developers list is needed. Think: If developers tried to discuss an implementation detail here and most replies would be like yours, the developers would loose their interest quite soon. Juha From noreply at z505.com Wed Nov 30 10:20:40 2016 From: noreply at z505.com (Lars) Date: Wed, 30 Nov 2016 02:20:40 -0700 Subject: [Lazarus] macOS Sierra save as dialog hangs Message-ID: <3d430a341aa6f7112f40949e1fd24b38.squirrel@gator3286.hostgator.com> Hi, Not sure if this has anything specifically to do with Sierra version of MacOS but that's the only Mac I have to test on.. When I run the latest Lazarus from source forge download section, on Mac Sierra OS version, The IDE loads up and works fine except for when I try to save the project. If I click any of the drop down menu items in the save project as dialog it hangs, with the spinning multicolor cursor and will not stop unless I force the application to quit. In addition, clicking the save button hangs in that dialog if I don't click any of the drop down items. Anyone on Mac had this issue? I ran a disk first aid to make sure my hard drive is not the cause. Then as an experiment I opened a new project (after forcing lazarus to quit then restarting it) and added a save dialog widget to the form. I launched the application without saving it and executed the save dialog. This one does not hang, i.e. in project1. However the lazarus app itself, hangs when save dialog accessed.. Wondering if this is a Sierra issue specifically. Not positive it is because I've seen other Sierra users on the internet able to use lazarus. From l at c-m-w.me.uk Wed Nov 30 10:31:40 2016 From: l at c-m-w.me.uk (C Western) Date: Wed, 30 Nov 2016 09:31:40 +0000 Subject: [Lazarus] macOS Sierra save as dialog hangs In-Reply-To: <3d430a341aa6f7112f40949e1fd24b38.squirrel@gator3286.hostgator.com> References: <3d430a341aa6f7112f40949e1fd24b38.squirrel@gator3286.hostgator.com> Message-ID: <6e30abaf-a2f6-3eae-699a-ec7764c6d189@c-m-w.me.uk> May be http://bugs.freepascal.org/view.php?id=29911 which is supposed to be resolved in the trunk version. See also http://bugs.freepascal.org/view.php?id=30533 Colin On 30/11/16 09:20, Lars via Lazarus wrote: > Hi, Not sure if this has anything specifically to do with Sierra version > of MacOS but that's the only Mac I have to test on.. > > When I run the latest Lazarus from source forge download section, on Mac > Sierra OS version, The IDE loads up and works fine except for when I try > to save the project. > > If I click any of the drop down menu items in the save project as dialog > it hangs, with the spinning multicolor cursor and will not stop unless I > force the application to quit. > > In addition, clicking the save button hangs in that dialog if I don't > click any of the drop down items. > > Anyone on Mac had this issue? > > I ran a disk first aid to make sure my hard drive is not the cause. > > Then as an experiment I opened a new project (after forcing lazarus to > quit then restarting it) and added a save dialog widget to the form. I > launched the application without saving it and executed the save dialog. > This one does not hang, i.e. in project1. However the lazarus app itself, > hangs when save dialog accessed.. > > Wondering if this is a Sierra issue specifically. Not positive it is > because I've seen other Sierra users on the internet able to use lazarus. > From noreply at z505.com Wed Nov 30 11:44:37 2016 From: noreply at z505.com (Lars) Date: Wed, 30 Nov 2016 03:44:37 -0700 Subject: [Lazarus] macOS Sierra save as dialog hangs In-Reply-To: <6e30abaf-a2f6-3eae-699a-ec7764c6d189@c-m-w.me.uk> References: <3d430a341aa6f7112f40949e1fd24b38.squirrel@gator3286.hostgator.com> <6e30abaf-a2f6-3eae-699a-ec7764c6d189@c-m-w.me.uk> Message-ID: On Wed, November 30, 2016 2:31 am, C Western via Lazarus wrote: > May be http://bugs.freepascal.org/view.php?id=29911 > which is supposed to be resolved in the trunk version. > > See also http://bugs.freepascal.org/view.php?id=30533 > > > Colin > Thanks. Just applied the patch to my local copy, instead of downloading entire source tree. Fixes the issue.. on my computer. Wow - fast reply, fast fix! Thanks (power of open source). As for my new Mac Laptop though, not too impressed with the zippiness it does not have compared to all my windows laptops ever owned. This thing is slow! Oh well. From michael at freepascal.org Wed Nov 30 13:29:14 2016 From: michael at freepascal.org (Michael Van Canneyt) Date: Wed, 30 Nov 2016 13:29:14 +0100 (CET) Subject: [Lazarus] macOS Sierra save as dialog hangs In-Reply-To: References: <3d430a341aa6f7112f40949e1fd24b38.squirrel@gator3286.hostgator.com> <6e30abaf-a2f6-3eae-699a-ec7764c6d189@c-m-w.me.uk> Message-ID: On Wed, 30 Nov 2016, Lars via Lazarus wrote: > On Wed, November 30, 2016 2:31 am, C Western via Lazarus wrote: >> May be http://bugs.freepascal.org/view.php?id=29911 >> which is supposed to be resolved in the trunk version. >> >> See also http://bugs.freepascal.org/view.php?id=30533 >> >> >> Colin >> > > Thanks. Just applied the patch to my local copy, instead of downloading > entire source tree. > > Fixes the issue.. on my computer. > > Wow - fast reply, fast fix! Thanks (power of open source). > > As for my new Mac Laptop though, not too impressed with the zippiness it > does not have compared to all my windows laptops ever owned. This thing is > slow! Oh well. Strange. I had the exact opposite reaction. You may want to have it checked for some defects... Michael. From aaa5500 at ya.ru Wed Nov 30 18:57:52 2016 From: aaa5500 at ya.ru (Alexey) Date: Wed, 30 Nov 2016 20:57:52 +0300 Subject: [Lazarus] AutoAdjustLayout fixes In-Reply-To: References: <1e02ae38-62c0-3bc1-fda3-710f850a21b5@ziesig.org> <105356c7-1090-d0f2-1d04-845c107b2c90@deseine.nl> Message-ID: Juha, I tried to improv http://mantis.freepascal.org/view.php?id=30995 and i tried other LCL controls which need this too. SpinEdit/FloatSpinedit/Check/Radiobtn/Group/Panel.. now i see that no more fixes needed. SpinEdit's are childs of TCustomEdit--so they ok today. Others dont need work: they autosize in x/y and so this work (for one line edits) not needed for em. AutoSize scaling _overworks_ AutoAdjust scaling. So AutoAdjust scaling can ignore other AutoSize ctrls. (tested on app) Alexey From fluisgirardi at gmail.com Wed Nov 30 19:12:58 2016 From: fluisgirardi at gmail.com (Fabio Luis Girardi) Date: Wed, 30 Nov 2016 16:12:58 -0200 Subject: [Lazarus] Form Width bigger than 4096 pixels? Message-ID: Hi! Currently I'm developing a application to control a process and the width of one form can't be increased to more than 4096 pixels. My environment is: Lazarus 1.7, FPC 3.1.1 over Linux Mint 17.3 amd64, with Sparta and Anchordocking packages installed. Why this limit? Is it some specification? Can this limit to be increased? -- The best regards, Fabio Luis Girardi PascalSCADA Project http://sourceforge.net/projects/pascalscada http://www.pascalscada.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at geldenhuys.co.uk Wed Nov 30 19:35:14 2016 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 30 Nov 2016 18:35:14 +0000 Subject: [Lazarus] Form Width bigger than 4096 pixels? In-Reply-To: References: Message-ID: <6c6879ea-17c8-6e54-46e5-7e616c0b0279@geldenhuys.co.uk> On 2016-11-30 18:12, Fabio Luis Girardi via Lazarus wrote: > Why this limit? > Is it some specification? Windowing environments tend to have a 32k or 64k window pixel limit (eg: X11 and GDI). So the 4k limit seems to be something introduced by LCL. Unfortunately I can't answer why they introduced a 4k limit though. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp From fluisgirardi at gmail.com Wed Nov 30 20:09:02 2016 From: fluisgirardi at gmail.com (Fabio Luis Girardi) Date: Wed, 30 Nov 2016 17:09:02 -0200 Subject: [Lazarus] Form Width bigger than 4096 pixels? In-Reply-To: <6c6879ea-17c8-6e54-46e5-7e616c0b0279@geldenhuys.co.uk> References: <6c6879ea-17c8-6e54-46e5-7e616c0b0279@geldenhuys.co.uk> Message-ID: 2016-11-30 16:35 GMT-02:00 Graeme Geldenhuys via Lazarus < lazarus at lists.lazarus-ide.org>: > > > Windowing environments tend to have a 32k or 64k window pixel limit (eg: > X11 and GDI). So the 4k limit seems to be something introduced by LCL. > Unfortunately I can't answer why they introduced a 4k limit though. > > I found it. This limit is hardcoded into the sparta, not in LCL. -- The best regards, Fabio Luis Girardi PascalSCADA Project http://sourceforge.net/projects/pascalscada http://www.pascalscada.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lazarus at kluug.net Wed Nov 30 20:29:08 2016 From: lazarus at kluug.net (Ondrej Pokorny) Date: Wed, 30 Nov 2016 20:29:08 +0100 Subject: [Lazarus] AutoAdjustLayout fixes In-Reply-To: References: <1e02ae38-62c0-3bc1-fda3-710f850a21b5@ziesig.org> <105356c7-1090-d0f2-1d04-845c107b2c90@deseine.nl> Message-ID: On 30.11.2016 18:57, Alexey via Lazarus wrote: > Juha, > I tried to improv http://mantis.freepascal.org/view.php?id=30995 > and i tried other LCL controls which need this too. > SpinEdit/FloatSpinedit/Check/Radiobtn/Group/Panel.. > now i see that no more fixes needed. > SpinEdit's are childs of TCustomEdit--so they ok today. > Others dont need work: they autosize in x/y and so this work (for one > line edits) not needed for em. > AutoSize scaling _overworks_ AutoAdjust scaling. > So AutoAdjust scaling can ignore other AutoSize ctrls. Just curious: what widget set do you use for macOS? Ondrej From juha.manninen62 at gmail.com Wed Nov 30 21:36:00 2016 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Wed, 30 Nov 2016 22:36:00 +0200 Subject: [Lazarus] AutoAdjustLayout fixes In-Reply-To: References: <1e02ae38-62c0-3bc1-fda3-710f850a21b5@ziesig.org> <105356c7-1090-d0f2-1d04-845c107b2c90@deseine.nl> Message-ID: On Wed, Nov 30, 2016 at 7:57 PM, Alexey via Lazarus wrote: > I tried to improv http://mantis.freepascal.org/view.php?id=30995 > and i tried other LCL controls which need this too. > SpinEdit/FloatSpinedit/Check/Radiobtn/Group/Panel.. > now i see that no more fixes needed. Thanks for testing. How about the TEditButton derivatives like TFileNameEdit, TDirectoryEdit, TCalcEdit etc.? They used to inherit from TCustomEdit but not any more. Now the edit control is embedded. The control's boundaries and resize handles now correctly include the button part. Juha