From graham at evroysystems.com Mon May 1 01:53:55 2017 From: graham at evroysystems.com (Graham Ward) Date: Mon, 1 May 2017 11:53:55 +1200 Subject: [Lazarus] Lazarus Bug: No exception raised when attempting to access an array outside of range. Message-ID: <19707b53-97db-dbae-c361-018cee932e44@evroysystems.com> Hi, Apologies if this email has been sent to the wrong location (I'm a brand new user to the Lazarus emailing list). I recently had a software/compilation bug whereby no exception was raised when my code was accessing an array outside of its range. Took some detective work, as it was resulting in corruption at runtime with completely unrelated code. This was caused by a bug in my own software that tried to access index 72 for an array of range [0..71]. What was more interesting was that if I expanded the array to 72 (or 73,74,75 for that matter) and then tried to access range+1 (IE index 73 for the array with an index of [0..72] this appeared to cause no ill effect to my program once more, so I was extremely "lucky" to have such an obvious bug appear in my code. Something more subtle would have been a lot more difficult to locate. The offending code is as follows: setlength(isMerged, ParityCol); // fixed length for array keeping track of merged cells. setlength(ColIndex, ParityCol); // Define the length of the Column Index For J := 0 to ParityCol do Begin isMerged[J] := False; //This line was leading to the program becoming unresponsive in another totally unrelated part of code (AssignFile...) in another procedure ColIndex[J] := 1000; // This line, although also accessing outside of the legal range, did not appear to cause any problems!!! end; Note I even tried the following line, which is obviously wrong (as the array has a maximum index of 71) ColIndex[175] := 500; In other languages (that I am more familiar with) an exception (Error : Array index outside of range) would have been raised. Why does the Lazarus compiler not raise a similar error? I am using: Code Typhon Version 6.0 FPC Version 3.1.1 SVN Revision : 54036 Assuming this is an actual bug in the compiler, then I hope this information proves useful. If not, then please advise me accordingly, thanks. Aside from this, let me say a very big thank you to you guys for all your hard work in what is a very useful piece of software for me (FPC). Your efforts are greatly appreciated. Kind Regards, Graham New Zealand From nc-gaertnma at netcologne.de Mon May 1 09:04:44 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Mon, 1 May 2017 09:04:44 +0200 Subject: [Lazarus] Lazarus Bug: No exception raised when attempting to access an array outside of range. In-Reply-To: <19707b53-97db-dbae-c361-018cee932e44@evroysystems.com> References: <19707b53-97db-dbae-c361-018cee932e44@evroysystems.com> Message-ID: <20170501090444.60f9f29c@limapholos.matflo.wg> On Mon, 1 May 2017 11:53:55 +1200 Graham Ward via Lazarus wrote: >[...] > I recently had a software/compilation bug whereby no exception was > raised when my code was accessing an array outside of its range. Enable runtime range checks: Project / Project Options / Compiler Option / Debugging / Checks / Range Or have a "debug" and "release" mode: http://wiki.lazarus.freepascal.org/IDE_Window:_Compiler_Options#Adding_a_release_and_debug_build_modes Mattias Took > some detective work, as it was resulting in corruption at runtime with > completely unrelated code. This was caused by a bug in my own software > that tried to access index 72 for an array of range [0..71]. What was > more interesting was that if I expanded the array to 72 (or 73,74,75 for > that matter) and then tried to access range+1 (IE index 73 for the array > with an index of [0..72] this appeared to cause no ill effect to my > program once more, so I was extremely "lucky" to have such an obvious > bug appear in my code. Something more subtle would have been a lot more > difficult to locate. > > The offending code is as follows: > > setlength(isMerged, ParityCol); // fixed length for array keeping > track of merged cells. > setlength(ColIndex, ParityCol); // Define the length of the Column > Index > For J := 0 to ParityCol do > Begin > isMerged[J] := False; //This line was leading to the program > becoming unresponsive in another totally unrelated part of code > (AssignFile...) in another procedure > ColIndex[J] := 1000; // This line, although also accessing outside > of the legal range, did not appear to cause any problems!!! > end; > > Note I even tried the following line, which is obviously wrong (as the > array has a maximum index of 71) > > ColIndex[175] := 500; > > In other languages (that I am more familiar with) an exception (Error : > Array index outside of range) would have been raised. Why does the > Lazarus compiler not raise a similar error? > > I am using: > > Code Typhon Version 6.0 > FPC Version 3.1.1 > SVN Revision : 54036 > > > Assuming this is an actual bug in the compiler, then I hope this > information proves useful. If not, then please advise me accordingly, > thanks. > > Aside from this, let me say a very big thank you to you guys for all > your hard work in what is a very useful piece of software for me (FPC). > Your efforts are greatly appreciated. > > Kind Regards, > Graham > New Zealand From michael at freepascal.org Mon May 1 09:32:08 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 1 May 2017 09:32:08 +0200 (CEST) Subject: [Lazarus] Lazarus Bug: No exception raised when attempting to access an array outside of range. In-Reply-To: <19707b53-97db-dbae-c361-018cee932e44@evroysystems.com> References: <19707b53-97db-dbae-c361-018cee932e44@evroysystems.com> Message-ID: On Mon, 1 May 2017, Graham Ward via Lazarus wrote: > Hi, > > Apologies if this email has been sent to the wrong location (I'm a brand > new user to the Lazarus emailing list). > > Note I even tried the following line, which is obviously wrong (as the > array has a maximum index of 71) > > ColIndex[175] := 500; > > In other languages (that I am more familiar with) an exception (Error : > Array index outside of range) would have been raised. Why does the > Lazarus compiler not raise a similar error? The Free Pascal compiler does not do range checking by default, you need to enable it with -Cr (there is an option in the project option dialog). araminta: ~ >fpc ta.pp -Cr araminta: ~ >./ta Runtime error 201 at $00010D50 $00010D50 araminta: ~ >cat ta.pp Var I : Integer; A : Array of byte; B : Array of byte; begin SetLength(A,12); SetLength(B,12); for I:=0 to length(A)+1 do A[i]:=1; end. Michael. From tony.whyman at mccallumwhyman.com Mon May 1 11:30:59 2017 From: tony.whyman at mccallumwhyman.com (Tony Whyman) Date: Mon, 1 May 2017 10:30:59 +0100 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: Message-ID: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> Marcos, When I originally created the Firebird Pascal API package, I wrote it with FPC as the only intended target. However, I then got feedback asking for Delphi compatibility and I couldn't resist the challenge of seeing how easy it would be to convert the source code. In the end, it was not that difficult and the following summarises the changes needed (apart from the minor syntax changes): 1. Standard set of defines for all modules: {$IFDEF MSWINDOWS} {$DEFINE WINDOWS} {$ENDIF} {$IFDEF FPC} {$mode delphi} {$ENDIF} The first one is needed to ensure that the "WINDOWS" defined symbol works with Delphi as well as FPC, while "mode delphi" is needed for FPC. 2. All strings declared explicitly as AnsiString expect where they are used with system calls (e.g. FileNames). This rule may vary between applications. However, as FPC defaults to AnsiString and Delphi to WideString, it is usually a good idea to be explicit in your string types. In my case, most strings were the ASCII subset of UTF8 and AnsiString worked for me. Similarly AnsiChar instead of Char. 3. PByte instead of PChar. Most uses of PChar in FPC/Lazarus aren't to character strings but are instead used to point to untyped buffers. However, in Delphi, PChar now means widestring and you will be caught out if you try and use PChar for an untyped buffer. PByte has the same semantic in both FPC and Delphi and is a pointer to an unsigned byte. 4. PAnsiChar instead of PChar. When PChar is used to genuinely point to a character string then as in point 2, you should be explicit about which type of string. PWideString may also be appropriate for some cases. 5. Take care when using string literals. I added {$IFDEF FPC} {$codepage UTF8} {$ENDIF} to sources with string literals just to make sure that FPC interprets all strings as UTF8. However, you need to be careful with Delphi. In some of the test scripts I ended up with source code such as: {$IFDEF DCC} ByName('title').AsString := UTF8Encode('Blob Test ©€'); ByName('Notes').AsString := UTF8Encode('Écoute moi'); {$ELSE} ByName('title').AsString := 'Blob Test ©€'; ByName('Notes').AsString := 'Écoute moi'; {$ENDIF} The first case (DCC defined) is Delphi and as my strings were all UTF8, I added an explicit UTF8Encode to force the literal to UTF8 before assigning to the string. Note the above is a test case with literals chosen to show up differences between character sets. 6. Varargs Delphi is much fussier than FPC about varargs constructs. If you have to use them then the only way this seems to work is e.g. function blah(...): sometype; cdecl varargs; 7. Generics If you don't have to go here then don't. Unfortunately I had dug a hole for myself and made extensive use of generics. Some of the differences are minor syntax, but others... Delphi and FPC just don't work the same way. Examples of problems are: - calling a constructor from a function defined using generics. - extracting an interface from an object defined using generics. Both are possible, but with very different syntax. 8.TSystemCodePage does not exist in Delphi You may need to add {$IF not declared(TSystemCodePage)} TSystemCodePage = word; {not defined in Delphi} {$IFEND} if you are using any Ansistring code page functions. 9. $IFEND or $ENDIF As illustrated in point 8, older versions of Delphi demand $IFEND rather than $ENDIF to terminate conditional compilation. I hope you find this a useful checklist. Regards Tony Whyman MWA On 30/04/17 17:37, Marcos Douglas B. Santos via Lazarus wrote: > It months ago I realized that Lazarus was saving the sources like that: > > 1- If there is only ANSI chars, save it as ANSI encode; > 2. If there is more than ANSI chars, save it as UTF8 encode; > > (correct me if I'm wrong about that) > > I think this was changed when I updated my FPC to 3.* and Lazarus (trunk). > Everything continues works. This new behavior was completly > transparent to me... but I have a doubt: > > If Delphi sources don't use UTF8, how is the best way to mantain > sources that need to work in both compilers? > > I mean, I would like to work with FPC and Lazarus as I am used to > doing, without take concerns about "remember to change the encode of > these files", "remember to not put accented chars on code", or > something like that. > > Is there some wiki page that explains this? > Are you working on projects that have these problems? Could you tell > me which is the best approach to deal with it? > Thank you. > > Best regards, > Marcos Douglas > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaa5500 at ya.ru Mon May 1 12:51:25 2017 From: aaa5500 at ya.ru (Alexey) Date: Mon, 1 May 2017 13:51:25 +0300 Subject: [Lazarus] Gtk2 ShowWindow(..SW_RESTORE) Message-ID: Hi. Maybe someone can implement it? Gtk2 misses it- case nCmdShow of SW_SHOWNORMAL: begin if B then gtk_widget_show(PGtkWidget(GtkWindow)) else begin if not GTK_WIDGET_VISIBLE(PGtkWidget(GtkWindow)) then gtk_widget_show(PGtkWidget(GtkWindow)); gtk_window_deiconify(GtkWindow); gtk_window_unmaximize(GtkWindow); gtk_window_unfullscreen(GtkWindow); end; end; SW_HIDE: gtk_widget_hide(PGtkWidget(GtkWindow)); SW_MINIMIZE: if not B then gtk_window_iconify(GtkWindow); SW_SHOWMAXIMIZED: if B then gtk_widget_show(PGtkWidget(GtkWindow)) else begin gtk_window_deiconify(GtkWindow); gtk_window_unfullscreen(GtkWindow); gtk_window_maximize(GtkWindow); end; SW_SHOWFULLSCREEN: if B then gtk_widget_show(PGtkWidget(GtkWindow)) else gtk_window_fullscreen(GtkWindow); end; -- Regards, Alexey From sysrpl at gmail.com Mon May 1 13:34:19 2017 From: sysrpl at gmail.com (Anthony Walter) Date: Mon, 1 May 2017 07:34:19 -0400 Subject: [Lazarus] Lazarus/Free Pascal wasn't even an option in this "best languages to write a desktop Linux application" list Message-ID: Over on the slant website Lazarus wasn't even an option for the following question: What are the best languages to write a desktop Linux application in? Link: https://www.slant.co/topics/635/~best-languages-to-write-a-desktop-linux-application-in I added Lazarus/Free Pascal to this list just now. If you like Lazarus/Free Pascal consider adding a recommend to it as an option at the link above. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nc-gaertnma at netcologne.de Mon May 1 13:47:39 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Mon, 1 May 2017 13:47:39 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: Message-ID: <20170501134739.7f3ccedf@limapholos.matflo.wg> On Sun, 30 Apr 2017 13:37:17 -0300 "Marcos Douglas B. Santos via Lazarus" wrote: > It months ago I realized that Lazarus was saving the sources like that: > > 1- If there is only ANSI chars, save it as ANSI encode; > 2. If there is more than ANSI chars, save it as UTF8 encode; Lazarus saves source file by default as UTF-8 without BOM. > (correct me if I'm wrong about that) > > I think this was changed when I updated my FPC to 3.* and Lazarus (trunk). > Everything continues works. This new behavior was completly transparent to > me... but I have a doubt: > > If Delphi sources don't use UTF8, how is the best way to mantain sources > that need to work in both compilers? Option a) You can use English in sources and load all non ASCII constants via resourcestrings or similar. Then the codepage is irrelevant. Option b) You can store all files as UTF-8 with BOM. Then FPC will store all non ASCII string constants as unicodestrings. Be careful when using PChar with them. This adds implicit conversions, so it might be slower. Mattias From juha.manninen62 at gmail.com Mon May 1 16:06:50 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Mon, 1 May 2017 17:06:50 +0300 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> Message-ID: On Mon, May 1, 2017 at 12:30 PM, Tony Whyman via Lazarus wrote: > When I originally created the Firebird Pascal API package, I wrote it with > FPC as the only intended target ... I guess you used the old Unicode support with explicit UTF-8 conversion functions. Things have improved a lot since then. You should read this page: http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus > 2. All strings declared explicitly as AnsiString expect where they are used > with system calls (e.g. FileNames). No no no! AnsiString is not compatible with Delphi any more. It is an unfortunate side-effect of the new Unicode support. However using "String" type works like magic in a Delphi compatible way at source level, despite their different encodings. So, do NOT use AnsiString explicitly. > However, as FPC defaults to AnsiString and Delphi to WideString No, Delphi defaults to UnicodeString, not WideString. Lazarus with its Unicode support defaults to AnsiString with encoding changed to UTF-8. Thus it is NOT compatible with AnsiString in Delphi. > it is usually a good idea to be explicit in your string types. No! The good idea is to use "String". > 3. PByte instead of PChar. > Most uses of PChar in FPC/Lazarus aren't to character strings but are > instead used to point to untyped buffers. "Some uses", not "most uses". In both Delphi and FPC strings and PChar have been misused for binary data but it was never recommended. Such code must be fixed anyway. > 5. Take care when using string literals. > I added > {$IFDEF FPC} > {$codepage UTF8} > {$ENDIF} Yes, string literals are tricky but usually you should NOT use {$codepage UTF8}. It is explained in the wiki page. I will not repeat it here. > I added an explicit UTF8Encode to force the literal to UTF8 before assigning > to the string. You don't need UTF8Encode any more. That also means your code can be 100% Delphi compatible at source level despite their different encodings. > 7. Generics For Delphi compatible generics you can use FPC trunk and the Generics Collection lib made by Maciej. > 8.TSystemCodePage does not exist in Delphi > ... > if you are using any Ansistring code page functions. Windows system codepages are not supported by the new Unicode system. You must convert such data explicitly by SetCodepage() or such. This is the only thing not compatible with neither Delphi nor the old Lazarus solution. :( However the world is moving to Unicode and this is less and less of a problem. > I hope you find this a useful checklist. It contained so much false information that it only confuses people. :( I want to repeat that it is possible to write code dealing with Unicode that is fully compatible with Delphi at source level. It will be compatible with a future UTF-16 solution in Lazarus as well. Encoding agnostic (UTF-8 / UTF-16) code is possible even if you must iterate individual codepoints. See the wiki page for details. Remember these to keep your code compatible: 1. Normally use type "String". 1. Assign a constant always to a type String variable. 2. Use type UnicodeString explicitly for API calls that need it. Juha From juha.manninen62 at gmail.com Mon May 1 16:18:22 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Mon, 1 May 2017 17:18:22 +0300 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> Message-ID: On Mon, May 1, 2017 at 12:30 PM, Tony Whyman via Lazarus wrote: > When I originally created the Firebird Pascal API package, Now I realize your code may have been for FPC but not for Lazarus. Even then the solution provided by LazUtils (2 files there) is good because it allows compatible and portable code. Later when FPC's UTF-16 support is ready, such code can be ported easily. Juha From pascaldragon at googlemail.com Mon May 1 17:33:15 2017 From: pascaldragon at googlemail.com (Sven Barth) Date: Mon, 1 May 2017 17:33:15 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> Message-ID: Am 01.05.2017 11:31 schrieb "Tony Whyman via Lazarus" < lazarus at lists.lazarus-ide.org>: > 7. Generics > > If you don't have to go here then don't. Unfortunately I had dug a hole for myself and made extensive use of generics. Some of the differences are minor syntax, but others... Delphi and FPC just don't work the same way. Examples of problems are: > > - calling a constructor from a function defined using generics. > > - extracting an interface from an object defined using generics. > > Both are possible, but with very different syntax. Would you please elaborate on these and which FPC version you targeted? Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From nc-gaertnma at netcologne.de Mon May 1 17:41:53 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Mon, 1 May 2017 17:41:53 +0200 Subject: [Lazarus] Gtk2 log "Refused invalidating during paint msg": how to check In-Reply-To: <14451624-5fdb-b77b-80ff-c9d920fb3007@ya.ru> References: <14451624-5fdb-b77b-80ff-c9d920fb3007@ya.ru> Message-ID: <20170501174153.1d385f15@limapholos.matflo.wg> On Sun, 30 Apr 2017 18:59:17 +0300 Alexey via Lazarus wrote: > How can I check that im inside Paint code? > > Maybe come control flag, or something, exists. if csCustomPaint in ControlState then Mattias From nc-gaertnma at netcologne.de Mon May 1 17:45:41 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Mon, 1 May 2017 17:45:41 +0200 Subject: [Lazarus] WMPaint In-Reply-To: References: Message-ID: <20170501174541.59b3833a@limapholos.matflo.wg> On Sun, 30 Apr 2017 19:06:18 +0300 Alexey via Lazarus wrote: > procedure TCustomControl.WMPaint(var Message: TLMPaint); > begin > if (csDestroying in ComponentState) or (not HandleAllocated) then exit; > Include(FControlState, csCustomPaint); > inherited WMPaint(Message); > Exclude(FControlState, csCustomPaint); > end; > > Maybe use try-finally here for Exclude? I don't know any case where this would help. Mattias From tony.whyman at mccallumwhyman.com Mon May 1 18:40:01 2017 From: tony.whyman at mccallumwhyman.com (Tony Whyman) Date: Mon, 1 May 2017 17:40:01 +0100 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> Message-ID: <77f79e46-0a44-b4d7-ef2d-6163ae226e02@mccallumwhyman.com> On 01/05/17 15:18, Juha Manninen via Lazarus wrote: > On Mon, May 1, 2017 at 12:30 PM, Tony Whyman via Lazarus > wrote: >> When I originally created the Firebird Pascal API package, > Now I realize your code may have been for FPC but not for Lazarus. > Even then the solution provided by LazUtils (2 files there) is good > because it allows compatible and portable code. Later when FPC's > UTF-16 support is ready, such code can be ported easily. > > Juha I assume that you mean that my code is non-visual which is indeed where I am coming from. If you want to write an application that is LCL/VCL compatible then that is another can of worms. Your concluding remarks in your other post were: > >>I hope you find this a useful checklist. > It contained so much false information that it only confuses people. > > I want to repeat that it is possible to write code dealing with > Unicode that is fully compatible with Delphi at source level. > It will be compatible with a future UTF-16 solution in Lazarus as well. > Encoding agnostic (UTF-8 / UTF-16) code is possible even if you must > iterate individual codepoints. See the wiki page for details. > > Remember these to keep your code compatible: > 1. Normally use type "String". > 1. Assign a constant always to a type String variable. > 2. Use type UnicodeString explicitly for API calls that need it. I am not sure how much your second post rows back from this but I do think that false is a bit harsh. You seem to be coming from a view that strings are strings and the compiler should be allowed to work out what is the appropriate string encoding for the local environment. All the programmer has to do is declare the type as "string" and all will be good. I guess that is your definition of portable code: it is agnostic as regards the string encoding. I am coming from a much messier perspective that says a portable program has to deal with whatever string encoding is thrown at it. It may be valid criticism to say that I was taking a particularly messy example and deriving generic rules from it - but few programs work in a vacuum and it is worth being aware of real world problems. I my case, the real world problem is Firebird. Firebird will expect or give you a string encoded not according to the local environment but that which was specified for the database connection and it is the API user that decides this and not the API. Ideally, the user specifies UTF8, but Firebird supports many other string encodings - but not UTF16 or Unicode at present. In the original version of the library, the API was defined using the "string" type as were the internal structures. When I looked at moving to Delphi support, there was no way that this would work if "string" suddenly became "UnicodeString". All over the place I had assumed that "string" meant "AnsiString" including checking and setting the code page in order to match the connection character set with whatever code page was being used by the API user. Could I have written the API without being aware of the character encoding? I doubt it. The connection character set is not something that the compiler can be aware of. Part of the role of the API library is to manage the character encoding on behalf of the user. On the other hand, by defining the API using the explicit AnsiString type, it should mean that if the API user uses the "string" type, then the compiler can automatically transliterate from the API to the API user's string types when string means "UnicodeString". So is my messy example typical or atypical? Am I correct in offering it as a source of rules. Ideally, it is atypical. However, I would observe that few programs exist in isolation. They have to deal with external objects such as files, GUIs and TCP connections. The compiler cannot work out the character encoding for itself in these cases and either your program or some intermediate library has to be character coding aware in order to deal with these objects. The bottom line is that it would be great if we never needed to be aware of the character encoding behind the string type. However, all too often you do and, because of that, when you are writing code that is portable between platforms and compilers, you either needed to be explicit in the string type throughout your program, or at least in the modules that deal with external interfaces. Tony Whyman From tony.whyman at mccallumwhyman.com Mon May 1 18:49:52 2017 From: tony.whyman at mccallumwhyman.com (Tony Whyman) Date: Mon, 1 May 2017 17:49:52 +0100 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> Message-ID: <0d8586a6-8077-c432-1c0b-cd3f1cb3c851@mccallumwhyman.com> On 01/05/17 16:33, Sven Barth via Lazarus wrote: > Would you please elaborate on these and which FPC version you targeted? > > Regards, > Sven > > > I am working with FPC 3.0.x and an example of the solution I used follows. Note that with FPC, there is no problem calling a constructor from a placeholder, while with delphi I found it necessary to add an explicit coercion. I also wanted to return the interface provided by the object. Again with FPC, this is easy. With Delphi, I found it necessary to use QueryInterface to do the same. The difference between the two seems to be that FPC waits until the generic is instantiated before type checking while Delphi performs type checking when compiling the generic itself - or thereabouts. IMHO, FPC is much superior to Delphi in this area. {$IFDEF FPC} TOutputBlockItemGroup<_TItem,_IItem> = class(TOutputBlockItem) {$ELSE} TOutputBlockItemGroup<_TItem: TOutputBlockItem; _IItem: IUnknown> = class(TOutputBlockItem) {$ENDIF} public function GetItem(index: integer): _IItem; function Find(ItemType: byte): _IItem; property Items[index: integer]: _IItem read getItem; default; end; .... {$IFDEF FPC} { TOutputBlockItemGroup } function TOutputBlockItemGroup<_TItem,_IItem>.GetItem(index: integer): _IItem; var P: POutputBlockItemData; begin P := inherited getItem(index); Result := _TItem.Create(self.Owner,P); end; function TOutputBlockItemGroup<_TItem,_IItem>.Find(ItemType: byte): _IItem; var P: POutputBlockItemData; begin P := inherited Find(ItemType); Result := _TItem.Create(self.Owner,P); end; {$ELSE} { TOutputBlockItemGroup } function TOutputBlockItemGroup<_TItem,_IItem>.GetItem(index: integer): _IItem; var P: POutputBlockItemData; Obj: TOutputBlockItem; begin P := inherited getItem(index); Obj := TOutputBlockItemClass(_TItem).Create(self.Owner,P); if Obj.QueryInterface(GetTypeData(TypeInfo(_IItem))^.Guid,Result) <> 0 then IBError(ibxeInterfaceNotSupported,[GuidToString(GetTypeData(TypeInfo(_IItem))^.Guid)]); end; function TOutputBlockItemGroup<_TItem,_IItem>.Find(ItemType: byte): _IItem; var P: POutputBlockItemData; Obj: TOutputBlockItem; begin P := inherited Find(ItemType); Obj := TOutputBlockItemClass(_TItem).Create(self.Owner,P); if Obj.QueryInterface(GetTypeData(TypeInfo(_IItem))^.Guid,Result) <> 0 then IBError(ibxeInterfaceNotSupported,[GuidToString(GetTypeData(TypeInfo(_IItem))^.Guid)]); end; From pascaldragon at googlemail.com Mon May 1 19:36:22 2017 From: pascaldragon at googlemail.com (Sven Barth) Date: Mon, 1 May 2017 19:36:22 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <0d8586a6-8077-c432-1c0b-cd3f1cb3c851@mccallumwhyman.com> Message-ID: Am 01.05.2017 18:50 schrieb "Tony Whyman via Lazarus" < lazarus at lists.lazarus-ide.org>: > > > > On 01/05/17 16:33, Sven Barth via Lazarus wrote: >> >> Would you please elaborate on these and which FPC version you targeted? >> >> Regards, >> Sven >> >> >> > I am working with FPC 3.0.x and an example of the solution I used follows. Note that with FPC, there is no problem calling a constructor from a placeholder, while with delphi I found it necessary to add an explicit coercion. I also wanted to return the interface provided by the object. Again with FPC, this is easy. With Delphi, I found it necessary to use QueryInterface to do the same. > > The difference between the two seems to be that FPC waits until the generic is instantiated before type checking while Delphi performs type checking when compiling the generic itself - or thereabouts. IMHO, FPC is much superior to Delphi in this area. Your assumption about the way FPC and Delphi do things is indeed correct. Comments of mine follow inside your example. > {$IFDEF FPC} > TOutputBlockItemGroup<_TItem,_IItem> = class(TOutputBlockItem) > {$ELSE} > TOutputBlockItemGroup<_TItem: TOutputBlockItem; _IItem: IUnknown> = class(TOutputBlockItem) > {$ENDIF} You should be able to use the second variant with FPC as well. It would allow the compiler to do more type checking when parsing the generic instead of when specializing it. > public > function GetItem(index: integer): _IItem; > function Find(ItemType: byte): _IItem; > property Items[index: integer]: _IItem read getItem; default; > end; > > .... > > {$IFDEF FPC} > { TOutputBlockItemGroup } > > function TOutputBlockItemGroup<_TItem,_IItem>.GetItem(index: integer): _IItem; > var P: POutputBlockItemData; > begin > P := inherited getItem(index); > Result := _TItem.Create(self.Owner,P); > end; > > function TOutputBlockItemGroup<_TItem,_IItem>.Find(ItemType: byte): _IItem; > var P: POutputBlockItemData; > begin > P := inherited Find(ItemType); > Result := _TItem.Create(self.Owner,P); > end; > > > {$ELSE} > > { TOutputBlockItemGroup } > > function TOutputBlockItemGroup<_TItem,_IItem>.GetItem(index: integer): _IItem; > var P: POutputBlockItemData; > Obj: TOutputBlockItem; > begin > P := inherited getItem(index); > Obj := TOutputBlockItemClass(_TItem).Create(self.Owner,P); Is this typecast really needed? > if Obj.QueryInterface(GetTypeData(TypeInfo(_IItem))^.Guid,Result) <> 0 then > IBError(ibxeInterfaceNotSupported,[GuidToString(GetTypeData(TypeInfo(_IItem))^.Guid)]); > end; "Result := Obj;" does not work? What about "Result := Obj as _IItem;"? > function TOutputBlockItemGroup<_TItem,_IItem>.Find(ItemType: byte): _IItem; > var P: POutputBlockItemData; > Obj: TOutputBlockItem; > begin > P := inherited Find(ItemType); > Obj := TOutputBlockItemClass(_TItem).Create(self.Owner,P); > if Obj.QueryInterface(GetTypeData(TypeInfo(_IItem))^.Guid,Result) <> 0 then > IBError(ibxeInterfaceNotSupported,[GuidToString(GetTypeData(TypeInfo(_IItem))^.Guid)]); > end; Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From juha.manninen62 at gmail.com Mon May 1 20:26:11 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Mon, 1 May 2017 21:26:11 +0300 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <77f79e46-0a44-b4d7-ef2d-6163ae226e02@mccallumwhyman.com> References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <77f79e46-0a44-b4d7-ef2d-6163ae226e02@mccallumwhyman.com> Message-ID: On Mon, May 1, 2017 at 7:40 PM, Tony Whyman via Lazarus wrote: > I am not sure how much your second post rows back from this but I do think > that false is a bit harsh. Yes, sorry, it was correct when using the default types in FPC 3. However making it compatible with Delphi requires some effort, as you noticed. My experience is that the Unicode support provided by LazUtils leads to more Delphi compatible code. The Windows system codepages are a problem, yes. Then data must be converted in some I/O layer. Everybody please experiment with it. It can be used also for non-GUI code. Juha From md at delfire.net Tue May 2 01:13:18 2017 From: md at delfire.net (Marcos Douglas B. Santos) Date: Mon, 1 May 2017 20:13:18 -0300 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> Message-ID: On Mon, May 1, 2017 at 6:30 AM, Tony Whyman via Lazarus wrote: > Marcos, > > When I originally created the Firebird Pascal API package, I wrote it with > FPC as the only intended target. However, I then got feedback asking for > Delphi compatibility and I couldn't resist the challenge of seeing how easy > it would be to convert the source code. In the end, it was not that > difficult and the following summarises the changes needed (apart from the > minor syntax changes): > > [...snip...] > Tony, thank you for all these tips. Best regards, Marcos Douglas From md at delfire.net Tue May 2 01:15:46 2017 From: md at delfire.net (Marcos Douglas B. Santos) Date: Mon, 1 May 2017 20:15:46 -0300 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <20170501134739.7f3ccedf@limapholos.matflo.wg> References: <20170501134739.7f3ccedf@limapholos.matflo.wg> Message-ID: On Mon, May 1, 2017 at 8:47 AM, Mattias Gaertner via Lazarus wrote: > Option a) You can use English in sources and load all non ASCII > constants via resourcestrings or similar. Then the codepage is > irrelevant. > Option b) You can store all files as UTF-8 with BOM. Then FPC will > store all non ASCII string constants as unicodestrings. Be careful when > using PChar with them. This adds implicit conversions, so it might be > slower. > Maybe option A could be the best. I did not remember to use resourcestrings... it is a good tip, thanks. Marcos Douglas From md at delfire.net Tue May 2 01:30:19 2017 From: md at delfire.net (Marcos Douglas B. Santos) Date: Mon, 1 May 2017 20:30:19 -0300 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> Message-ID: On Mon, May 1, 2017 at 11:06 AM, Juha Manninen via Lazarus wrote: > On Mon, May 1, 2017 at 12:30 PM, Tony Whyman via Lazarus > ... > > No! The good idea is to use "String". I agree. >> 5. Take care when using string literals. >> I added >> {$IFDEF FPC} >> {$codepage UTF8} >> {$ENDIF} > > Yes, string literals are tricky but usually you should NOT use {$codepage UTF8}. > It is explained in the wiki page. I will not repeat it here. So, as Mattias said, we should code using ANSI chars and everything will be Ok. >> 7. Generics > > For Delphi compatible generics you can use FPC trunk and the Generics > Collection lib made by Maciej. Is it part of FPC? If not, could you can post the official URL? >> I hope you find this a useful checklist. > > It contained so much false information that it only confuses people. :( > > I want to repeat that it is possible to write code dealing with > Unicode that is fully compatible with Delphi at source level. > It will be compatible with a future UTF-16 solution in Lazarus as well. > Encoding agnostic (UTF-8 / UTF-16) code is possible even if you must > iterate individual codepoints. See the wiki page for details. That is I wanted to read. Thanks. Some doubts: > Remember these to keep your code compatible: > 1. Normally use type "String". > 1. Assign a constant always to a type String variable. What do you mean? Instead of create a constant, is it better create a String variable and assign the string to it? > 2. Use type UnicodeString explicitly for API calls that need it. Best regards, Marcos Douglas From juha.manninen62 at gmail.com Tue May 2 10:30:07 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Tue, 2 May 2017 11:30:07 +0300 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> Message-ID: On Tue, May 2, 2017 at 2:30 AM, Marcos Douglas B. Santos via Lazarus wrote: > So, as Mattias said, we should code using ANSI chars and everything will be Ok. No, you can use all the Unicode freely. The source files are saved as UTF-8 by default. Delphi does the same, this detail is also compatible. >> For Delphi compatible generics you can use FPC trunk and the Generics >> Collection lib made by Maciej. > > Is it part of FPC? If not, could you can post the official URL? It is part of FPC trunk. >> 1. Assign a constant always to a type String variable. > > What do you mean? Instead of create a constant, is it better create a > String variable and assign the string to it? >From FPC's point of view our UTF-8 solution is a hack. In practice it means that success in assigning string literals depends on the string type. This: S := 'Have 🍷 for FPC 💓 Lazarus'; always works if "S" is a "String". It may not work with other string types. It is all explained in the wiki page. When all your string data is Unicode then you can code in a Delphi compatible way. Only the Windows system codepages impose a problem, but I got an impression you don't need them now. Juha From juha.manninen62 at gmail.com Tue May 2 10:58:53 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Tue, 2 May 2017 11:58:53 +0300 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: Message-ID: On Sun, Apr 30, 2017 at 7:37 PM, Marcos Douglas B. Santos via Lazarus wrote: > If Delphi sources don't use UTF8, how is the best way to mantain sources > that need to work in both compilers? I wonder if I have misunderstood something about your questions. What means "Delphi sources don't use UTF8"? AFAIK they do use UTF8. One more clarification about assigning string data: The potential problem is only with string literals, constants. Assignment between variables always goes right thanks to their dynamic encoding in FPC 3+. Juha From henry.vermaak at gmail.com Tue May 2 16:30:15 2017 From: henry.vermaak at gmail.com (Henry Vermaak) Date: Tue, 2 May 2017 15:30:15 +0100 Subject: [Lazarus] How to deploy a Lazarus app for Windows? In-Reply-To: References: <8eb1cb00-2d6c-e680-d161-a9f91e5bcc32@fastwebnet.it> <1cf07bae-e574-a9be-a257-bd472edb03d2@zoznam.sk> Message-ID: <20170502143015.GA29201@technical09.Axicon2.local> On Sat, Apr 29, 2017 at 09:00:14AM +0100, Tony Whyman via Lazarus wrote: > +1 > > IMHO, WIX is the best way to create Windows installer packages. It has the > great advantage of using XML scripts to define the installation package. > This allows you to put them under proper change control and makes it easy to > copy and edit the script for each new application rather than start from > scratch. The WIX toolset also runs under wine and with a FPC cross-compiler, > it is possible to build both a Windows executable and the installer package > under Linux. I have some applications that I deploy under both Windows and > Linux and all the builds are performed from a single bash script under > Linux. You can also use 7-zip to create a self-installer package from the > .msi. WiX also makes installing drivers painless. It fits nicely into the Makefile paradigm, so plays well with the rest of our build system, too. Henry From md at delfire.net Wed May 3 02:16:19 2017 From: md at delfire.net (Marcos Douglas B. Santos) Date: Tue, 2 May 2017 21:16:19 -0300 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> Message-ID: On Tue, May 2, 2017 at 5:30 AM, Juha Manninen via Lazarus wrote: >>> 1. Assign a constant always to a type String variable. >> >> What do you mean? Instead of create a constant, is it better create a >> String variable and assign the string to it? > > From FPC's point of view our UTF-8 solution is a hack. In practice it > means that success in assigning string literals depends on the string > type. > This: > S := 'Have 🍷 for FPC 💓 Lazarus'; > always works if "S" is a "String". It may not work with other string types. > It is all explained in the wiki page. I understood, thanks. > When all your string data is Unicode then you can code in a Delphi > compatible way. > Only the Windows system codepages impose a problem, but I got an > impression you don't need them now. I am develop on Windows. What problems do you mean? Marcos Douglas From md at delfire.net Wed May 3 02:21:49 2017 From: md at delfire.net (Marcos Douglas B. Santos) Date: Tue, 2 May 2017 21:21:49 -0300 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: Message-ID: On Tue, May 2, 2017 at 5:58 AM, Juha Manninen via Lazarus wrote: > On Sun, Apr 30, 2017 at 7:37 PM, Marcos Douglas B. Santos via Lazarus > wrote: >> If Delphi sources don't use UTF8, how is the best way to mantain sources >> that need to work in both compilers? > > I wonder if I have misunderstood something about your questions. > What means "Delphi sources don't use UTF8"? > AFAIK they do use UTF8. Sorry about that. I stopped using Delphi at version 7, that uses ANSI. I thought that Delphi nowadays was using UTF16. I will install Delphi Tokyo Starter and discover these things. > One more clarification about assigning string data: > The potential problem is only with string literals, constants. > Assignment between variables always goes right thanks to their dynamic > encoding in FPC 3+. But if I put theses constants as resourcestrings, it's Ok as Mattias told me, right? Thank you for these tips. Best regards, Marcos Douglas From mailinglists at geldenhuys.co.uk Wed May 3 10:52:47 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 3 May 2017 09:52:47 +0100 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> Message-ID: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> On 2017-05-02 09:30, Juha Manninen via Lazarus wrote: > From FPC's point of view our UTF-8 solution is a hack. FPC's point of view or Marco's point of view? Just curious - so what is FPC’s “correct” solution then for using UTF-8 and the preferred encoding? What's the alternative they offer? [rant] ps: Both FPC and Delphi is in such a messed up state when it comes to string and character types. It is the laughing stock of programming languages at the moment. At least EMBT is heading in the right direction with their Linux Delphi compiler - they completely removed AnsiString. FPC and Delphi can learn a huge lesson from Java and Qt in how to handle string and character types. [/rant] 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 May 3 10:59:35 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 3 May 2017 09:59:35 +0100 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: Message-ID: On 2017-05-03 01:21, Marcos Douglas B. Santos via Lazarus wrote: > Sorry about that. I stopped using Delphi at version 7, that uses ANSI. > I thought that Delphi nowadays was using UTF16. They (Delphi) loves to follow Microsoft. Files are stored in UTF-8 (this is the norm), but they use UTF-16 internally. Lazarus stores files in UTF-8 and uses UTF-8 internally. Some background info ==================== UTF-16 was the first encoding implementation for Unicode - at a time when they thought 2-bytes will be big enough for everything. They were wrong. So then they invented UTF-8 to solve the problem. But by that time Microsoft already standardised on UTF-16, so Delphi followed suite. Linux, FreeBSD etc saw the light and used UTF-8 instead. 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 May 3 11:03:41 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Wed, 3 May 2017 12:03:41 +0300 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: Message-ID: Marcos Douglas B. Santos wrote: > I am develop on Windows. What problems do you mean? Unicode is recommended also on Windows. No worries. You don't need to use the old system codepages. People who need them must convert them explicitly because the Unicode system of Lazarus does not support them directly. > Sorry about that. I stopped using Delphi at version 7, that uses ANSI. > I thought that Delphi nowadays was using UTF16. > I will install Delphi Tokyo Starter and discover these things. You confuse separate things now. The encoding of their "String" is now UTF-16. Source files are saved as UTF-8. > But if I put theses constants as resourcestrings, it's Ok as Mattias > told me, right? I don't think it makes any difference. You can use the full Unicode in both cases. --- I am puzzled why there were so many misleading and confusing replies, also from knowledgeable Lazarus developers. Remember, the question was about making sources compatible with Delphi. The person (Marcos Douglas) did not know details of how strings work in Delphi and Lazarus. Now we finally have a system that allows (more or less) compatible code when using Unicode. Why was it not even mentioned by you guys? For example: Ondrej Pokorny wrote: > Speaking from my experience, the only approach (not only the best one but > the only one) is not to use characters above #255. Nonsense. Full Unicode is supported. Mattias Gaertner wrote: > Option a) You can use English in sources and load all non ASCII > constants via resourcestrings or similar. Then the codepage is > irrelevant. > Option b) You can store all files as UTF-8 with BOM. Then FPC will > store all non ASCII string constants as unicodestrings. Be careful when > using PChar with them. This adds implicit conversions, so it might be > slower. That must be very confusing. Why didn't you just tell him to use the default Unicode support in Lazarus which allows to write Delphi compatible code, just by remembering couple of rules. Also Tony's advice to use AnsiString explicitly is quite irresponsible for a person who looks for Delphi compatibility. AnsiString is not Delphi compatible any more in our system and it brings you back to stone-age in Delphi, to the horrors of system codepages. Is it possible that people still don't know how Delphi compatible the Lazarus Unicode system is (unless you need the old system codepages obviously)? For example Lazarus developer Werner (wp) didn't know the Ansi...() string functions, like AnsiCompareStr(), are compatible with Delphi. http://forum.lazarus.freepascal.org/index.php/topic,36664.msg244619.html#msg244619 Yes they are! Please also look at program LazUnicodeTest in components/lazutils/test/. It does advanced Unicode stuff and works in both Delphi and Lazarus. It means any code dealing with Unicode can do it. How could this thing be communicated so that people understand? Why other Lazarus developers don't want to mention it? I am puzzled. :( Juha From lazarus at kluug.net Wed May 3 11:13:55 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Wed, 3 May 2017 11:13:55 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: Message-ID: <84ef6f25-4d35-5df7-da81-b9bccc88ee4f@kluug.net> On 03.05.2017 11:03, Juha Manninen via Lazarus wrote: > I am puzzled why there were so many misleading and confusing replies, > also from knowledgeable Lazarus developers. > Remember, the question was about making sources compatible with Delphi. > The person (Marcos Douglas) did not know details of how strings work > in Delphi and Lazarus. > Now we finally have a system that allows (more or less) compatible > code when using Unicode. Why was it not even mentioned by you guys? > > For example: > > Ondrej Pokorny wrote: >> Speaking from my experience, the only approach (not only the best one but >> the only one) is not to use characters above #255. > Nonsense. Full Unicode is supported. Not if you need pre-unicode Delphi support :) (Well, Marcos didn't specify what Delphi version he wants to target but he stated "If Delphi sources don't use UTF8 [...]", which applies to pre-unicode Delphi versions.) Ondrej From juha.manninen62 at gmail.com Wed May 3 11:21:18 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Wed, 3 May 2017 12:21:18 +0300 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> Message-ID: On Wed, May 3, 2017 at 11:52 AM, Graeme Geldenhuys via Lazarus wrote: > At least EMBT is heading in the right direction with their > Linux Delphi compiler - they completely removed AnsiString. I must agree with you. I hope it will be removed in (far) future when nobody uses the old Windows system codepages any more. Windows already supports Unicode in everything ... except for console output! Why is that? Anyway, please let's leave out encoding supremacy issues now. My point has been that our Unicode solution makes the encoding issues irrelevent. It is almost compatible at source level despite the different encodings. Think how improbable that is, yet it works. See also the encoding agnostic support provided by LazUnicode. Encoding does not matter any more, as long as it is Unicode. Juha From lazarus at kluug.net Wed May 3 11:25:43 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Wed, 3 May 2017 11:25:43 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> Message-ID: On 03.05.2017 11:21, Juha Manninen via Lazarus wrote: > Windows already supports Unicode in everything ... except for console > output! Why is that? You can start the console with UTF-8 codepage: http://stackoverflow.com/questions/14109024/how-to-make-unicode-charset-in-cmd-exe-by-default Then you have full unicode (utf-8) support. Ondrej From mailinglists at geldenhuys.co.uk Wed May 3 11:34:39 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 3 May 2017 10:34:39 +0100 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> Message-ID: On 2017-05-03 10:25, Ondrej Pokorny via Lazarus wrote: > You can start the console with UTF-8 codepage: > http://stackoverflow.com/questions/14109024/how-to-make-unicode-charset-in-cmd-exe-by-default > > Then you have full unicode (utf-8) support. Or use the much better console alternatives. The Windows platform is finally catching on to what was been available in X11 environments for years - multiple choice on consoles. For example, take a look at ConEmu for Windows. * Tab support built-in * Resizeable console windows * User defined encoding per console window * Font choice * better mouse & clipboard support * User defined "console engine" per window or tab. eg: I can have Bash run in one tab and the standard windows console in another. * color customisation * transparency support https://sourceforge.net/projects/conemu/ I don't know why anybody would still want to run the standard Windows console - it is 20 years behind everybody else. 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 May 3 11:37:53 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Wed, 3 May 2017 12:37:53 +0300 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <84ef6f25-4d35-5df7-da81-b9bccc88ee4f@kluug.net> References: <84ef6f25-4d35-5df7-da81-b9bccc88ee4f@kluug.net> Message-ID: On Wed, May 3, 2017 at 12:13 PM, Ondrej Pokorny via Lazarus wrote: > Not if you need pre-unicode Delphi support :) Ok, true. IMO such old Delphi versions should not be used any more for new code. Maintenance tasks only I think. Fortunately there is again a free Delphi Starter edition. It means anybody can use the latest version. Things are surely getting better! Juha From juergen.hestermann at gmx.de Wed May 3 11:53:26 2017 From: juergen.hestermann at gmx.de (=?UTF-8?Q?J=c3=bcrgen_Hestermann?=) Date: Wed, 3 May 2017 11:53:26 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> Message-ID: <1c82b5eb-ef1e-03fc-6fd8-26f3b93d1fba@gmx.de> Am 2017-05-03 um 11:34 schrieb Graeme Geldenhuys via Lazarus: > I don't know why anybody would still want to run the standard Windows > console - it is 20 years behind everybody else. The reason: It is available on every Windows machine. The alternatives need to be installed first so scripts designed for them don't work out of the box. From nc-gaertnma at netcologne.de Wed May 3 13:29:00 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Wed, 3 May 2017 13:29:00 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: Message-ID: <20170503132900.7cc8013c@limapholos.matflo.wg> On Wed, 3 May 2017 12:03:41 +0300 Juha Manninen via Lazarus wrote: >[...] > Mattias Gaertner wrote: > > Option a) You can use English in sources and load all non ASCII > > constants via resourcestrings or similar. Then the codepage is > > irrelevant. > > Option b) You can store all files as UTF-8 with BOM. Then FPC will > > store all non ASCII string constants as unicodestrings. Be careful when > > using PChar with them. This adds implicit conversions, so it might be > > slower. > > That must be very confusing. Why didn't you just tell him to use the > default Unicode support in Lazarus which allows to write Delphi > compatible code, just by remembering couple of rules. The "default Unicode support in Lazarus" is not compatible with Delphi. For compatibility it needs the BOM. Do you have a link where the couple of rules are listed? Mattias From nc-gaertnma at netcologne.de Wed May 3 13:43:20 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Wed, 3 May 2017 13:43:20 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: Message-ID: <20170503134320.30675bde@limapholos.matflo.wg> On Wed, 3 May 2017 12:03:41 +0300 Juha Manninen via Lazarus wrote: >[...] > Please also look at program LazUnicodeTest in components/lazutils/test/. > It does advanced Unicode stuff and works in both Delphi and Lazarus. I tried it: First it did not compile in Delphi, because of an unsupported inline. I fix that with an IFDEF FPC. Then it runs. The output is somewhat hard to interpret as the Windows console shows many chars as '?' and the writelns do not explain what it is supposed to show. The good news is that it works. The bad news is, that it only works because Delphi silently altered the source file and added the BOM. Back in Lazarus compiling such a file gives the error: LazUnicodeTest.lpr(28,10) Error: UTF-8 code greater than 65535 found > It means any code dealing with Unicode can do it. > > How could this thing be communicated so that people understand? > Why other Lazarus developers don't want to mention it? > I am puzzled. :( You are right, that using Unicode with Lazarus only needs a couple of rules to follow. Sharing code with Delphi adds a few more rules. Mattias From juha.manninen62 at gmail.com Wed May 3 14:15:53 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Wed, 3 May 2017 15:15:53 +0300 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <20170503134320.30675bde@limapholos.matflo.wg> References: <20170503134320.30675bde@limapholos.matflo.wg> Message-ID: On Wed, May 3, 2017 at 2:43 PM, Mattias Gaertner via Lazarus wrote: > First it did not compile in Delphi, because of an unsupported inline. I > fix that with an IFDEF FPC. Right, I had added that after testing with Delphi. The inline looks good to me, don't know why Delphi does not like it. > Then it runs. The output is somewhat hard to interpret as the > Windows console shows many chars as '?' and the writelns do not > explain what it is supposed to show. > The good news is that it works. Yes, I guess it should be a GUI app. The console is the only place in Windows not supporting Unicode still. Damn MS, they have supported Unicode in other APIs and apps for nearly 20 years already. > The bad news is, that it only works because Delphi silently altered > the source file and added the BOM. > Back in Lazarus compiling such a file gives the error: > LazUnicodeTest.lpr(28,10) Error: UTF-8 code greater than 65535 found Äh, I did not test moving it back to Lazarus. Hmmm... why does FPC not understand the BOM? > You are right, that using Unicode with Lazarus only needs a couple of > rules to follow. Sharing code with Delphi adds a few more rules. One valid choice is to edit in Lazarus and copy to Delphi only to be built. I understood Marcos Douglas planned something like that. If code really must be edited in both, how to solve it? This was another complication I did not think about. :( About the couple of rules to follow, I had these in mind: 1. Normally use type "String". 2. Assign a constant always to a type String variable. 3. Use type UnicodeString explicitly for API calls that need it. They are not listed as a short list in wiki. The wiki page is more detailed. Maybe they should be listed as a "Getting started" paragraph. Juha From md at delfire.net Wed May 3 14:28:55 2017 From: md at delfire.net (Marcos Douglas B. Santos) Date: Wed, 3 May 2017 09:28:55 -0300 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: Message-ID: On Wed, May 3, 2017 at 5:59 AM, Graeme Geldenhuys via Lazarus wrote: > On 2017-05-03 01:21, Marcos Douglas B. Santos via Lazarus wrote: >> Sorry about that. I stopped using Delphi at version 7, that uses ANSI. >> I thought that Delphi nowadays was using UTF16. > > They (Delphi) loves to follow Microsoft. Files are stored in UTF-8 (this > is the norm), but they use UTF-16 internally. > > Lazarus stores files in UTF-8 and uses UTF-8 internally. > > Some background info > ==================== > UTF-16 was the first encoding implementation for Unicode - at a time > when they thought 2-bytes will be big enough for everything. They were > wrong. So then they invented UTF-8 to solve the problem. But by that > time Microsoft already standardised on UTF-16, so Delphi followed suite. > Linux, FreeBSD etc saw the light and used UTF-8 instead. Ok, thank you for these informations. best regards, Marcos Douglas From nc-gaertnma at netcologne.de Wed May 3 14:37:00 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Wed, 3 May 2017 14:37:00 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <20170503134320.30675bde@limapholos.matflo.wg> Message-ID: <20170503143700.7ae3d108@limapholos.matflo.wg> On Wed, 3 May 2017 15:15:53 +0300 Juha Manninen via Lazarus wrote: >[...] > > Back in Lazarus compiling such a file gives the error: > > LazUnicodeTest.lpr(28,10) Error: UTF-8 code greater than 65535 found > > Äh, I did not test moving it back to Lazarus. Well, that's the point of sharing code, isn't it? > Hmmm... why does FPC not understand the BOM? It does. And so does Delphi. But with and without BOM have different meanings. > > You are right, that using Unicode with Lazarus only needs a couple of > > rules to follow. Sharing code with Delphi adds a few more rules. > > One valid choice is to edit in Lazarus and copy to Delphi only to be > built. I understood Marcos Douglas planned something like that. > If code really must be edited in both, how to solve it? That's what I tried to explain to Marcos and what you described as "That must be very confusing." > This was another complication I did not think about. :( > > About the couple of rules to follow, I had these in mind: > 1. Normally use type "String". > 2. Assign a constant always to a type String variable. > 3. Use type UnicodeString explicitly for API calls that need it. 4. When sharing code with Delphi use BOM or use only ASCII constants. You can choose for each unit. Either way load texts using resourcestring or similar techniques. 5. What about Char and aString[]? 6. What about PChar? > They are not listed as a short list in wiki. The wiki page is more detailed. > Maybe they should be listed as a "Getting started" paragraph. Good idea. Mattias From tony.whyman at mccallumwhyman.com Wed May 3 14:37:24 2017 From: tony.whyman at mccallumwhyman.com (Tony Whyman) Date: Wed, 3 May 2017 13:37:24 +0100 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> Message-ID: On 03/05/17 09:52, Graeme Geldenhuys via Lazarus wrote: > [rant] > ps: > Both FPC and Delphi is in such a messed up state when it comes to > string and character types. It is the laughing stock of programming > languages at the moment. At least EMBT is heading in the right > direction with their Linux Delphi compiler - they completely removed > AnsiString. > > FPC and Delphi can learn a huge lesson from Java and Qt in how to > handle string and character types. > [/rant] > > Regards, > Graeme Is Delphi/FPC string handling that much worse than 'C'? To me, the great thing about AnsiString is that it provides unified handling of UTF8 and legacy codepages in a single managed type by including the code page id as a dynamic property of the string. On the other hand, AnsiString and UnicodeString are still separate types. Why? Why should there not be a single unified string type with (e.g.) ASCII, UTF8 and UTF-16 (or MS Unicode) being just another code page? From nc-gaertnma at netcologne.de Wed May 3 14:47:13 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Wed, 3 May 2017 14:47:13 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> Message-ID: <20170503144713.015a1939@limapholos.matflo.wg> On Wed, 3 May 2017 13:37:24 +0100 Tony Whyman via Lazarus wrote: >[...] > On the other hand, AnsiString and UnicodeString are still separate > types. Why? Why should there not be a single unified string type with > (e.g.) ASCII, UTF8 and UTF-16 (or MS Unicode) being just another code page? Many 8bit string functions work for any 8bit encoding, and so do many 16bit string functions for any 16bit encoding. But almost no string function works for both. Mattias From listbox at martoks-place.de Wed May 3 15:34:41 2017 From: listbox at martoks-place.de (Martok) Date: Wed, 3 May 2017 15:34:41 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: Message-ID: Am 03.05.2017 um 11:03 schrieb Juha Manninen via Lazarus: > How could this thing be communicated so that people understand? It would probably help if there weren't three different pages about "Unicode Support" on the wiki, all saying slightly different and conflicting things (because they talk about different things, but that's really not obvious unless you already know) and decidedly *not* saying what a user might want to know... Maybe split the technical internals from a "simpler" user's guide? Martok From mailinglists at geldenhuys.co.uk Wed May 3 16:36:05 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 3 May 2017 15:36:05 +0100 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> Message-ID: <6057f72a-5dab-3d02-2d5e-93e02096fd19@geldenhuys.co.uk> On 2017-05-03 13:37, Tony Whyman via Lazarus wrote: > Is Delphi/FPC string handling that much worse than 'C'? I can’t answer about C, but compared to Java and Qt’s solution, Delphi and FPC’s solutions are terrible and very confusing. Regards, Graeme From pascaldragon at googlemail.com Wed May 3 18:50:44 2017 From: pascaldragon at googlemail.com (Sven Barth) Date: Wed, 3 May 2017 18:50:44 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> Message-ID: Am 03.05.2017 11:34 schrieb "Graeme Geldenhuys via Lazarus" < lazarus at lists.lazarus-ide.org>: > For example, take a look at ConEmu for Windows. > * Tab support built-in > * Resizeable console windows While not point and click you can resize console windows (and the window buffer) without problems. And it's even remembered *per shortcut*! > * User defined encoding per console window While not selectable upon start (I think) it can easily be changed with a command. > * Font choice Supported since at least XP > * better mouse & clipboard support If you use the PowerShell window that experience is already vastly improved. Could be that this is the case for the default console window in Windows 10 as well. > * User defined "console engine" per window or tab. > eg: I can have Bash run in one tab and the standard > windows console in another. No one stops you from running a different shell in a command window (e.g. I often switch to cmd inside PowerShell when some program give me trouble with the latter). > * color customisation Already supported since at least Windows 7 (can't currently check older versions). > I don't know why anybody would still want to run the standard Windows > console - it is 20 years behind everybody else. Because it does its job and its part of the OS without the need to install some 3rd party application. Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From pascaldragon at googlemail.com Wed May 3 18:53:50 2017 From: pascaldragon at googlemail.com (Sven Barth) Date: Wed, 3 May 2017 18:53:50 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> Message-ID: Am 03.05.2017 14:37 schrieb "Tony Whyman via Lazarus" < lazarus at lists.lazarus-ide.org>: > On the other hand, AnsiString and UnicodeString are still separate types. Why? Why should there not be a single unified string type with (e.g.) ASCII, UTF8 and UTF-16 (or MS Unicode) being just another code page? Because indexed access to the string data would slow down quite a bit as the RTL would need to determine whether the string is a 1-Byte, 2-Byte, 4-Byte or multi Byte String. Yes the compiler could do optimizations for this inside loops, but it would definitely slow down -O- code. Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From juha.manninen62 at gmail.com Wed May 3 21:47:15 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Wed, 3 May 2017 22:47:15 +0300 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: Message-ID: On Wed, May 3, 2017 at 12:03 PM, Juha Manninen wrote: > Marcos Douglas B. Santos wrote: >> But if I put theses constants as resourcestrings, it's Ok as Mattias >> told me, right? > > I don't think it makes any difference. You can use the full Unicode in > both cases. I stand corrected. If you share and edit the sources between Delphi and Lazarus then you cannot use the full Unicode. Resourcestrings work for translated Unicode texts. If you edit only with Lazarus and copy the files for Delphi compilation then you can use full Unicode. Actually I now remember testing with UTF-8 BOM and noticing the same issue but I forgot already. This is an unfortunate side-effect of the solution being a hack. It is so close to being easily portable. Why Delphi adds the BOM? Why can't it just read the file and understand it is UTF-8? If somebody is interested, this could be solved by removing the BOM from all files by a script before opening again in Lazarus. It could even be a plugin package in Lazarus. It would be relatively easy to implement. How many people are editing their sources in both Delphi and Lazarus? Juha From lazarus at kluug.net Wed May 3 22:18:59 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Wed, 3 May 2017 22:18:59 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: Message-ID: On 03.05.2017 21:47, Juha Manninen via Lazarus wrote: > How many people are editing their sources in both Delphi and Lazarus? Me, but I keep the files ASCII-only because I need to target all Delphi versions down to D5 :/ My customers really demand it, unfortunately. I'd like to kill these dinosaurs, believe me - not the customers but the thousand different Delphi versions from ancient eras, during the best period even 2 of them in a year :) I still feel that code should be in English, including comments - and I am a patriot, even if it is not popular nowadays :). The utf-8 bom seems to be a stupid issue, though. Ondrej From pascaldragon at googlemail.com Wed May 3 22:28:53 2017 From: pascaldragon at googlemail.com (Sven Barth) Date: Wed, 3 May 2017 22:28:53 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: Message-ID: On 03.05.2017 21:47, Juha Manninen via Lazarus wrote: > Why Delphi adds the BOM? Why can't it just read the file and > understand it is UTF-8? Probably for the same reason as FPC: the default code page if no BOM is available and no command line option is set and no $codepage directive is found is ISO-8859-1. A BOM does the same as the command line option -FcUTF8 or the directive {$codepage utf8}, namely switching the source codepage to UTF-8. Only then string constants that contain UTF-8 characters are converted to UnicodeString constants. Regards, Sven From mailinglists at geldenhuys.co.uk Wed May 3 23:55:19 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 3 May 2017 22:55:19 +0100 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: Message-ID: <950e811e-500c-68ed-3fa3-e0941ac529d4@geldenhuys.co.uk> On 2017-05-03 20:47, Juha Manninen via Lazarus wrote: > If you share and edit the sources between Delphi and Lazarus then you > cannot use the full Unicode. Quite comical considering that the FPC team always makes such a big fuss about "we want Delphi compatibility", and now it seems to be worse than ever before. Regards, Graeme From md at delfire.net Thu May 4 04:40:37 2017 From: md at delfire.net (Marcos Douglas B. Santos) Date: Wed, 3 May 2017 23:40:37 -0300 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <84ef6f25-4d35-5df7-da81-b9bccc88ee4f@kluug.net> References: <84ef6f25-4d35-5df7-da81-b9bccc88ee4f@kluug.net> Message-ID: On Wed, May 3, 2017 at 6:13 AM, Ondrej Pokorny via Lazarus wrote: > Not if you need pre-unicode Delphi support :) > > (Well, Marcos didn't specify what Delphi version he wants to target but he > stated "If Delphi sources don't use UTF8 [...]", which applies to > pre-unicode Delphi versions.) Yeah, sorry. I said that because I didn't know which encoding Delphi is using nowadays. But I would like to use only Delphi with Unicode support with "dot.unit.support". Marcos Douglas From md at delfire.net Thu May 4 06:05:42 2017 From: md at delfire.net (Marcos Douglas B. Santos) Date: Thu, 4 May 2017 01:05:42 -0300 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <20170503143700.7ae3d108@limapholos.matflo.wg> References: <20170503134320.30675bde@limapholos.matflo.wg> <20170503143700.7ae3d108@limapholos.matflo.wg> Message-ID: On Wed, May 3, 2017 at 9:37 AM, Mattias Gaertner via Lazarus wrote: >> Hmmm... why does FPC not understand the BOM? > > It does. And so does Delphi. But with and without BOM have different > meanings. > > >> > You are right, that using Unicode with Lazarus only needs a couple of >> > rules to follow. Sharing code with Delphi adds a few more rules. >> >> One valid choice is to edit in Lazarus and copy to Delphi only to be >> built. I understood Marcos Douglas planned something like that. >> If code really must be edited in both, how to solve it? > > That's what I tried to explain to Marcos and what you described as > "That must be very confusing." > > >> This was another complication I did not think about. :( >> >> About the couple of rules to follow, I had these in mind: >> 1. Normally use type "String". >> 2. Assign a constant always to a type String variable. >> 3. Use type UnicodeString explicitly for API calls that need it. > > 4. When sharing code with Delphi use BOM or use only ASCII constants. > You can choose for each unit. Either way load texts using > resourcestring or similar techniques. > > 5. What about Char and aString[]? > 6. What about PChar? I got it. Best regards, Marcos Douglas From juha.manninen62 at gmail.com Thu May 4 09:45:14 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Thu, 4 May 2017 10:45:14 +0300 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <950e811e-500c-68ed-3fa3-e0941ac529d4@geldenhuys.co.uk> References: <950e811e-500c-68ed-3fa3-e0941ac529d4@geldenhuys.co.uk> Message-ID: On Thu, May 4, 2017 at 12:55 AM, Graeme Geldenhuys via Lazarus wrote: > On 2017-05-03 20:47, Juha Manninen via Lazarus wrote: >> If you share and edit the sources between Delphi and Lazarus then you >> cannot use the full Unicode. > > Quite comical considering that the FPC team always makes such a big fuss > about "we want Delphi compatibility", and now it seems to be worse than > ever before. Well, the code + its string literals are compatible. If you copy/paste them, they compile and work. Now only this small invisible BOM screws up things. Actually the IDE could have an option to remove the BOM. No scripts or packages are needed for that. It should be easy to implement. I will look at it later, hold on ... Juha From tony.whyman at mccallumwhyman.com Thu May 4 10:56:18 2017 From: tony.whyman at mccallumwhyman.com (Tony Whyman) Date: Thu, 4 May 2017 09:56:18 +0100 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> Message-ID: <3deb9f06-45df-8b71-e33d-a25a308a113d@mccallumwhyman.com> On 03/05/17 17:53, Sven Barth via Lazarus wrote: > > Am 03.05.2017 14:37 schrieb "Tony Whyman via Lazarus" > >: > > On the other hand, AnsiString and UnicodeString are still separate > types. Why? Why should there not be a single unified string type with > (e.g.) ASCII, UTF8 and UTF-16 (or MS Unicode) being just another code > page? > > Because indexed access to the string data would slow down quite a bit > as the RTL would need to determine whether the string is a 1-Byte, > 2-Byte, 4-Byte or multi Byte String. Yes the compiler could do > optimizations for this inside loops, but it would definitely slow down > -O- code. > > Regards, > Sven > > > I don't believe that string indexing even works for UTF8 strings at present - at least not in a simple s[i] way. Is it really that much overhead to have a simple codepage check before calling the correct function to index a string? The obvious optimisation would be to check for UTF8, then UTF16 then the Default codepage and then the rest. Or perhaps UTF16 first for Windows. With register level code you are talking about very few actual machine level operations. To me, a unified string type would have the advantage that: - You would only have one managed string type "string" (and hence avoids the confusion that exists today). - You would have standard string byte length and string character length functions (which yes, in the latter case, would have to have a codepage check as above). - String indexing could be standardised as always returning the character at position 'i' (including UTF8 strings - albeit after having to "walk" the string). - Automatic transliteration on string compare (with code page check of course) - and perhaps with the option to specific a non-standard collation. - Readily portable code. - The only time that a programmer has to think about the character encoding is when writing code that interacts directly with an external interface. How often would that extra lookup be significant compared with the benefits that unified string handling would bring? And, there is no reason why you could not retain the UnicodeString type for cases where you really need to optimise UTF16 handling. I see the unified string type as a further extension to AnsiString to include UTF16 and UCS2 code pages together with appropriate function support. Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaa5500 at ya.ru Thu May 4 11:07:31 2017 From: aaa5500 at ya.ru (Alexey) Date: Thu, 4 May 2017 12:07:31 +0300 Subject: [Lazarus] Hi-dpi icons suggestion Message-ID: I have suggestion for scaling hi-dpi for Speedbuttons with icons Now: icons scale by any scale, e.g. by 175% if OS scale is 175% It looks bad for 16x16 ide icons. they are looking broken. Suggestion: - until scale <200%, don't zoom icons, paint 16x even on bigger buttons - scale is >=200%, <300%, then zoom icons 2x times - scale is >=300%, then zoom icons 3x times (Can add prop, to keep /bad look/ on 175%) -- Regards, Alexey T. From mailinglists at geldenhuys.co.uk Thu May 4 11:15:47 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 4 May 2017 10:15:47 +0100 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <3deb9f06-45df-8b71-e33d-a25a308a113d@mccallumwhyman.com> References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <3deb9f06-45df-8b71-e33d-a25a308a113d@mccallumwhyman.com> Message-ID: On 2017-05-04 09:56, Tony Whyman via Lazarus wrote: > I don't believe that string indexing even works for UTF8 strings at > present - at least not in a simple s[i] way. It's simple, STOP using index arrays into strings. It doesn't work for Unicode! Use specialised code-point iterators or something similar instead. If you expect a Byte value from s[i] then fine, but if you expect a "character" (like something you see on the screen), then no it will never work. Why? See below: * UTF-16 will return a 2-byte value which isn't big enough to cover the full Unicode range BMP and above. * UTF-8 will return a 1-byte value which again isn't big enough to cover all possible code points in Unicode. For UTF-8 it could be anything from 1-4 bytes. * A "character seen on the screen" could be made up of multiple code points. eg: U+0065 (e) + U+0302 (^) gives you ê. So it might look like one "character", it is *not*. How is arraying indexing into a string supposed to handle this? It can't, unless it first normalises all Unicode strings, but even that will not work in all cases - because not all combining code points can be normalised. 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 Thu May 4 11:25:32 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 4 May 2017 10:25:32 +0100 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <3deb9f06-45df-8b71-e33d-a25a308a113d@mccallumwhyman.com> Message-ID: On 2017-05-04 10:15, Graeme Geldenhuys via Lazarus wrote: > * A "character seen on the screen" could be made up of multiple code > points. eg: U+0065 (e) + U+0302 (^) gives you ê. So it might look like > one "character", it is *not*. Applying better typography to that representation would yield: U+0065 (e) + U+0302 (̂◌) = ê. The “DejaVu Sans” font will render the above correctly. And here is a list of Combining Diacritics, and as I mentioned before, not all of them can be normalised into a single code-point “character”. Also some languages even use multiple combining diacritics for a single "character on the screen". https://en.wikipedia.org/wiki/Combining_Diacritical_Marks Regards, Graeme From nc-gaertnma at netcologne.de Thu May 4 11:42:07 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Thu, 4 May 2017 11:42:07 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <3deb9f06-45df-8b71-e33d-a25a308a113d@mccallumwhyman.com> References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <3deb9f06-45df-8b71-e33d-a25a308a113d@mccallumwhyman.com> Message-ID: <20170504114207.44730d7d@limapholos.matflo.wg> On Thu, 4 May 2017 09:56:18 +0100 Tony Whyman via Lazarus wrote: >[...] > I don't believe that string indexing even works for UTF8 strings at > present - at least not in a simple s[i] way. It exists the same as for UTF-16 strings. > Is it really that much overhead to have a simple codepage check before > calling the correct function to index a string? The obvious optimisation > would be to check for UTF8, then UTF16 then the Default codepage and > then the rest. Or perhaps UTF16 first for Windows. With register level > code you are talking about very few actual machine level operations. The char type does not fit widechar. You would need widechar. And in most cases the [] are used in loops. The compiler would have to add checks on each access. It would be faster to convert the string at the beginning to UnicodeString and back at the end. A technique that many RTL functions do to support any string type. > To me, a unified string type would have the advantage that: > > - You would only have one managed string type "string" (and hence avoids > the confusion that exists today). You can avoid the confusion by using only one string encoding, either UTF-8 or UTF-16. The problem is that existing libraries often support only one. >[...]> - The only time that a programmer has to think about the character > encoding is when writing code that interacts directly with an external > interface. That's already possible. With LazUTF8. The problem is legacy code and sharing code with Delphi. >[...] Mattias From markMLl.lazarus at telemetry.co.uk Thu May 4 12:02:01 2017 From: markMLl.lazarus at telemetry.co.uk (Mark Morgan Lloyd) Date: Thu, 4 May 2017 10:02:01 +0000 Subject: [Lazarus] How can I write to arbitrary position on device In-Reply-To: References: Message-ID: On 13/04/17 07:30, Mark Morgan Lloyd via Lazarus wrote: > On 12/04/17 21:30, Carlos E. R. via Lazarus wrote:> Hi,> I'm new on this > list, so if I should post this to a different place,> just tell me.> I > want to find a function that I can use on Linux to write a memory> block > to an arbitrary position on a device, say, /dev/sda or /dev/sda5 .> I > can do that on an opened file with seek() and write(), but apparently> > only on files. I need accessing the raw disk device. So currently I > call> 'dd' instead.> I also had problems with blockread/write: it failed > reading more than> one megabyte. > That's interesting, I need to look at some medium testing stuff over the > next few days and was assuming I'd need to check the dd sources. Are you > running as root to get direct access to the device? In case this is useful to anybody at any point: I was filling a device with a pattern and then reading it back, and found that the read time depended crucially on the amount of RAM available (relative to the size of device I was testing). This turned out to be because I was relying on Reset() with FileMode = 2 to open the file R/W, but this was causing the Linux kernel to buffer as much as possible in RAM. Switching to using Rewrite(), then closing and reopening with Reset() only if needed, resulted in predictable performance. So I think that the lesson is that Reset() should only be used for R/W files when the write and read operations are expected to be comparatively close to each other in time and position. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] From markMLl.lazarus at telemetry.co.uk Thu May 4 12:18:19 2017 From: markMLl.lazarus at telemetry.co.uk (Mark Morgan Lloyd) Date: Thu, 4 May 2017 10:18:19 +0000 Subject: [Lazarus] Startup environment: to Gui, or not to GUI? In-Reply-To: References: Message-ID: On 11/04/17 09:30, Mark Morgan Lloyd via Lazarus wrote: > Apologies if this is an FAQ. > Is there an orthodox way that a Lazarus program can very early on look > at how it's been started and decide whether it can usefully fall back to > a text mode, e.g. to display help info on stdout rather than a messagebox? > I'm tinkering with something (a media test program for SDCards etc.) > which I'd like to either run as a conventional console program, or using > a GUI. I've previously written stuff where operation was entirely > dependant on command-line options, but haven't tried making the decision > completely automatically. In case it helps anybody avoid wasted time: looking carefully at what I've been doing, it turns out that it's not possible to make an LCL-based program running on unix (i.e. with X11 etc.) to fall back cleanly to text mode, such that it could be run on e.g. a serial terminal, by manipulating the main program unit (.lpr or whatever). The problem is that the main unit will import LCL units which assume the presence of X11 or equivalent, and that they will attempt to initialise themselves before the main block in the .lpr is run. Hence any attempted decision in the .lpr is too late to be of much use. A program can fairly easily be written such that if it's started from a shell wrapped in a GUI (Konsole, xterm or whatever) it can display help or version text and quit in good order. The same applies if it's run from an SSH session provided that X11 tunnelling is enabled. But it won't run over e.g. a serial line or from the main console on a non-GUI system, and will probably give problems is executed as root using sudo or setuid. There might be ways of working round this using a special unit imported early (i.e. like cmem etc.), I've not experimented with that approach. -- 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 Thu May 4 13:01:40 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Thu, 4 May 2017 13:01:40 +0200 (CEST) Subject: [Lazarus] Startup environment: to Gui, or not to GUI? In-Reply-To: References: Message-ID: On Thu, 4 May 2017, Mark Morgan Lloyd via Lazarus wrote: > On 11/04/17 09:30, Mark Morgan Lloyd via Lazarus wrote: >> Apologies if this is an FAQ. >> Is there an orthodox way that a Lazarus program can very early on look >> at how it's been started and decide whether it can usefully fall back to >> a text mode, e.g. to display help info on stdout rather than a messagebox? >> I'm tinkering with something (a media test program for SDCards etc.) >> which I'd like to either run as a conventional console program, or using >> a GUI. I've previously written stuff where operation was entirely >> dependant on command-line options, but haven't tried making the decision >> completely automatically. > > In case it helps anybody avoid wasted time: looking carefully at what > I've been doing, it turns out that it's not possible to make an > LCL-based program running on unix (i.e. with X11 etc.) to fall back > cleanly to text mode, such that it could be run on e.g. a serial > terminal, by manipulating the main program unit (.lpr or whatever). The simple solution is to write 2 binaries. A text-only one, and a GUI one. The text-only one starts the GUI one if it detects a GUI (or if a command-line element is present). I see no added value in having everything in 1 binary. Michael. From mailinglists at geldenhuys.co.uk Thu May 4 13:31:05 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 4 May 2017 12:31:05 +0100 Subject: [Lazarus] Startup environment: to Gui, or not to GUI? In-Reply-To: References: Message-ID: <81aaa728-7d14-f8af-78d8-eea3a1a77264@geldenhuys.co.uk> On 2017-05-04 11:18, Mark Morgan Lloyd via Lazarus wrote: > In case it helps anybody avoid wasted time: looking carefully at what > I've been doing, it turns out that it's not possible to make an > LCL-based program running on unix (i.e. with X11 etc.) And it wouldn’t be right if I didn’t offer up an alternative. fpGUI based applications can indeed do what you want. I do this all the time for command line handling. If a GUI program is run from a terminal (no X11 server), it will still output to the console telling the user what program it is, version info, command line parameters and importantly, that it requires a GUI to function. In a GUI environment (eg: MS Windows) it will display a dialog with all the same information, if the -h command line parameter was passed in. Here is such output of one of my programs (run from the login terminal - no X11): ======================================= $ ./osmail -h Opensoft Mail & News v1.00 (build 18) Compiled on 2017/05/01 11:09:41 The following parameters are available: h, help Shows this help lc Logs debug information to the console lv Logs debug information to a visual screen ls Logs debug information to debug server l Logs debug information to a file style Applies a custom style to the application. Available options are: "auto", "Win2000", "Motif", "Carbon", "Plastic Dark", "Plastic Dark Gray", "Plastic Medium Gray", "Plastic Light Gray" NOTE: This program requires a graphical windowing environment to function. $ ======================================= So as you can see, what you want to do is possible. Maybe LCL just needs more work around its initialization code - being less eager to initialize its GUI. ;-) Michael's suggestion of two binaries is also a good idea. 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 Thu May 4 13:47:56 2017 From: wkitty42 at windstream.net (wkitty42 at windstream.net) Date: Thu, 4 May 2017 07:47:56 -0400 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> Message-ID: <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> On 05/03/2017 05:21 AM, Juha Manninen via Lazarus wrote: > Encoding does not matter any more, as long as it is Unicode. reminds me of a saying that is attributed to Henry Ford... Any customer can have a car painted any color that he wants so long as it is black. :) -- 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 markMLl.lazarus at telemetry.co.uk Thu May 4 15:30:20 2017 From: markMLl.lazarus at telemetry.co.uk (Mark Morgan Lloyd) Date: Thu, 4 May 2017 13:30:20 +0000 Subject: [Lazarus] Startup environment: to Gui, or not to GUI? In-Reply-To: <81aaa728-7d14-f8af-78d8-eea3a1a77264@geldenhuys.co.uk> References: <81aaa728-7d14-f8af-78d8-eea3a1a77264@geldenhuys.co.uk> Message-ID: On 04/05/17 12:00, Graeme Geldenhuys via Lazarus wrote: > On 2017-05-04 11:18, Mark Morgan Lloyd via Lazarus wrote:> In case it helps anybody avoid wasted time: looking carefully at what > I've been doing, it turns out that it's not possible to make an > LCL-based program running on unix (i.e. with X11 etc.) > And it wouldn’t be right if I didn’t offer up an alternative. fpGUIbased applications can indeed do what you want. I do this all the timefor command line handling. If a GUI program is run from a terminal (noX11 server), it will still output to the console telling the user whatprogram it is, version info, command line parameters and importantly,that it requires a GUI to function. In a GUI environment (eg: MSWindows) it will display a dialog with all the same information, if the-h command line parameter was passed in. > Here is such output of one of my programs (run from the login terminal -no X11): Agreed, such as --help or --version output. However it looks as though it's important to check anything that attempts this on e.g. the system text-mode console or over something really crude like telnet... and I hope you're doing that for fpGUI since you keep telling us how good it is :-) > So as you can see, what you want to do is possible. Maybe LCL just needsmore work around its initialization code - being less eager toinitialize its GUI. ;-) I think it could probably be done by slipping a unit in just before cthreads, provided that this terminated aggressively. That's actually less intrusive that the editing I've been doing in the .lpr initialisation block, but it would mean splitting out e.g. text-mode --help and graphics-mode --about into separate places. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] From juha.manninen62 at gmail.com Thu May 4 16:56:00 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Thu, 4 May 2017 17:56:00 +0300 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> Message-ID: On Thu, May 4, 2017 at 2:47 PM, wkitty42--- via Lazarus wrote: > On 05/03/2017 05:21 AM, Juha Manninen via Lazarus wrote: >> Encoding does not matter any more, as long as it is Unicode. > > reminds me of a saying that is attributed to Henry Ford... > Any customer can have a car painted any color that he wants so long as it is > black. Ok, maybe my wording was not good. I believe everybody is happy to get rid of the horrendous Windows system codepages and the question marks in text. Unicode is a good thing! The LazUnicode unit provides a solution for encoding agnostic code. Yes. It is no joke. There has been many wars about UTF-8 <> UTF-16 encoding supremacy. They look ridiculous for anybody who knows the complexity of Unicode. The complexity is not related to encodings, it is at the abstract Unicode level where encodings have no effect. Currently Delphi and Lazarus use a different encoding. Some people see it as a problem. LazUnicode proves it is not a problem. You can write code that works with both. Codepoints in both encodings have variable width, thus they must use the same fundamental concepts. It was easy to write functions to support them both. However LazUnicode does not solve the problems at abstract Unicode level and nobody claims so. Another fact is that lots of UTF-16 code out there is broken because people treat UTF-16 as fixed width encoding for some reason. Using LazUnicode unit improves the situation. The code will inevitably work right with both encodings. I have seen comments saying that treating UTF-16 as fixed width encoding is OK because the characters outside BMP are so rare. It is like saying that a buggy spreadsheet app is OK because it calculates the sums wrong only sometimes. IMO such people should not do programming. I have not seen any feedback or comments about LazUnicode so far. I guess it means that nobody uses it. :( Juha From wkitty42 at windstream.net Thu May 4 17:32:50 2017 From: wkitty42 at windstream.net (wkitty42 at windstream.net) Date: Thu, 4 May 2017 11:32:50 -0400 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> Message-ID: <6679418a-b71e-865a-7ee6-6df4a888b4c3@windstream.net> On 05/04/2017 10:56 AM, Juha Manninen via Lazarus wrote: > On Thu, May 4, 2017 at 2:47 PM, wkitty42--- via Lazarus > wrote: >> On 05/03/2017 05:21 AM, Juha Manninen via Lazarus wrote: >>> Encoding does not matter any more, as long as it is Unicode. >> >> reminds me of a saying that is attributed to Henry Ford... >> Any customer can have a car painted any color that he wants so long as it is >> black. > > Ok, maybe my wording was not good. i was making a joke... my apologies if it didn't make the great divide... you're good! :) :) :) -- 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 mailinglists at geldenhuys.co.uk Thu May 4 19:53:40 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 4 May 2017 18:53:40 +0100 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> Message-ID: <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> On 2017-05-04 15:56, Juha Manninen via Lazarus wrote: > I have seen comments saying that treating UTF-16 as fixed width > encoding is OK because the characters outside BMP are so rare. It is > like saying that a buggy spreadsheet app is OK because it calculates > the sums wrong only sometimes. IMO such people should not do > programming. +1 I purchased a commercial text editor renowned for having excellent Unicode support - at least that is what ALL the reviews said. Umm yeah, to my disappointment it internally uses UTF-16 (because it is written in Delphi), and treats UTF-16 as 2-byte fixed width! WTF! > I have not seen any feedback or comments about LazUnicode so far. I > guess it means that nobody uses it. :( You made me curious, so I want to take a look. Hopefully it doesn’t depend too heavily on the rest of LCL, so I’ll be able to use it in other projects of mine. Regards, Graeme From juha.manninen62 at gmail.com Thu May 4 22:53:39 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Thu, 4 May 2017 23:53:39 +0300 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> Message-ID: On Thu, May 4, 2017 at 8:53 PM, Graeme Geldenhuys via Lazarus wrote: > You made me curious, so I want to take a look. Hopefully it doesn’t > depend too heavily on the rest of LCL, so I’ll be able to use it in > other projects of mine. It has no dependency for LCL, it is part of LazUtils package just like the other Unicode stuff. It can be used also with Delphi by copying 2 unit files. It is briefly explained here: http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus#CodePoint_functions_for_encoding_agnostic_code Juha From mailinglists at geldenhuys.co.uk Fri May 5 00:20:33 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 4 May 2017 23:20:33 +0100 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> Message-ID: <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> On 2017-05-04 21:53, Juha Manninen via Lazarus wrote: > It is briefly explained here: I haven't been following FPC 3.x development much because I think the Unicode changes are terribly confusing. A case in point. Looking at the Wiki page you listed, I read the following: " Since FPC 3.0 you must add the flag -FcUTF8 or add {$codepage UTF8} at the beginning of the unit. * Note: This changes all string literals to UTF-16, increasing the size of the binary and slowing it down. That's why Lazarus does not add it by default. " That makes NO sense to me. My units are always saved as UTF-8 encoded text. By helping the compiler out by explicitly telling it my files are UTF-8 encoded using -FcUTF8 or adding {$codepage UTF8} or saving the unit with a BOM marker breaks writeln() output under Linux/FreeBSD. Who knows what else it breaks. Apparently the breakage is because of the "NOTE" quoted above. Why the hell does FPC consider string literals UTF-16 when I explicitly told it the whole unit is UTF-8 encoded? FPC is doing the opposite of what I told it! I simply can't see myself moving past FPC 2.6.4 at this point. FPC 3.x just doesn't make any sense. Regards, Graeme From nc-gaertnma at netcologne.de Fri May 5 01:15:47 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Fri, 5 May 2017 01:15:47 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> Message-ID: <20170505011547.0ff3f5bb@limapholos.matflo.wg> On Thu, 4 May 2017 23:20:33 +0100 Graeme Geldenhuys via Lazarus wrote: >[...] > Since FPC 3.0 you must add the flag -FcUTF8 or add {$codepage UTF8} at the beginning of the unit. > > * Note: This changes all string literals to UTF-16, increasing the size of the binary and slowing it down. That's why Lazarus does not add it by default. > " > > That makes NO sense to me. My units are always saved as UTF-8 encoded text. By helping the compiler out by explicitly telling it my files are UTF-8 encoded using -FcUTF8 or adding {$codepage UTF8} or saving the unit with a BOM marker breaks writeln() output under Linux/FreeBSD. Who knows what else it breaks. Apparently the breakage is because of the "NOTE" quoted above. Why the hell does FPC consider string literals UTF-16 when I explicitly told it the whole unit is UTF-8 encoded? FPC is doing the opposite of what I told it! I added a FAQ: http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus#What_happens_when_I_use_.24codepage_utf8.3F > I simply can't see myself moving past FPC 2.6.4 at this point. FPC 3.x just doesn't make any sense. AFAIK you are using UTF-8 in AnsiString in FPC 2.6.4. That works in many cases, because of double fooling the compiler. This trick does not work on Windows with RTL file functions though. The good news is that the same trick works in FPC 3.0. And with some new tricks it is now possible to make the RTL file functions support UTF-8. Of course it would be nicer, if we don't need tricks to get Unicode. Mattias From michael at freepascal.org Fri May 5 08:43:00 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Fri, 5 May 2017 08:43:00 +0200 (CEST) Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <20170505011547.0ff3f5bb@limapholos.matflo.wg> References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> Message-ID: On Fri, 5 May 2017, Mattias Gaertner via Lazarus wrote: >> I simply can't see myself moving past FPC 2.6.4 at this point. FPC 3.x just doesn't make any sense. > > AFAIK you are using UTF-8 in AnsiString in FPC 2.6.4. That works in > many cases, because of double fooling the compiler. This trick does not > work on Windows with RTL file functions though. > The good news is that the same trick works in FPC 3.0. And with some new > tricks it is now possible to make the RTL file functions support UTF-8. > Of course it would be nicer, if we don't need tricks to get Unicode. What tricks do you still need in 3.0.x ? As far as I know, you don't need any tricks to work with unicode filenames or output in 3.0.2. Maybe with exception of TStrings and TFileStream. Michael. From michael at freepascal.org Fri May 5 08:43:00 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Fri, 5 May 2017 08:43:00 +0200 (CEST) Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <20170505011547.0ff3f5bb@limapholos.matflo.wg> References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> Message-ID: On Fri, 5 May 2017, Mattias Gaertner via Lazarus wrote: >> I simply can't see myself moving past FPC 2.6.4 at this point. FPC 3.x just doesn't make any sense. > > AFAIK you are using UTF-8 in AnsiString in FPC 2.6.4. That works in > many cases, because of double fooling the compiler. This trick does not > work on Windows with RTL file functions though. > The good news is that the same trick works in FPC 3.0. And with some new > tricks it is now possible to make the RTL file functions support UTF-8. > Of course it would be nicer, if we don't need tricks to get Unicode. What tricks do you still need in 3.0.x ? As far as I know, you don't need any tricks to work with unicode filenames or output in 3.0.2. Maybe with exception of TStrings and TFileStream. Michael. From badsectoracula at gmail.com Fri May 5 10:31:00 2017 From: badsectoracula at gmail.com (Kostas Michalopoulos) Date: Fri, 5 May 2017 11:31:00 +0300 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> Message-ID: On Thu, May 4, 2017 at 8:53 PM, Graeme Geldenhuys via Lazarus < lazarus at lists.lazarus-ide.org> wrote: > On 2017-05-04 15:56, Juha Manninen via Lazarus wrote: > > I have seen comments saying that treating UTF-16 as fixed width > > encoding is OK because the characters outside BMP are so rare. It is > > like saying that a buggy spreadsheet app is OK because it calculates > > the sums wrong only sometimes. IMO such people should not do > > programming. > > +1 > I purchased a commercial text editor renowned for having excellent > Unicode support - at least that is what ALL the reviews said. Umm > yeah, to my disappointment it internally uses UTF-16 (because it is > written in Delphi), and treats UTF-16 as 2-byte fixed width! WTF! > To play the devil's advocate, the fact that ALL reviews said that it has excellent support for Unicode means that characters outside the BMP *are* rare. After all, BMP does include practically all languages used today. I mean, it isn't technically correct, it is just that in practice it is good enough for a very large number of tasks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nc-gaertnma at netcologne.de Fri May 5 10:43:06 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Fri, 5 May 2017 10:43:06 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> Message-ID: <20170505104306.7203f0c1@limapholos.matflo.wg> On Fri, 5 May 2017 11:31:00 +0300 Kostas Michalopoulos via Lazarus wrote: >[...] > To play the devil's advocate, the fact that ALL reviews said that it has > excellent support for Unicode means that characters outside the BMP *are* > rare. After all, BMP does include practically all languages used today. > > I mean, it isn't technically correct, it is just that in practice it is > good enough for a very large number of tasks. Devil's advocate: The new emojis are outside BMP. Mattias From mschnell at lumino.de Fri May 5 10:59:56 2017 From: mschnell at lumino.de (Michael Schnell) Date: Fri, 5 May 2017 10:59:56 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> Message-ID: <397cf8bf-70a1-2dfd-f7cd-9d66de60a641@lumino.de> On 04.05.2017 16:56, Juha Manninen via Lazarus wrote: > I believe everybody is happy to get rid of the horrendous Windows If if this is true, there is a decent need for backwards compatibility. That is why, theoretically, code aware strings is a good idea. Unfortunately the implementation of those, IMHO, is abysmal, as well in Delphi, as in fpc. (Most obvious drawback: not flexibly typed TStrings.) -Michael From mailinglists at geldenhuys.co.uk Fri May 5 11:01:24 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 5 May 2017 10:01:24 +0100 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <20170505011547.0ff3f5bb@limapholos.matflo.wg> References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> Message-ID: On 2017-05-05 00:15, Mattias Gaertner via Lazarus wrote: > I added a FAQ: > http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus#What_happens_when_I_use_.24codepage_utf8.3F Ah, thanks for that explanation. > AFAIK you are using UTF-8 in AnsiString in FPC 2.6.4. That works in > many cases, because of double fooling the compiler. This trick does not > work on Windows with RTL file functions though. Yes and true, but fpGUI supplies its own "wrapper" RTL file functions, thus it works 100% on all platforms for years. I believe LCL used to do the same. RawByteString type (yet another string type in FPC & Delphi's arsenal) did not exist at the time, otherwise I would probably have defined... TfpgString = RawByteString; and used that everywhere. > Of course it would be nicer, if we don't need tricks to get Unicode. Indeed, and that is why I love solutions implemented by Java and Qt Framework. They are simple, it works and not confusing. Even Embarcadero is doing some string type clean-up. Their new Linux compiler completely removed AnsiString support. After all, why do you need any other string types when you support the Unicode standard. 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 May 5 11:06:53 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 5 May 2017 10:06:53 +0100 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> Message-ID: <500ffa2a-7aef-3c21-5b84-dcb4931e6921@geldenhuys.co.uk> On 2017-05-05 07:43, Michael Van Canneyt via Lazarus wrote: > As far as I know, you don't need any tricks to work with unicode > filenames or output in 3.0.2. Maybe with exception of TStrings and > TFileStream. Again, I didn't have time to follow FPC 3.x development much, and I was too confused with all the Unicode changes. With FPC 3.0.x, can you now load text files from disk using TStringList and specify the encoding of the file at load time? Something like: sl.LoadFromFile('some_utf8_file.txt', CP_UTF8); sl.LoadFromFile('some_utf16_file.txt', CP_UTF16); sl.LoadFromFile('some_latin1_file.txt', CP_Latin1); etc 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 May 5 11:13:26 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 5 May 2017 10:13:26 +0100 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> Message-ID: <0de83629-4327-287d-1e8e-2d9e551bbf7a@geldenhuys.co.uk> On 2017-05-05 09:31, Kostas Michalopoulos via Lazarus wrote: > After all, BMP does include practically all languages used today. The bottom line: Unicode Standard <> BMP only! If you think that, then rather promote your application as a UCS-2 compliant application, not a Unicode compliant application. I can't remember my exact use case at the time, but the code-points I needed to work with (using a data dump text file) were outside the BMP range. I had to use a Java based text editor to correctly edit the files. Also, as Mattias said, the Emoji's, Musical notes, Scientific symbols, Map symbols etc all fall outside the BMP. 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 Fri May 5 11:17:28 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Fri, 5 May 2017 11:17:28 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <500ffa2a-7aef-3c21-5b84-dcb4931e6921@geldenhuys.co.uk> References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <500ffa2a-7aef-3c21-5b84-dcb4931e6921@geldenhuys.co.uk> Message-ID: On 05.05.2017 11:06, Graeme Geldenhuys via Lazarus wrote: > On 2017-05-05 07:43, Michael Van Canneyt via Lazarus wrote: >> As far as I know, you don't need any tricks to work with unicode >> filenames or output in 3.0.2. Maybe with exception of TStrings and >> TFileStream. > Again, I didn't have time to follow FPC 3.x development much, and I was too > confused with all the Unicode changes. > > With FPC 3.0.x, can you now load text files from disk using TStringList and > specify the encoding of the file at load time? > > Something like: > > sl.LoadFromFile('some_utf8_file.txt', CP_UTF8); > sl.LoadFromFile('some_utf16_file.txt', CP_UTF16); > sl.LoadFromFile('some_latin1_file.txt', CP_Latin1); I don't know about 3.0.x but you can do it in trunk 3.1.1. I posted a patch for it (r34475). I also extended TEncoding to support AnsiString, which was the requirement for TStrings encoding support. Ondrej From michael at freepascal.org Fri May 5 11:17:54 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Fri, 5 May 2017 11:17:54 +0200 (CEST) Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <500ffa2a-7aef-3c21-5b84-dcb4931e6921@geldenhuys.co.uk> References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <500ffa2a-7aef-3c21-5b84-dcb4931e6921@geldenhuys.co.uk> Message-ID: On Fri, 5 May 2017, Graeme Geldenhuys via Lazarus wrote: > On 2017-05-05 07:43, Michael Van Canneyt via Lazarus wrote: >> As far as I know, you don't need any tricks to work with unicode >> filenames or output in 3.0.2. Maybe with exception of TStrings and >> TFileStream. > > Again, I didn't have time to follow FPC 3.x development much, and I was too > confused with all the Unicode changes. > > With FPC 3.0.x, can you now load text files from disk using TStringList and > specify the encoding of the file at load time? > > Something like: > > sl.LoadFromFile('some_utf8_file.txt', CP_UTF8); > sl.LoadFromFile('some_utf16_file.txt', CP_UTF16); > sl.LoadFromFile('some_latin1_file.txt', CP_Latin1); Not yet. These are the exceptions I was talking about. But the FileOpen, Assign,Reset, Write of plain pascal do work with both Unicode and plain strings. To fix the classes issues properly, we need a unicode RTL and a ANSI RTL if we wish to remain backwards compatible: The Strings[] property can have only 1 type. Michael. From mailinglists at geldenhuys.co.uk Fri May 5 11:18:22 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 5 May 2017 10:18:22 +0100 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <397cf8bf-70a1-2dfd-f7cd-9d66de60a641@lumino.de> References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <397cf8bf-70a1-2dfd-f7cd-9d66de60a641@lumino.de> Message-ID: On 2017-05-05 09:59, Michael Schnell via Lazarus wrote: > (Most obvious drawback: not flexibly typed TStrings.) I know not everybody likes Generics, but that is where I see Generics could come in very handy. A single TStrings implementation that supports multiple string types. Or just implement a UTF-8 version. ;-) On a side note: I have implemented a UTF-8 version of TStrings & TStringList somewhere on my hard drive. 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 Fri May 5 11:23:55 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Fri, 5 May 2017 11:23:55 +0200 (CEST) Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <500ffa2a-7aef-3c21-5b84-dcb4931e6921@geldenhuys.co.uk> Message-ID: On Fri, 5 May 2017, Ondrej Pokorny via Lazarus wrote: > On 05.05.2017 11:06, Graeme Geldenhuys via Lazarus wrote: >> On 2017-05-05 07:43, Michael Van Canneyt via Lazarus wrote: >>> As far as I know, you don't need any tricks to work with unicode >>> filenames or output in 3.0.2. Maybe with exception of TStrings and >>> TFileStream. >> Again, I didn't have time to follow FPC 3.x development much, and I was too >> confused with all the Unicode changes. >> >> With FPC 3.0.x, can you now load text files from disk using TStringList and >> specify the encoding of the file at load time? >> >> Something like: >> >> sl.LoadFromFile('some_utf8_file.txt', CP_UTF8); >> sl.LoadFromFile('some_utf16_file.txt', CP_UTF16); >> sl.LoadFromFile('some_latin1_file.txt', CP_Latin1); > > I don't know about 3.0.x but you can do it in trunk 3.1.1. I posted a > patch for it (r34475). I also extended TEncoding to support AnsiString, > which was the requirement for TStrings encoding support. Yes, this somewhat alleviates the problem; but this still is a single-byte TStrings, as opposed to the WideString TStrings of Delphi. It's also still a single-byte filename argument. Michael. From mailinglists at geldenhuys.co.uk Fri May 5 11:24:30 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 5 May 2017 10:24:30 +0100 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <500ffa2a-7aef-3c21-5b84-dcb4931e6921@geldenhuys.co.uk> Message-ID: <49182def-2afe-7cab-7658-28fff4552901@geldenhuys.co.uk> On 2017-05-05 10:17, Michael Van Canneyt via Lazarus wrote: >> Something like: >> >> sl.LoadFromFile('some_utf8_file.txt', CP_UTF8); >> sl.LoadFromFile('some_utf16_file.txt', CP_UTF16); >> sl.LoadFromFile('some_latin1_file.txt', CP_Latin1); > > Not yet. These are the exceptions I was talking about. That also means FPC 3.0.x is then seriously flawed. It supports Unicode, but it also doesn't support Unicode. So what is the suggested work-around for FPC 3.0.2 to load various text encoding files into a TStringList? Hopefully the answer is not: "there is none" :-/ Because that will seriously impair/break INI usage too. The first example off the top of my head. XML and JSON probably 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 Fri May 5 11:24:31 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Fri, 5 May 2017 11:24:31 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <500ffa2a-7aef-3c21-5b84-dcb4931e6921@geldenhuys.co.uk> Message-ID: <51d09177-aca3-6576-75aa-05f95657db2c@kluug.net> On 05.05.2017 11:17, Michael Van Canneyt via Lazarus wrote: > On Fri, 5 May 2017, Graeme Geldenhuys via Lazarus wrote: > >> On 2017-05-05 07:43, Michael Van Canneyt via Lazarus wrote: >>> As far as I know, you don't need any tricks to work with unicode >>> filenames or output in 3.0.2. Maybe with exception of TStrings and >>> TFileStream. >> >> Again, I didn't have time to follow FPC 3.x development much, and I >> was too >> confused with all the Unicode changes. >> >> With FPC 3.0.x, can you now load text files from disk using >> TStringList and >> specify the encoding of the file at load time? >> >> Something like: >> sl.LoadFromFile('some_utf8_file.txt', CP_UTF8); >> sl.LoadFromFile('some_utf16_file.txt', CP_UTF16); >> sl.LoadFromFile('some_latin1_file.txt', CP_Latin1); > > Not yet. These are the exceptions I was talking about. Current trunk 3.1.1 can do that since r34475 - you applied it :) I don't know if you ported it back to 3.0.x, though. TFileStream can also open files with unicode names - at least on Windows (since 3.0.0 if I am not mistaken). See Function FileCreate (Const FileName : UnicodeString; ShareMode : Integer; Rights : Integer) : THandle; in rtl/win/sysutils.pas -->> There are absolutely no limitations whatsover, AFAIK. At least I don't know any and I don't experience any. Ondrej From mailinglists at geldenhuys.co.uk Fri May 5 11:26:17 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 5 May 2017 10:26:17 +0100 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <500ffa2a-7aef-3c21-5b84-dcb4931e6921@geldenhuys.co.uk> Message-ID: On 2017-05-05 10:17, Ondrej Pokorny via Lazarus wrote: > I don't know about 3.0.x but you can do it in trunk 3.1.1. I posted a > patch for it (r34475). Fantastic! Glad to see somebody was thinking in the same train of thought as I did. :) Is that scheduled to be back-ported to FPC 3.0.x? Regards, Graeme From michael at freepascal.org Fri May 5 11:27:29 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Fri, 5 May 2017 11:27:29 +0200 (CEST) Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <49182def-2afe-7cab-7658-28fff4552901@geldenhuys.co.uk> References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <500ffa2a-7aef-3c21-5b84-dcb4931e6921@geldenhuys.co.uk> <49182def-2afe-7cab-7658-28fff4552901@geldenhuys.co.uk> Message-ID: On Fri, 5 May 2017, Graeme Geldenhuys via Lazarus wrote: > On 2017-05-05 10:17, Michael Van Canneyt via Lazarus wrote: >>> Something like: >>> >>> sl.LoadFromFile('some_utf8_file.txt', CP_UTF8); >>> sl.LoadFromFile('some_utf16_file.txt', CP_UTF16); >>> sl.LoadFromFile('some_latin1_file.txt', CP_Latin1); >> >> Not yet. These are the exceptions I was talking about. > > > That also means FPC 3.0.x is then seriously flawed. It > supports Unicode, but it also doesn't support Unicode. > > So what is the suggested work-around for FPC 3.0.2 to load > various text encoding files into a TStringList? Hopefully > the answer is not: "there is none" :-/ Use the plain pascal routines to read lines from a file, fill stringlist. You can write a class helper for it. > Because that will seriously impair/break INI usage too. The > first example off the top of my head. XML and JSON probably > too. No. Those have been using widestring/UTF8string since day 1. The main problem to switch the classes unit is backwards compatibility. Michael. From michael at freepascal.org Fri May 5 11:29:32 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Fri, 5 May 2017 11:29:32 +0200 (CEST) Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <51d09177-aca3-6576-75aa-05f95657db2c@kluug.net> References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <500ffa2a-7aef-3c21-5b84-dcb4931e6921@geldenhuys.co.uk> <51d09177-aca3-6576-75aa-05f95657db2c@kluug.net> Message-ID: On Fri, 5 May 2017, Ondrej Pokorny via Lazarus wrote: > On 05.05.2017 11:17, Michael Van Canneyt via Lazarus wrote: >> On Fri, 5 May 2017, Graeme Geldenhuys via Lazarus wrote: >> >>> On 2017-05-05 07:43, Michael Van Canneyt via Lazarus wrote: >>>> As far as I know, you don't need any tricks to work with unicode >>>> filenames or output in 3.0.2. Maybe with exception of TStrings and >>>> TFileStream. >>> >>> Again, I didn't have time to follow FPC 3.x development much, and I >>> was too >>> confused with all the Unicode changes. >>> >>> With FPC 3.0.x, can you now load text files from disk using >>> TStringList and >>> specify the encoding of the file at load time? >>> >>> Something like: >>> sl.LoadFromFile('some_utf8_file.txt', CP_UTF8); >>> sl.LoadFromFile('some_utf16_file.txt', CP_UTF16); >>> sl.LoadFromFile('some_latin1_file.txt', CP_Latin1); >> >> Not yet. These are the exceptions I was talking about. > > Current trunk 3.1.1 can do that since r34475 - you applied it :) I don't > know if you ported it back to 3.0.x, though. As far as I know, it is not backported, but Marco would need to confirm it. Michael. From lazarus at kluug.net Fri May 5 11:31:24 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Fri, 5 May 2017 11:31:24 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <49182def-2afe-7cab-7658-28fff4552901@geldenhuys.co.uk> References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <500ffa2a-7aef-3c21-5b84-dcb4931e6921@geldenhuys.co.uk> <49182def-2afe-7cab-7658-28fff4552901@geldenhuys.co.uk> Message-ID: <1c325ca0-6b4b-6084-9f92-0690ee64fcfc@kluug.net> On 05.05.2017 11:24, Graeme Geldenhuys via Lazarus wrote: > On 2017-05-05 10:17, Michael Van Canneyt via Lazarus wrote: >>> Something like: >>> >>> sl.LoadFromFile('some_utf8_file.txt', CP_UTF8); >>> sl.LoadFromFile('some_utf16_file.txt', CP_UTF16); >>> sl.LoadFromFile('some_latin1_file.txt', CP_Latin1); >> Not yet. These are the exceptions I was talking about. > > That also means FPC 3.0.x is then seriously flawed. It > supports Unicode, but it also doesn't support Unicode. > > So what is the suggested work-around for FPC 3.0.2 to load > various text encoding files into a TStringList? Hopefully > the answer is not: "there is none" :-/ Use "DefaultSystemCodePage := CP_UTF8" and you can load any text in any encoding into TStrings without character loss - the file will be converted to UTF-8 in LoadFrom* and converted back in SaveTo*. So your code can handle all encodings equally. There are no limitations and no problems whatsoever. Yes, FPC is fully unicode-ready - in case you are fine with using UTF-8 internally! Ondrej From lazarus at kluug.net Fri May 5 11:41:21 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Fri, 5 May 2017 11:41:21 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <500ffa2a-7aef-3c21-5b84-dcb4931e6921@geldenhuys.co.uk> Message-ID: On 05.05.2017 11:23, Michael Van Canneyt via Lazarus wrote: > Yes, this somewhat alleviates the problem; but this still is a > single-byte TStrings, as opposed to the WideString > TStrings of Delphi. It's also still a single-byte filename argument. Yes but you forget that unicode is also single-byte UTF-8. And the greatest thing about FPC: it fully supports "DefaultSystemCodePage := CP_UTF8". Therefore you don't need WideString/UnicodeString file arguments and UnicodeString-TStrings to have full unicode support in current FPC. Just use "DefaultSystemCodePage := CP_UTF8" and every single-byte string is unicode enabled. Believe me, I use it in production without any problems: I have unicode-aware TStrings, I can read files with unicode names, I can do everything with plain FPC trunk. I don't need a 100% UTF-16 Delphi-Compatible RTL for that at all. I can do that with current UTF-8 FPC RTL as well. (Honestly I think it's better for FPC to stick with UTF-8 and don't overcomplicate the RTL with UTF-16 support.) Ondrej From nc-gaertnma at netcologne.de Fri May 5 11:41:48 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Fri, 5 May 2017 11:41:48 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> Message-ID: <20170505114148.765f720b@limapholos.matflo.wg> On Fri, 5 May 2017 10:01:24 +0100 Graeme Geldenhuys via Lazarus wrote: >[...] > > AFAIK you are using UTF-8 in AnsiString in FPC 2.6.4. That works in > > many cases, because of double fooling the compiler. This trick does not > > work on Windows with RTL file functions though. > > Yes and true, but fpGUI supplies its own "wrapper" RTL file functions, thus > it works 100% on all platforms for years. I believe LCL used to do the same. Yes, and with FPC 3.0 many of them are no longer needed. > RawByteString type (yet another string type in FPC & Delphi's arsenal) did > not exist at the time, otherwise I would probably have defined... > > TfpgString = RawByteString; > > and used that everywhere. How would that help? > > Of course it would be nicer, if we don't need tricks to get Unicode. > > Indeed, and that is why I love solutions implemented by Java and Qt > Framework. They are simple, it works and not confusing. IMO you are comparing apples and oranges. The FP compiler provides a very easy Unicode solution - or even two (UTF-8 and UTF-16). The problem are the old RTL and libs, which are written for system encoding, not for Unicode. You can design in FPC an Unicode RTL just like Java and QT. fpgui and LazUtils are kind of a start of that. Or you can help FPC finishing the Unicode RTL. So stop complaining and help them. > Even Embarcadero > is doing some string type clean-up. Their new Linux compiler completely > removed AnsiString support. After all, why do you need any other > string types when you support the Unicode standard. That's true for most cases. I wonder what they do when you need to access the raw 8-bit file names, or work with large amount of 8-bit strings. Mattias From mailinglists at geldenhuys.co.uk Fri May 5 11:56:41 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 5 May 2017 10:56:41 +0100 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <20170505114148.765f720b@limapholos.matflo.wg> References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <20170505114148.765f720b@limapholos.matflo.wg> Message-ID: <86ae8e8b-21d1-41a5-bd48-c27fddd98359@geldenhuys.co.uk> On 2017-05-05 10:41, Mattias Gaertner via Lazarus wrote: > I wonder what they do when you need to access the raw 8-bit file names, OSX, iOS, Android and Linux all use UTF-8 as standard, so filename access is not going to be any problem. Windows is moving more and more towards UTF-16 everywhere, so that shouldn't be a problem either. > or work with large amount of 8-bit strings. Why would you want to? Unicode supports all languages, there simply is no need for other non-Unicode encodings any more. If it is memory usage you are worried about, convert your 8-bit strings as UTF-8 encoded text (most Western countries text will all use low memory then - compared to UTF-16 as an alternative). Java has only supported Unicode since its inception in 1995, and Java runs everywhere. It's never had a problem running on non-Unicode enabled platforms. 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 Fri May 5 12:01:47 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Fri, 5 May 2017 12:01:47 +0200 (CEST) Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <500ffa2a-7aef-3c21-5b84-dcb4931e6921@geldenhuys.co.uk> Message-ID: On Fri, 5 May 2017, Ondrej Pokorny via Lazarus wrote: > On 05.05.2017 11:23, Michael Van Canneyt via Lazarus wrote: >> Yes, this somewhat alleviates the problem; but this still is a >> single-byte TStrings, as opposed to the WideString >> TStrings of Delphi. It's also still a single-byte filename argument. > > Yes but you forget that unicode is also single-byte UTF-8. And the > greatest thing about FPC: it fully supports "DefaultSystemCodePage := > CP_UTF8". > > Therefore you don't need WideString/UnicodeString file arguments and > UnicodeString-TStrings to have full unicode support in current FPC. > > Just use "DefaultSystemCodePage := CP_UTF8" and every single-byte string > is unicode enabled. > > Believe me, I use it in production without any problems: I have > unicode-aware TStrings, I can read files with unicode names, I can do > everything with plain FPC trunk. I am aware of this, I do it myself. But I work on Linux, where UTF8 is the norm. So I cannot vouch for other platforms... > > I don't need a 100% UTF-16 Delphi-Compatible RTL for that at all. This is the crux of the problem. Is this wanted/needed or do we stick to UTF8 ? We claim Delphi compatibility. So IMHO we must provide a UTF-16 Delphi compatible RTL. Michael. From nc-gaertnma at netcologne.de Fri May 5 12:08:19 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Fri, 5 May 2017 12:08:19 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <86ae8e8b-21d1-41a5-bd48-c27fddd98359@geldenhuys.co.uk> References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <20170505114148.765f720b@limapholos.matflo.wg> <86ae8e8b-21d1-41a5-bd48-c27fddd98359@geldenhuys.co.uk> Message-ID: <20170505120819.17aaedee@limapholos.matflo.wg> On Fri, 5 May 2017 10:56:41 +0100 Graeme Geldenhuys via Lazarus wrote: >[...] > > or work with large amount of 8-bit strings. > > Why would you want to? Unicode supports all languages, Maybe there is a misunderstanding. Let me rephrase my question: What string do you use in Linux Delphi when working with UTF-8 strings? Mattias From mailinglists at geldenhuys.co.uk Fri May 5 12:16:14 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 5 May 2017 11:16:14 +0100 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <500ffa2a-7aef-3c21-5b84-dcb4931e6921@geldenhuys.co.uk> Message-ID: <2639f07e-2a3d-6591-a3be-8643b3386ccf@geldenhuys.co.uk> On 2017-05-05 11:01, Michael Van Canneyt via Lazarus wrote: > We claim Delphi compatibility. > So IMHO we must provide a UTF-16 Delphi compatible RTL. In the end it’s about supporting Unicode. Does it really matter what internal encoding it is to achieve the “Unicode support” goal? Regards, Graeme From lazarus at kluug.net Fri May 5 12:17:22 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Fri, 5 May 2017 12:17:22 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <20170505120819.17aaedee@limapholos.matflo.wg> References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <20170505114148.765f720b@limapholos.matflo.wg> <86ae8e8b-21d1-41a5-bd48-c27fddd98359@geldenhuys.co.uk> <20170505120819.17aaedee@limapholos.matflo.wg> Message-ID: <7aca3d3e-8705-88db-9925-88614393c190@kluug.net> On 05.05.2017 12:08, Mattias Gaertner via Lazarus wrote: > On Fri, 5 May 2017 10:56:41 +0100 > Graeme Geldenhuys via Lazarus wrote: > >> [...] >>> or work with large amount of 8-bit strings. >> Why would you want to? Unicode supports all languages, > Maybe there is a misunderstanding. Let me rephrase my question: > What string do you use in Linux Delphi when working with UTF-8 strings? Embarcadero realized they made a mistake when they disabled (yes, only disabled not removed) 8-byte strings from NEXTGEN compilers. UTF8String and RawByteString are back for all NEXTGEN compilers since 10.1. You can use them in Linux Delphi as well. http://andy.jgknet.de/blog/2016/05/system-bytestrings-for-10-1-berlin/ Ondrej From nc-gaertnma at netcologne.de Fri May 5 12:23:06 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Fri, 5 May 2017 12:23:06 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <500ffa2a-7aef-3c21-5b84-dcb4931e6921@geldenhuys.co.uk> Message-ID: <20170505122306.1c2630a4@limapholos.matflo.wg> On Fri, 5 May 2017 12:01:47 +0200 (CEST) Michael Van Canneyt via Lazarus wrote: >[...] > > Believe me, I use it in production without any problems: I have > > unicode-aware TStrings, I can read files with unicode names, I can do > > everything with plain FPC trunk. > > I am aware of this, I do it myself. > But I work on Linux, where UTF8 is the norm. > > So I cannot vouch for other platforms... It worked on Linux since years. Since FPC 3.0 it works on Windows too. Mattias From nc-gaertnma at netcologne.de Fri May 5 12:42:20 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Fri, 5 May 2017 12:42:20 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <7aca3d3e-8705-88db-9925-88614393c190@kluug.net> References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <20170505114148.765f720b@limapholos.matflo.wg> <86ae8e8b-21d1-41a5-bd48-c27fddd98359@geldenhuys.co.uk> <20170505120819.17aaedee@limapholos.matflo.wg> <7aca3d3e-8705-88db-9925-88614393c190@kluug.net> Message-ID: <20170505124220.413b5356@limapholos.matflo.wg> On Fri, 5 May 2017 12:17:22 +0200 Ondrej Pokorny via Lazarus wrote: >[...] > Embarcadero realized they made a mistake when they disabled (yes, only > disabled not removed) 8-byte strings from NEXTGEN compilers. UTF8String > and RawByteString are back for all NEXTGEN compilers since 10.1. You can > use them in Linux Delphi as well. > > http://andy.jgknet.de/blog/2016/05/system-bytestrings-for-10-1-berlin/ Wow. I guess that means FPC lost the title of "compiler with most confusing string types". Mattias From juha.manninen62 at gmail.com Fri May 5 12:46:43 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Fri, 5 May 2017 13:46:43 +0300 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> Message-ID: On Fri, May 5, 2017 at 9:43 AM, Michael Van Canneyt via Lazarus wrote: > What tricks do you still need in 3.0.x ? The annoying tricky part with our UTF-8 solution is the assignment of Unicode string literals. With UTF-8 BOM it does not work at all, as discussed here. Without BOM it depends on string type + compiler settings in an illogical way. We would need a more robust solution for that. Do you have ideas? Juha From michael at freepascal.org Fri May 5 12:52:48 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Fri, 5 May 2017 12:52:48 +0200 (CEST) Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> Message-ID: On Fri, 5 May 2017, Juha Manninen via Lazarus wrote: > On Fri, May 5, 2017 at 9:43 AM, Michael Van Canneyt via Lazarus > wrote: >> What tricks do you still need in 3.0.x ? > > The annoying tricky part with our UTF-8 solution is the assignment of > Unicode string literals. > With UTF-8 BOM it does not work at all, as discussed here. > Without BOM it depends on string type + compiler settings in an illogical way. > We would need a more robust solution for that. Do you have ideas? I propose to let the compiler observe the BOM. But I don't think more is needed. Michael. From juergen.hestermann at gmx.de Fri May 5 12:55:55 2017 From: juergen.hestermann at gmx.de (=?UTF-8?Q?J=c3=bcrgen_Hestermann?=) Date: Fri, 5 May 2017 12:55:55 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <2639f07e-2a3d-6591-a3be-8643b3386ccf@geldenhuys.co.uk> References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <500ffa2a-7aef-3c21-5b84-dcb4931e6921@geldenhuys.co.uk> <2639f07e-2a3d-6591-a3be-8643b3386ccf@geldenhuys.co.uk> Message-ID: <6f8b278f-ce94-d21f-c148-e99faabf815d@gmx.de> Am 2017-05-05 um 12:16 schrieb Graeme Geldenhuys via Lazarus: > In the end it’s about supporting Unicode. Does it really matter > what internal encoding it is to achieve the “Unicode support” > goal? From a performance perspective it may be unwanted to convert string encodings back and forth all the time. Although, in my file manager I use UTF-8 internally and convert to/from UTF-16 for all Windows API functions and I never found any problem with it. The time that the API functions requires is so much longer than the time for string conversion that it does not matter at all. Even fast API-functions like changing attributes only take a second for thousands of files. A situation where it may be a problem is when reading (UTF-16 encoded) text files. But I never stumbled over such a thing yet. I would promote the use of UTF-8 whereever possible while converting to target encodings only when unavoidable. It makes life much easier if you only concentrate on one (the best) Unicode encoding (UTF-8). Therefore I see no use of a UTF-16 bases RTL. I don't think that you would notice any performance difference to the UTF-8 based RTL. It would only waste valuable time that can be invested in other things. From lazarus at kluug.net Fri May 5 12:56:23 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Fri, 5 May 2017 12:56:23 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <500ffa2a-7aef-3c21-5b84-dcb4931e6921@geldenhuys.co.uk> Message-ID: On 05.05.2017 12:01, Michael Van Canneyt via Lazarus wrote: > On Fri, 5 May 2017, Ondrej Pokorny via Lazarus wrote: >> Believe me, I use it in production without any problems: I have >> unicode-aware TStrings, I can read files with unicode names, I can do >> everything with plain FPC trunk. > > I am aware of this, I do it myself. But I work on Linux, where UTF8 is > the norm. > > So I cannot vouch for other platforms... For now I am only on Windows and I have to say loadly: IT WORKS GREAT :) >> I don't need a 100% UTF-16 Delphi-Compatible RTL for that at all. > > This is the crux of the problem. Is this wanted/needed or do we stick > to UTF8 ? > > We claim Delphi compatibility. So IMHO we must provide a UTF-16 Delphi > compatible RTL. I write code that is compatible with FPC and Delphi 5 - 10.2 and it works fine. So you already have a Delphi-compatible RTL. The only (well documented) difference is that FPC uses single-byte string and Delphi uses 2-byte string. The only place where you need to handle the difference is where you need the size of char (when you access string as buffer) - which is particularly low-level code: MyStream.WriteBuffer(MyString[1], Length(MyString) * SizeOf(Char)); -> you need the extra SizeOf(Char) and not a constant (1 for fpc, 2 for unicode Delphi). That's all. All high-level code is compatible already. Good job. I really do think it's not worth it to pollute FPC RTL with UnicodeString overloads of every function, class etc. Better to keep 1 clean approach (UTF-8 RTL) and not confuse people with 2 approaches (UTF-8 vs UTF-16). E.g. how do you want to call the new UnicodeString-TStrings class? You have 2 options: 1.) Break compatibility to legacy FPC. (New TStrings will use UnicodeString.) 2.) Break compatibility to Delphi. (TStrings will stay with 8-byte string.) There is no obvious solution for the problem :/ And then if you will introduce a compiler switch to change String from 1-byte to 2-bytes... Oh no, so much mess and so many variants to care about. Really, sometimes it's better to give people no options :) (Or have you already introduced the switch?) Just stick with current utf8 approach that proved well :) Ondrej From lazarus at kluug.net Fri May 5 12:59:49 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Fri, 5 May 2017 12:59:49 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <6f8b278f-ce94-d21f-c148-e99faabf815d@gmx.de> References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <500ffa2a-7aef-3c21-5b84-dcb4931e6921@geldenhuys.co.uk> <2639f07e-2a3d-6591-a3be-8643b3386ccf@geldenhuys.co.uk> <6f8b278f-ce94-d21f-c148-e99faabf815d@gmx.de> Message-ID: <15b8e63d-7130-3549-d1c6-0904e799fb74@kluug.net> On 05.05.2017 12:55, Jürgen Hestermann via Lazarus wrote: > A situation where it may be a problem is when reading > (UTF-16 encoded) text files. No, not at all. If you convert the file on the fly, there is almost 0 performance penalty. Ondrej From mailinglists at geldenhuys.co.uk Fri May 5 13:02:48 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 5 May 2017 12:02:48 +0100 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <500ffa2a-7aef-3c21-5b84-dcb4931e6921@geldenhuys.co.uk> Message-ID: <979db791-8f89-23b2-c00d-cfc08aa1d77c@geldenhuys.co.uk> On 2017-05-05 10:41, Ondrej Pokorny via Lazarus wrote: > Just use "DefaultSystemCodePage := CP_UTF8" and every single-byte string > is unicode enabled. So does that mean you don't have to also call the following two functions (which LCL does). SetMultiByteConversionCodePage(CP_UTF8); SetMultiByteRTLFileSystemCodePage(CP_UTF8); So doing DefaultSystemCodePage := CP_UTF8; is all you need to switch the RTL, FCL and the String data type to UTF-8? If so, when why does LCL also call the above two functions? Regards, Graeme From juha.manninen62 at gmail.com Fri May 5 13:12:05 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Fri, 5 May 2017 14:12:05 +0300 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> Message-ID: On Fri, May 5, 2017 at 1:20 AM, Graeme Geldenhuys via Lazarus wrote: > A case in point. Looking at the Wiki page you listed, I read the following: > " > Since FPC 3.0 you must add the flag -FcUTF8 or add {$codepage UTF8} at the beginning of the unit. > ... Uhhh, the same page in "String Literals" section says: "In most cases {$codepage utf8} / -FcUTF8 is not needed." which is the correct information. Also this wiki page has become a mess when many people add stuff but nobody removes any. For example Michl added the grid about how constant assignment works with and without {$codepage utf8}. It is nice but he didn't remove the other paragraphs explaining the same thing. It looks like an extremely complex topic for a new user, while in reality he should code like with Delphi + remember only few simple rules. Then Mattias adds FAQs contradicting the earlier texts ... The comment from Martok was valid. This page is not good for users who just want to get started quickly. I will simplify the page. I will remove stuff and move the FAQ to a new page. Sorry in advance for people who's text will be removed. Juha From mailinglists at geldenhuys.co.uk Fri May 5 13:14:38 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 5 May 2017 12:14:38 +0100 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <6f8b278f-ce94-d21f-c148-e99faabf815d@gmx.de> References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <500ffa2a-7aef-3c21-5b84-dcb4931e6921@geldenhuys.co.uk> <2639f07e-2a3d-6591-a3be-8643b3386ccf@geldenhuys.co.uk> <6f8b278f-ce94-d21f-c148-e99faabf815d@gmx.de> Message-ID: <2711fe73-b804-ac9d-8870-b3335c5181bc@geldenhuys.co.uk> On 2017-05-05 11:55, Jürgen Hestermann via Lazarus wrote: > I use UTF-8 internally and > convert to/from UTF-16 for all Windows API functions and > I never found any problem with it. > The time that the API functions requires is so much longer than the > time for string conversion that it does not matter at all. This is what I've been doing for years, and I agree, it works great. Windows is also the only platform (of any modern OS) that doesn't use UTF-8 as standard - so I consider it the minority. > A situation where it may be a problem is when reading > (UTF-16 encoded) text files. I'm yet to find a UTF-16 encoded text file in the wild. I'm not saying they don't exist, I'm just saying they are extremely rare and more like an anomaly. UTF-8 seems to rule the roost and the Internet. This graph should say it all: https://en.wikipedia.org/wiki/File:Utf8webgrowth.svg (source): https://en.wikipedia.org/wiki/UTF-8 Even so, a simple conversion to UTF-8 at load time should resolve all possible problems. 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 Fri May 5 13:15:23 2017 From: mschnell at lumino.de (Michael Schnell) Date: Fri, 5 May 2017 13:15:23 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <2639f07e-2a3d-6591-a3be-8643b3386ccf@geldenhuys.co.uk> References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <500ffa2a-7aef-3c21-5b84-dcb4931e6921@geldenhuys.co.uk> <2639f07e-2a3d-6591-a3be-8643b3386ccf@geldenhuys.co.uk> Message-ID: On 05.05.2017 12:16, Graeme Geldenhuys via Lazarus wrote: > In the end it’s about supporting Unicode. Does it really matter > what internal encoding it is to achieve the “Unicode support” > goal? > Yep it does. There are ways around that issue (i.e. code aware strings) but in fact these trigger a new bunch of problems. You might want to read -> http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support -Michael From nc-gaertnma at netcologne.de Fri May 5 13:17:33 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Fri, 5 May 2017 13:17:33 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> Message-ID: <20170505131733.0f67e9df@limapholos.matflo.wg> On Fri, 5 May 2017 12:52:48 +0200 (CEST) Michael Van Canneyt via Lazarus wrote: >[...] > I propose to let the compiler observe the BOM. > But I don't think more is needed. FPC observes the BOM. Same as Delphi. I wonder if it would help if FPC would store UTF-8 string literals as UTF-8 and how much work that is. Mattias From michael at freepascal.org Fri May 5 13:29:01 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Fri, 5 May 2017 13:29:01 +0200 (CEST) Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <20170505131733.0f67e9df@limapholos.matflo.wg> References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <20170505131733.0f67e9df@limapholos.matflo.wg> Message-ID: On Fri, 5 May 2017, Mattias Gaertner via Lazarus wrote: > On Fri, 5 May 2017 12:52:48 +0200 (CEST) > Michael Van Canneyt via Lazarus wrote: > >> [...] >> I propose to let the compiler observe the BOM. >> But I don't think more is needed. > > FPC observes the BOM. Same as Delphi. Then what is still the problem ? > > I wonder if it would help if FPC would store UTF-8 string literals as > UTF-8 and how much work that is. Amount of work is probably not so much. The question is whether it will cause problems for e.g. the JVM code generator. But I still fail to see the actual problem, aside from a lot of confusion by users. Confusion arises from a lack of clear information. So in my opinion, we simply need to provide clear information, before we start changing things. Michael. From mailinglists at geldenhuys.co.uk Fri May 5 13:35:46 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 5 May 2017 12:35:46 +0100 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <20170505131733.0f67e9df@limapholos.matflo.wg> References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <20170505131733.0f67e9df@limapholos.matflo.wg> Message-ID: <30f45e1e-91d2-be4d-7555-3281c40a0f16@geldenhuys.co.uk> On 2017-05-05 12:17, Mattias Gaertner via Lazarus wrote: > I wonder if it would help if FPC would store UTF-8 string literals as > UTF-8 Yeah, that would be the logical thing to do. FPC not doing that is what really confused me. Regards, Graeme From lazarus at kluug.net Fri May 5 13:41:26 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Fri, 5 May 2017 13:41:26 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <979db791-8f89-23b2-c00d-cfc08aa1d77c@geldenhuys.co.uk> References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <500ffa2a-7aef-3c21-5b84-dcb4931e6921@geldenhuys.co.uk> <979db791-8f89-23b2-c00d-cfc08aa1d77c@geldenhuys.co.uk> Message-ID: <84471499-acdd-9b58-ffc0-3131ed1ed2df@kluug.net> On 05.05.2017 13:02, Graeme Geldenhuys via Lazarus wrote: > On 2017-05-05 10:41, Ondrej Pokorny via Lazarus wrote: >> Just use "DefaultSystemCodePage := CP_UTF8" and every single-byte string >> is unicode enabled. > So does that mean you don't have to also call the following two functions (which LCL does). > > SetMultiByteConversionCodePage(CP_UTF8); > SetMultiByteRTLFileSystemCodePage(CP_UTF8); > > > So doing > > DefaultSystemCodePage := CP_UTF8; > > is all you need to switch the RTL, FCL and the String data type to UTF-8? > > If so, when why does LCL also call the above two functions? SetMultiByteConversionCodePage does only one thing: it sets DefaultSystemCodePage :) So yes, if you set DefaultSystemCodePage you don't have to call SetMultiByteConversionCodePage. You are right - I forgot about SetMultiByteRTLFileSystemCodePage/DefaultRTLFileSystemCodePage. BUT if I take a look into the RTL sources I see that it's used only in FindFirst/FindNext, FExpand and GetDir/do_GetDir. And only in the result strings. IMO it could be removed and replaced with DefaultSystemCodePage. Ondrej From juha.manninen62 at gmail.com Fri May 5 13:41:50 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Fri, 5 May 2017 14:41:50 +0300 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <20170505131733.0f67e9df@limapholos.matflo.wg> Message-ID: On Fri, May 5, 2017 at 2:29 PM, Michael Van Canneyt via Lazarus wrote: > Then what is still the problem ? With BOM you get: Error: UTF-8 code greater than 65535 found which is counter-intuitive when the file and the string literal are both UTF-8. It is related to changing the default codepage at run-time which is a hack from FPC's POV. For the same reason we need this grid: http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus#String_Literals_Overview So, it is not only a communication issue. It is truly messy. If only it could be improved... Juha From juha.manninen62 at gmail.com Fri May 5 13:49:28 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Fri, 5 May 2017 14:49:28 +0300 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <979db791-8f89-23b2-c00d-cfc08aa1d77c@geldenhuys.co.uk> References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <500ffa2a-7aef-3c21-5b84-dcb4931e6921@geldenhuys.co.uk> <979db791-8f89-23b2-c00d-cfc08aa1d77c@geldenhuys.co.uk> Message-ID: On Fri, May 5, 2017 at 2:02 PM, Graeme Geldenhuys via Lazarus wrote: > If so, when why does LCL also call the above two functions? Graeme, they are called by LazUtils package, LazUTF8 unit, not by LCL. It is not limited to GUI programming. A wrong information easily propagates, thus it is important to get this right. Juha From mailinglists at geldenhuys.co.uk Fri May 5 14:05:37 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 5 May 2017 13:05:37 +0100 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <500ffa2a-7aef-3c21-5b84-dcb4931e6921@geldenhuys.co.uk> <979db791-8f89-23b2-c00d-cfc08aa1d77c@geldenhuys.co.uk> Message-ID: <255db238-2484-ae88-c742-9214c1dd3a3d@geldenhuys.co.uk> On 2017-05-05 12:49, Juha Manninen via Lazarus wrote: > A wrong information easily propagates, thus it is important to get this right. No worries, I agree. Thanks for correcting my terminology. Regards, Graeme From pascaldragon at googlemail.com Fri May 5 14:56:19 2017 From: pascaldragon at googlemail.com (Sven Barth) Date: Fri, 5 May 2017 14:56:19 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <20170505131733.0f67e9df@limapholos.matflo.wg> Message-ID: Am 05.05.2017 13:50 schrieb "Juha Manninen via Lazarus" < lazarus at lists.lazarus-ide.org>: > > On Fri, May 5, 2017 at 2:29 PM, Michael Van Canneyt via Lazarus > wrote: > > Then what is still the problem ? > > With BOM you get: > Error: UTF-8 code greater than 65535 found > which is counter-intuitive when the file and the string literal are both UTF-8. That is mainly due to the compiler not supporting surrogate pairs for the UTF-8 -> UTF-16 conversion. If it would support them, then there wouldn't be a problem anymore... (though of course it would need to be ensured that other parts of the RTL support surrogate pairs as well) Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From nc-gaertnma at netcologne.de Fri May 5 15:21:30 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Fri, 5 May 2017 15:21:30 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> Message-ID: <20170505152130.7f9e8cf9@limapholos.matflo.wg> On Fri, 5 May 2017 14:12:05 +0300 Juha Manninen via Lazarus wrote: >[...] > Then Mattias adds FAQs contradicting the earlier texts ... Oops. Which one? Mattias From juha.manninen62 at gmail.com Fri May 5 15:28:56 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Fri, 5 May 2017 16:28:56 +0300 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <20170505152130.7f9e8cf9@limapholos.matflo.wg> References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505152130.7f9e8cf9@limapholos.matflo.wg> Message-ID: On Fri, May 5, 2017 at 3:56 PM, Sven Barth via Lazarus wrote: > That is mainly due to the compiler not supporting surrogate pairs for the > UTF-8 -> UTF-16 conversion. If it would support them, then there wouldn't be > a problem anymore... That is a serious bug. Getting codepoints right is the absolute minimum requirement for Unicode support. Surrogate pairs are the UTF-16 equivalent of multi-byte codepoints in UTF-8. Now I understand this was not caused by our UTF-8 run-time switch "hack". It is a plain bug in FPC. Is there a plan to fix it? Juha From juha.manninen62 at gmail.com Fri May 5 15:36:51 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Fri, 5 May 2017 16:36:51 +0300 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <20170505152130.7f9e8cf9@limapholos.matflo.wg> References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505152130.7f9e8cf9@limapholos.matflo.wg> Message-ID: On Fri, May 5, 2017 at 4:21 PM, Mattias Gaertner via Lazarus wrote: > Oops. Which one? The FAQ says: "Since FPC 3.0 you must add the flag -FcUTF8 or add {$codepage UTF8} at the beginning of the unit." The same page in "String Literals" section says: "In most cases {$codepage utf8} / -FcUTF8 is not needed." which is the correct information. Actually I don't know if that FAQ entry is yours. Many people have added stuff there. The page is intimidating for a user who just wants to support Unicode without a fuss. Juha From nc-gaertnma at netcologne.de Fri May 5 15:44:13 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Fri, 5 May 2017 15:44:13 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <99e19f05-59bd-9909-3e44-745b13a120a5@mccallumwhyman.com> <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505152130.7f9e8cf9@limapholos.matflo.wg> Message-ID: <20170505154413.3b01c2aa@limapholos.matflo.wg> On Fri, 5 May 2017 16:36:51 +0300 Juha Manninen via Lazarus wrote: > On Fri, May 5, 2017 at 4:21 PM, Mattias Gaertner via Lazarus > wrote: > > Oops. Which one? > > The FAQ says: > "Since FPC 3.0 you must add the flag -FcUTF8 or add {$codepage UTF8} > at the beginning of the unit." I improved it a bit. Mattias From Sascha.Hestermann at gmx.de Sat May 6 20:17:18 2017 From: Sascha.Hestermann at gmx.de (Gabor Boros) Date: Sat, 6 May 2017 14:17:18 -0400 Subject: [Lazarus] =?utf-8?q?=E2=9C=88Re=3A_amazing_news!?= Message-ID: <1851514870.20170506211718@gmx.de> Yo! This news is going to amaze you, I'm telling you! Just check it out http://frame.williamtara.com Gabor Boros Sent from Mail for Windows 10 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 9DEA12365121458EC794062773640BD0.jpg Type: image/jpeg Size: 24945 bytes Desc: not available URL: From Sascha.Hestermann at gmx.de Sat May 6 20:17:46 2017 From: Sascha.Hestermann at gmx.de (John Landmesser) Date: Sun, 7 May 2017 02:17:46 +0800 Subject: [Lazarus] =?utf-8?q?=E2=98=A0Re=3A_absolutely_amazing?= Message-ID: <1520806898.20170506211746@gmx.de> Yo! I've been looking for some stuff and have accidentally come across that absolutely amazing things, just take a look at them http://algunde.crosscue.com Wishes, John Landmesser Sent from Mail for Windows 10 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 25E1E9796F220C34E4F3F2ED2720EEB6.jpg Type: image/jpeg Size: 18503 bytes Desc: not available URL: From michael at freepascal.org Sat May 6 21:26:38 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Sat, 6 May 2017 21:26:38 +0200 (CEST) Subject: [Lazarus] Menu editor unstable? Message-ID: Hi, The menu editor of lazarus trunk seems highly unstable. I've had 10+ crashes of lazarus in the last 2 hours, all due to the menu editor. The crash means that I get an access violation and I must actually kill lazarus, because once I click away the access violation dialog, the lazarus windows redraw, but respond to no other messages. The only thing that helps is a KILL signal. I have not exactly been able to reproduce reliably, but the following just triggered it: - Start IDE - Open project - Select a popup menu (there are several) - Double click to edit - Select menu item 1 - Immediatly select menu item 2. -> crash. But also simply selecting something in the menu editor, and going to the object inspector can crash it. As a result I find myself saving all files before entering the menu editor. Not exactly ideal, to say the least. Anyone else experiencing this ? Latest Lazarus from SVN. GTK2, linux 64-bit. Michael. From mircocasini at libero.it Sun May 7 07:43:23 2017 From: mircocasini at libero.it (Mirco Casini) Date: Sun, 7 May 2017 10:43:23 +0500 Subject: [Lazarus] =?utf-8?q?=E2=98=A2safe_and_sound?= Message-ID: <1328834054.20170507084323@libero.it> Greetings! After a month of journey I'm finally back home, it was a lovely journey, and I'm safe and sound))) Please read more about my adventures here http://elysha.dreddscott.com Sent from a prehistoric stone tablet, Mirco Casini From gabriella.lynns at gmx.com Sun May 7 07:48:47 2017 From: gabriella.lynns at gmx.com (Gabriella Lynns) Date: Sun, 7 May 2017 07:48:47 +0200 Subject: [Lazarus] Installation issue - unit not found Message-ID: An HTML attachment was scrubbed... URL: From michael at freepascal.org Sun May 7 09:02:16 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Sun, 7 May 2017 09:02:16 +0200 (CEST) Subject: [Lazarus] Installation issue - unit not found In-Reply-To: References: Message-ID: On Sun, 7 May 2017, Gabriella Lynns via Lazarus wrote: > I have been trying to install Lazarus for two unprivileged users, each in a subdirectory of their own $HOME  I've been using a > script originally from getlazarus.org >   > The first installation went smoothly. The second, using exactly the same script, failed with: >   > /home/gl/Development/FreePascal/lazarus/components/lazutils/lazutils.pas(20,47) Fatal: (10022) Can't find unit > LazarusPackageIntf used by LazUtils > Fatal: (1018) Compilation aborted > Makefile:2702: recipe for target 'lazutils.ppu' failed > make[1]: *** [lazutils.ppu] Error 1 > make[1]: Leaving directory '/home/gl/Development/FreePascal/lazarus/components/lazutils' > Makefile:3052: recipe for target 'lazutils' failed > make: *** [lazutils] Error 2 >   > This occurs during the lazarus 'make all'. fpc installed fine. >   > Any idea what is going on here? Why does a script which works for one unprivileged user fail with another unprivileged user 5 > minutes later? The only difference I can see in the two users is that one of them (the one that fails) is in the SUDOERS file. > And there is no sudo in the setup script. Is this on the same machine ? if so: Does the script use the /tmp directory ? Maybe there are some leftover files in some subdirectory of the /tmp directory ? If not: does the second machine contain a prior installation of Free/Pascal lzazarus ? Michael. From florian at freepascal.org Sun May 7 10:10:26 2017 From: florian at freepascal.org (Florian Klaempfl) Date: Sun, 7 May 2017 10:10:26 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <30f45e1e-91d2-be4d-7555-3281c40a0f16@geldenhuys.co.uk> References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <20170505131733.0f67e9df@limapholos.matflo.wg> <30f45e1e-91d2-be4d-7555-3281c40a0f16@geldenhuys.co.uk> Message-ID: Am 05.05.2017 um 13:35 schrieb Graeme Geldenhuys via Lazarus: > On 2017-05-05 12:17, Mattias Gaertner via Lazarus wrote: >> I wonder if it would help if FPC would store UTF-8 string literals as >> UTF-8 > > Yeah, that would be the logical thing to do. Why? What makes a string literal UTF-8? > FPC not doing that is what > really confused me. You have to distinuish between source encoding and string encoding. From nc-gaertnma at netcologne.de Sun May 7 10:30:23 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Sun, 7 May 2017 10:30:23 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <20170505131733.0f67e9df@limapholos.matflo.wg> <30f45e1e-91d2-be4d-7555-3281c40a0f16@geldenhuys.co.uk> Message-ID: <20170507103023.39b8c084@limapholos.matflo.wg> On Sun, 7 May 2017 10:10:26 +0200 Florian Klaempfl via Lazarus wrote: > Am 05.05.2017 um 13:35 schrieb Graeme Geldenhuys via Lazarus: > > On 2017-05-05 12:17, Mattias Gaertner via Lazarus wrote: > >> I wonder if it would help if FPC would store UTF-8 string literals as > >> UTF-8 > > > > Yeah, that would be the logical thing to do. > > Why? What makes a string literal UTF-8? Here: $codepage utf-8 and non ASCII. > > FPC not doing that is what > > really confused me. > > You have to distinuish between source encoding and string encoding. Yes, but sometimes the string encoding is not obvious: {$codepage utf8} const s = 'äöüالعَرَبِيَّة'; begin writeln(s); // needs widestringmanager end. Mattias From nc-gaertnma at netcologne.de Sun May 7 10:36:51 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Sun, 7 May 2017 10:36:51 +0200 Subject: [Lazarus] Menu editor unstable? In-Reply-To: References: Message-ID: <20170507103651.15696d9d@limapholos.matflo.wg> On Sat, 6 May 2017 21:26:38 +0200 (CEST) Michael Van Canneyt via Lazarus wrote: >[...] > I have not exactly been able to reproduce reliably, but the following just triggered > it: > - Start IDE > - Open project > - Select a popup menu (there are several) > - Double click to edit > - Select menu item 1 > - Immediatly select menu item 2. > -> crash. > > But also simply selecting something in the menu editor, and going to the object > inspector can crash it. > > As a result I find myself saving all files before entering the menu editor. > Not exactly ideal, to say the least. > > Anyone else experiencing this ? > > Latest Lazarus from SVN. GTK2, linux 64-bit. It does not crash here. So it needs something more to trigger the bug. Maybe the FPC Version? Stacktrace? Mattias From florian at freepascal.org Sun May 7 10:42:36 2017 From: florian at freepascal.org (Florian Klaempfl) Date: Sun, 7 May 2017 10:42:36 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <20170507103023.39b8c084@limapholos.matflo.wg> References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <20170505131733.0f67e9df@limapholos.matflo.wg> <30f45e1e-91d2-be4d-7555-3281c40a0f16@geldenhuys.co.uk> <20170507103023.39b8c084@limapholos.matflo.wg> Message-ID: Am 07.05.2017 um 10:30 schrieb Mattias Gaertner via Lazarus: > On Sun, 7 May 2017 10:10:26 +0200 > Florian Klaempfl via Lazarus wrote: > >> Am 05.05.2017 um 13:35 schrieb Graeme Geldenhuys via Lazarus: >>> On 2017-05-05 12:17, Mattias Gaertner via Lazarus wrote: >>>> I wonder if it would help if FPC would store UTF-8 string literals as >>>> UTF-8 >>> >>> Yeah, that would be the logical thing to do. >> >> Why? What makes a string literal UTF-8? > > Here: $codepage utf-8 and non ASCII. > > >>> FPC not doing that is what >>> really confused me. >> >> You have to distinuish between source encoding and string encoding. > > Yes, but sometimes the string encoding is not obvious: > > {$codepage utf8} > const s = 'äöüالعَرَبِيَّة'; > begin > writeln(s); // needs widestringmanager > end. Yes. Which is good imo. The compiler should call the unicode writeln in this case and this requires a widestringmanager (where I agree, its name is chosen wrong, it should be named unicodestringmanager) anyways. If the string were encoded UTF-8 and the ansistring writeln is called, your example would work only on a system with an utf-8 console. But you can achieve the same (broken output) by just leaving away the codepage directive then. It will not work on non utf-8 consoles either. From michael at freepascal.org Sun May 7 11:29:57 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Sun, 7 May 2017 11:29:57 +0200 (CEST) Subject: [Lazarus] Menu editor unstable? In-Reply-To: <20170507103651.15696d9d@limapholos.matflo.wg> References: <20170507103651.15696d9d@limapholos.matflo.wg> Message-ID: On Sun, 7 May 2017, Mattias Gaertner via Lazarus wrote: > On Sat, 6 May 2017 21:26:38 +0200 (CEST) > Michael Van Canneyt via Lazarus wrote: > >> [...] >> I have not exactly been able to reproduce reliably, but the following just triggered >> it: >> - Start IDE >> - Open project >> - Select a popup menu (there are several) >> - Double click to edit >> - Select menu item 1 >> - Immediatly select menu item 2. >> -> crash. >> >> But also simply selecting something in the menu editor, and going to the object >> inspector can crash it. >> >> As a result I find myself saving all files before entering the menu editor. >> Not exactly ideal, to say the least. >> >> Anyone else experiencing this ? >> >> Latest Lazarus from SVN. GTK2, linux 64-bit. > > It does not crash here. So it needs something more to trigger the bug. > Maybe the FPC Version? 3.0.2 > Stacktrace? I will try to get one. Michael. From mailinglists at geldenhuys.co.uk Sun May 7 11:57:31 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Sun, 7 May 2017 10:57:31 +0100 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <20170505131733.0f67e9df@limapholos.matflo.wg> <30f45e1e-91d2-be4d-7555-3281c40a0f16@geldenhuys.co.uk> Message-ID: <3e65aa41-34ed-fe7a-ac62-94aa46986dae@geldenhuys.co.uk> On 2017-05-07 09:10, Florian Klaempfl via Lazarus wrote: >> Yeah, that would be the logical thing to do. > > Why? What makes a string literal UTF-8? > As Mattias said, the fact that the source unit is UTF-8 encoded. Defined by a BOM marker, or -Fcutf8 or {$codepage utf8}. If the source unit is UTF-8 encoded, the literal string constant can't (and shouldn't) be in any other encoding. I would say the same if the source unit was stored in UTF-16 encoding. Then string literals would be treated as UTF-16. It's perfectly logical to me. 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 May 7 12:02:49 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Sun, 7 May 2017 12:02:49 +0200 (CEST) Subject: [Lazarus] Form resize to standard size in IDE. Message-ID: Hi, Another oddity in the IDE designer. I have a form which contains some group boxes, radio buttons and a buttonpanel. Bordertstyle is bsDialog. No special properties regarding autosize or whatsoever have been set. When I switch (using F12) between source and form, it *always* resizes to some seemingly standard size and I need to fix the size. The form just contains the following: Height = 279 Top = 218 Width = 443 BorderStyle = bsDialog Caption = 'Resize Selected elements' ClientHeight = 279 ClientWidth = 443 Position = poOwnerFormCenter LCLVersion = '1.9.0.0' I have attached it for reference. I suspect the scaling and high-dpi is at work here: I have a dual-monitor system, with xinerama. To test that hypothesis, I tried to set scaled to false, but it doesn't help. Also: When the form designer is active, and I press save, the form is marked 'dirty' (i.e. not saved!) Anything I can do to help to diagnose the issue ? Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: frm.zip Type: application/zip Size: 1390 bytes Desc: URL: From florian at freepascal.org Sun May 7 12:07:24 2017 From: florian at freepascal.org (Florian Klaempfl) Date: Sun, 7 May 2017 12:07:24 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: <3e65aa41-34ed-fe7a-ac62-94aa46986dae@geldenhuys.co.uk> References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <20170505131733.0f67e9df@limapholos.matflo.wg> <30f45e1e-91d2-be4d-7555-3281c40a0f16@geldenhuys.co.uk> <3e65aa41-34ed-fe7a-ac62-94aa46986dae@geldenhuys.co.uk> Message-ID: Am 07.05.2017 um 11:57 schrieb Graeme Geldenhuys via Lazarus: > On 2017-05-07 09:10, Florian Klaempfl via Lazarus wrote: >>> Yeah, that would be the logical thing to do. >> >> Why? What makes a string literal UTF-8? >> > > As Mattias said, the fact that the source unit is UTF-8 encoded. > Defined by a BOM marker, or -Fcutf8 or {$codepage utf8}. If the source > unit is UTF-8 encoded, the literal string constant can't (and > shouldn't) be in any other encoding. > > I would say the same if the source unit was stored in UTF-16 > encoding. Then string literals would be treated as UTF-16. And if a ISO/Ansi codepage is given? Things would probably fail. The point is: FPC is consistent in this regard: also sources with a given iso/ansi codepage are handled the same way. If there is a string literal with non-ascii chars, it is converted to UTF-16 using the codepage of the source. Very simple, very logical. It is a matter of preference if UTF-8, -16, -32 are chosen at this point, but FPC uses UTF-16. If it uses UTF-8, the problem would occur the other way around. If no codepage is given (by directive, command line, BOM), string literals are handled byte-wise as raw strings. > > It's perfectly logical to me. It is logical only in a limited view. From michael at freepascal.org Sun May 7 12:11:13 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Sun, 7 May 2017 12:11:13 +0200 (CEST) Subject: [Lazarus] Annoying lazarus mailing list behaviour Message-ID: Hi, Can we please get rid of the Cc: being added to the mails sent through the lazarus mailing list ? In most cases, when I reply, I get 2 recipients. I always must delete 1. When the original mail comes from Mattias Gaertner, I *invariably* get 3 reply addresses: to : Mattias Gaertner via Lazarus Cc : lazarus at lists.lazarus.freepascal.org, Mattias Gaertner I suspect that Mattias still uses the 'old' list address in his mails when posting, and that this is why I get 3 recipients. This is VERY annoying. (not the mails from Mattias, but the mailing list behaviour ;) ) Michael. From pascaldragon at googlemail.com Sun May 7 12:11:26 2017 From: pascaldragon at googlemail.com (Sven Barth) Date: Sun, 7 May 2017 12:11:26 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <7eb2dd9d-4381-1455-1cc3-9c900ee4af65@geldenhuys.co.uk> <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <20170505131733.0f67e9df@limapholos.matflo.wg> <30f45e1e-91d2-be4d-7555-3281c40a0f16@geldenhuys.co.uk> <3e65aa41-34ed-fe7a-ac62-94aa46986dae@geldenhuys.co.uk> Message-ID: Am 07.05.2017 12:07 schrieb "Florian Klaempfl via Lazarus" < lazarus at lists.lazarus-ide.org>: > > Am 07.05.2017 um 11:57 schrieb Graeme Geldenhuys via Lazarus: > > On 2017-05-07 09:10, Florian Klaempfl via Lazarus wrote: > >>> Yeah, that would be the logical thing to do. > >> > >> Why? What makes a string literal UTF-8? > >> > > > > As Mattias said, the fact that the source unit is UTF-8 encoded. > > Defined by a BOM marker, or -Fcutf8 or {$codepage utf8}. If the source > > unit is UTF-8 encoded, the literal string constant can't (and > > shouldn't) be in any other encoding. > > > > I would say the same if the source unit was stored in UTF-16 > > encoding. Then string literals would be treated as UTF-16. > > And if a ISO/Ansi codepage is given? Things would probably fail. > > The point is: FPC is consistent in this regard: also sources with a > given iso/ansi codepage are handled the same way. If there is a string > literal with non-ascii chars, it is converted to UTF-16 using the > codepage of the source. Very simple, very logical. It is a matter of > preference if UTF-8, -16, -32 are chosen at this point, but FPC uses > UTF-16. If it uses UTF-8, the problem would occur the other way around. > > If no codepage is given (by directive, command line, BOM), string > literals are handled byte-wise as raw strings. Small correction: FPC only does this conversion if the codepage is UTF-8, no other. Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From pascaldragon at googlemail.com Sun May 7 12:15:21 2017 From: pascaldragon at googlemail.com (Sven Barth) Date: Sun, 7 May 2017 12:15:21 +0200 Subject: [Lazarus] Annoying lazarus mailing list behaviour In-Reply-To: References: Message-ID: Am 07.05.2017 12:11 schrieb "Michael Van Canneyt via Lazarus" < lazarus at lists.lazarus-ide.org>: > > > Hi, > > Can we please get rid of the Cc: being added to the mails sent through the lazarus > mailing list ? > > In most cases, when I reply, I get 2 recipients. I always must delete 1. > > When the original mail comes from Mattias Gaertner, I *invariably* get 3 reply addresses: > > to : Mattias Gaertner via Lazarus > Cc : lazarus at lists.lazarus.freepascal.org, > Mattias Gaertner > > I suspect that Mattias still uses the 'old' list address in his mails when > posting, and that this is why I get 3 recipients. > > This is VERY annoying. > > (not the mails from Mattias, but the mailing list behaviour ;) ) If you go back some months it was revealed that this is now necessary due to increased security in Gmail and Co. Otherwise mails from the list would be bounced. Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From florian at freepascal.org Sun May 7 12:17:37 2017 From: florian at freepascal.org (Florian Klaempfl) Date: Sun, 7 May 2017 12:17:37 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <20170505131733.0f67e9df@limapholos.matflo.wg> <30f45e1e-91d2-be4d-7555-3281c40a0f16@geldenhuys.co.uk> <3e65aa41-34ed-fe7a-ac62-94aa46986dae@geldenhuys.co.uk> Message-ID: Am 07.05.2017 um 12:11 schrieb Sven Barth via Lazarus: > Am 07.05.2017 12:07 schrieb "Florian Klaempfl via Lazarus" > >: >> >> Am 07.05.2017 um 11:57 schrieb Graeme Geldenhuys via Lazarus: >> > On 2017-05-07 09:10, Florian Klaempfl via Lazarus wrote: >> >>> Yeah, that would be the logical thing to do. >> >> >> >> Why? What makes a string literal UTF-8? >> >> >> > >> > As Mattias said, the fact that the source unit is UTF-8 encoded. >> > Defined by a BOM marker, or -Fcutf8 or {$codepage utf8}. If the source >> > unit is UTF-8 encoded, the literal string constant can't (and >> > shouldn't) be in any other encoding. >> > >> > I would say the same if the source unit was stored in UTF-16 >> > encoding. Then string literals would be treated as UTF-16. >> >> And if a ISO/Ansi codepage is given? Things would probably fail. >> >> The point is: FPC is consistent in this regard: also sources with a >> given iso/ansi codepage are handled the same way. If there is a string >> literal with non-ascii chars, it is converted to UTF-16 using the >> codepage of the source. Very simple, very logical. It is a matter of >> preference if UTF-8, -16, -32 are chosen at this point, but FPC uses >> UTF-16. If it uses UTF-8, the problem would occur the other way around. >> >> If no codepage is given (by directive, command line, BOM), string >> literals are handled byte-wise as raw strings. > > Small correction: FPC only does this conversion if the codepage is > UTF-8, no other. Then something is wrong/broken :) From pascaldragon at googlemail.com Sun May 7 12:18:19 2017 From: pascaldragon at googlemail.com (Sven Barth) Date: Sun, 7 May 2017 12:18:19 +0200 Subject: [Lazarus] Annoying lazarus mailing list behaviour In-Reply-To: References: Message-ID: Am 07.05.2017 12:11 schrieb "Michael Van Canneyt via Lazarus" < lazarus at lists.lazarus-ide.org>: > > > Hi, > > Can we please get rid of the Cc: being added to the mails sent through the lazarus > mailing list ? > > In most cases, when I reply, I get 2 recipients. I always must delete 1. > > When the original mail comes from Mattias Gaertner, I *invariably* get 3 reply addresses: > > to : Mattias Gaertner via Lazarus > Cc : lazarus at lists.lazarus.freepascal.org, > Mattias Gaertner > > I suspect that Mattias still uses the 'old' list address in his mails when > posting, and that this is why I get 3 recipients. > > This is VERY annoying. > > (not the mails from Mattias, but the mailing list behaviour ;) ) Addendum: what E-Mail client do you use? Both Android's GMail App and Thunderbird (with Reply to List) handle it correctly. Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at freepascal.org Sun May 7 12:18:22 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Sun, 7 May 2017 12:18:22 +0200 (CEST) Subject: [Lazarus] Annoying lazarus mailing list behaviour In-Reply-To: References: Message-ID: On Sun, 7 May 2017, Sven Barth via Lazarus wrote: > Am 07.05.2017 12:11 schrieb "Michael Van Canneyt via Lazarus" < > lazarus at lists.lazarus-ide.org>: >> >> >> Hi, >> >> Can we please get rid of the Cc: being added to the mails sent through > the lazarus >> mailing list ? >> >> In most cases, when I reply, I get 2 recipients. I always must delete 1. >> >> When the original mail comes from Mattias Gaertner, I *invariably* get 3 > reply addresses: >> >> to : Mattias Gaertner via Lazarus >> Cc : lazarus at lists.lazarus.freepascal.org, >> Mattias Gaertner >> >> I suspect that Mattias still uses the 'old' list address in his mails when >> posting, and that this is why I get 3 recipients. >> >> This is VERY annoying. >> >> (not the mails from Mattias, but the mailing list behaviour ;) ) > > If you go back some months it was revealed that this is now necessary due > to increased security in Gmail and Co. Otherwise mails from the list would > be bounced. Nonsense. Adding the CC is absolutely not necessary for this, only the from: line needs to be adapted. An MTA doesn't look at CC. Michael. From michael at freepascal.org Sun May 7 12:18:44 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Sun, 7 May 2017 12:18:44 +0200 (CEST) Subject: [Lazarus] Annoying lazarus mailing list behaviour In-Reply-To: References: Message-ID: On Sun, 7 May 2017, Sven Barth via Lazarus wrote: > Am 07.05.2017 12:11 schrieb "Michael Van Canneyt via Lazarus" < > lazarus at lists.lazarus-ide.org>: >> >> >> Hi, >> >> Can we please get rid of the Cc: being added to the mails sent through > the lazarus >> mailing list ? >> >> In most cases, when I reply, I get 2 recipients. I always must delete 1. >> >> When the original mail comes from Mattias Gaertner, I *invariably* get 3 > reply addresses: >> >> to : Mattias Gaertner via Lazarus >> Cc : lazarus at lists.lazarus.freepascal.org, >> Mattias Gaertner >> >> I suspect that Mattias still uses the 'old' list address in his mails when >> posting, and that this is why I get 3 recipients. >> >> This is VERY annoying. >> >> (not the mails from Mattias, but the mailing list behaviour ;) ) > > Addendum: what E-Mail client do you use? Both Android's GMail App and > Thunderbird (with Reply to List) handle it correctly. Pine. Michael. From kapibara.pas at aol.com Sun May 7 12:23:16 2017 From: kapibara.pas at aol.com (kapibara) Date: Sun, 7 May 2017 12:23:16 +0200 Subject: [Lazarus] TSQLQuery Scroll events Message-ID: <0191c5dc-28a1-4e3f-b505-9e3d8b8e1862@aol.com> I made a test app to unerstand more about TSQLQuery events. It requires SQLite and has one table with three records. 1) Why does the dataset scroll 6 times to open a query that has a resultset with three records? 2) Also, directly after opening the query, why is BeforeScroll/AfterScroll triggered when you click the first item in the DBLookupListBox? Shouldn't the dataset already be on that position and no scroll needed? Later, if you click an item twice, only the first time triggers a scroll event. 3) At query open, why does it scroll from record 1 an then immediately to record 3? (First and last record) and then to record 1 again, followed by 2, 3 and 3 again? Yes, why does it scroll from record 3 two times in a row? Toggle "Active Query" to true and immediately look at the Log window, line 4 and 5. 4) Editing and posting a name gives rise to 6 more scrolls. Explanations whats going on are highly welcome. -------------- next part -------------- A non-text attachment was scrubbed... Name: Scroll.png Type: image/png Size: 35058 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: scrollius.zip Type: application/zip Size: 3988 bytes Desc: not available URL: From michael at freepascal.org Sun May 7 12:30:02 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Sun, 7 May 2017 12:30:02 +0200 (CEST) Subject: [Lazarus] TSQLQuery Scroll events In-Reply-To: <0191c5dc-28a1-4e3f-b505-9e3d8b8e1862@aol.com> References: <0191c5dc-28a1-4e3f-b505-9e3d8b8e1862@aol.com> Message-ID: On Sun, 7 May 2017, kapibara via Lazarus wrote: > I made a test app to unerstand more about TSQLQuery events. It requires > SQLite and has one table with three records. > > 1) Why does the dataset scroll 6 times to open a query that has a resultset > with three records? > > 2) Also, directly after opening the query, why is BeforeScroll/AfterScroll > triggered when you click the first item in the DBLookupListBox? Shouldn't the > dataset already be on that position and no scroll needed? Later, if you click > an item twice, only the first time triggers a scroll event. > > 3) At query open, why does it scroll from record 1 an then immediately to > record 3? (First and last record) and then to record 1 again, followed by 2, > 3 and 3 again? Yes, why does it scroll from record 3 two times in a row? > Toggle "Active Query" to true and immediately look at the Log window, line 4 > and 5. > > 4) Editing and posting a name gives rise to 6 more scrolls. > > Explanations whats going on are highly welcome. Never use a GUI to understand dataset events. Because what you get is a mix of how TDataset behaves and how the DB aware controls behave. The DB aware controls do the most strange things imaginable in order to accomodate whatever their designer thought necessary. TDataset just reacts on the commands that the controls give. So, if you want to understand how TDataset events work, you should only use a command-line program, and issue a command (open, next, edit etc), and see how the TDataset reacts. Michael. From zeljko at holobit.net Sun May 7 13:08:35 2017 From: zeljko at holobit.net (zeljko) Date: Sun, 7 May 2017 13:08:35 +0200 Subject: [Lazarus] Menu editor unstable? In-Reply-To: References: Message-ID: <96ea6b61-02ff-d1c5-1bc4-5f01c85888e0@holobit.net> On 05/06/2017 09:26 PM, Michael Van Canneyt via Lazarus wrote: > > Hi, > > The menu editor of lazarus trunk seems highly unstable. > > I've had 10+ crashes of lazarus in the last 2 hours, all due to the menu > editor. > > The crash means that I get an access violation and I must actually kill > lazarus, because once I click away the access violation dialog, the > lazarus windows > redraw, but respond to no other messages. The only thing that helps is a > KILL signal. > > I have not exactly been able to reproduce reliably, but the following > just triggered > it: > - Start IDE > - Open project > - Select a popup menu (there are several) > - Double click to edit > - Select menu item 1 > - Immediatly select menu item 2. > -> crash. > > But also simply selecting something in the menu editor, and going to the > object > inspector can crash it. > > As a result I find myself saving all files before entering the menu editor. > Not exactly ideal, to say the least. > > Anyone else experiencing this ? > > Latest Lazarus from SVN. GTK2, linux 64-bit. Not here, but using Lazarus Qt 64-bit + fpc-3.0.2. zeljko From zeljko at holobit.net Sun May 7 13:12:50 2017 From: zeljko at holobit.net (zeljko) Date: Sun, 7 May 2017 13:12:50 +0200 Subject: [Lazarus] Form resize to standard size in IDE. In-Reply-To: References: Message-ID: <185806b9-149d-d111-952e-51d2930c72c2@holobit.net> On 05/07/2017 12:02 PM, Michael Van Canneyt via Lazarus wrote: > > Hi, > > Another oddity in the IDE designer. > > I have a form which contains some group boxes, radio buttons and a > buttonpanel. > Bordertstyle is bsDialog. No special properties regarding autosize or > whatsoever have been set. > > When I switch (using F12) between source and form, it *always* resizes to > some seemingly standard size and I need to fix the size. > > The form just contains the following: > Height = 279 > Top = 218 > Width = 443 > BorderStyle = bsDialog > Caption = 'Resize Selected elements' > ClientHeight = 279 > ClientWidth = 443 > Position = poOwnerFormCenter > LCLVersion = '1.9.0.0' > > I have attached it for reference. > > I suspect the scaling and high-dpi is at work here: I have a > dual-monitor system, with xinerama. > To test that hypothesis, I tried to set scaled to false, but it doesn't > help. > > Also: When the form designer is active, and I press save, the form is > marked 'dirty' > (i.e. not saved!) > > Anything I can do to help to diagnose the issue ? If you suspect on HiDPI then you should disable scaling at application level (lazaruside) via Application.Scaled := False (or similar prop name) . In that case TCustomForm.Scaled should not be taken into account in any case. Second thing: I assume that you're using Gtk2 ide. What is windowmanager ? Does it run compositing ? zeljko From michael at freepascal.org Sun May 7 13:12:43 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Sun, 7 May 2017 13:12:43 +0200 (CEST) Subject: [Lazarus] Menu editor unstable? - stack trace In-Reply-To: References: <20170507103651.15696d9d@limapholos.matflo.wg> Message-ID: On Sun, 7 May 2017, Michael Van Canneyt wrote: > > > On Sun, 7 May 2017, Mattias Gaertner via Lazarus wrote: > >> On Sat, 6 May 2017 21:26:38 +0200 (CEST) >> Michael Van Canneyt via Lazarus wrote: >> >>> [...] >>> I have not exactly been able to reproduce reliably, but the following just >>> triggered >>> it: >>> - Start IDE >>> - Open project >>> - Select a popup menu (there are several) >>> - Double click to edit >>> - Select menu item 1 >>> - Immediatly select menu item 2. >>> -> crash. >>> But also simply selecting something in the menu editor, and going to the >>> object >>> inspector can crash it. >>> >>> As a result I find myself saving all files before entering the menu >>> editor. >>> Not exactly ideal, to say the least. >>> >>> Anyone else experiencing this ? >>> >>> Latest Lazarus from SVN. GTK2, linux 64-bit. >> >> It does not crash here. So it needs something more to trigger the bug. >> Maybe the FPC Version? > > 3.0.2 > >> Stacktrace? > > I will try to get one. Here it is. When It happened, I had just selected a menu item, and wanted to change it's name in the object inspector (I think I was typing the first characters of the new name, not 100% sure on that). TObjectInspectorDlg.FillPersistentComboBox: Updating ComboBox with components TObjectInspectorDlg.FillPersistentComboBox: Updating ComboBox with components TObjectInspectorDlg.FillPersistentComboBox: Updating ComboBox with components TObjectInspectorDlg.FillPersistentComboBox: Updating ComboBox with components TObjectInspectorDlg.FillPersistentComboBox: Updating ComboBox with components Hint: (lazarus) TMainIDE.DesignerRenameComponent Old=MenuItem37:TMenuItem New=MIResize Owner=FPReportDesignerForm:TFPReportDesignerForm WARNING: TShadowItem.Destroy with LCLRefCount>0. Hint: Maybe the component is processing an event? TApplication.HandleException Access violation Stack trace: $0000000000000000 $00000000009FD49D line 1617 of ../designer/menueditor.pp $0000000000A02673 line 2590 of ../designer/menueditor.pp $00000000005B29F8 line 2242 of include/control.inc $00000000005B2E61 line 2375 of include/control.inc $0000000000436562 line 602 of ../inc/objpas.inc $00000000005B28FD line 2202 of include/control.inc $00000000005A580C line 5396 of include/wincontrol.inc $00000000007722AC line 112 of lclmessageglue.pas $000000000066C191 line 3702 of gtk2/gtk2proc.inc $000000000067AEC6 line 2137 of gtk2/gtk2callback.inc $000000000067A5C8 line 1899 of gtk2/gtk2callback.inc $00007F04FDB6EAFC The WARNING is a bit frightening... Looking at the stack trace, it looks like FShadowMenu in line 2590 of menueditor is Nil. Which seems to correspond with the warning ? After clicking Abort, I get then 2 more AVs: [TJITComponentList.DestroyJITComponent] ERROR destroying component Error: Access violation Stack trace: $00000000004E2AD4 line 790 of mainbase.pas $00000000004CD54F line 8978 of main.pp $000000000090B365 line 6331 of propedits.pp $00000000009D95C3 line 3008 of ../designer/designer.pp $00000000009D9DEB line 3165 of ../designer/designer.pp $000000000048529F line 288 of include/customform.inc $000000000053492E line 481 of ../objpas/classes/compon.inc $00000000006A4C15 line 131 of lclclasses.pp $00000000005B9D59 line 4991 of include/control.inc $00000000005A81B8 line 6601 of include/wincontrol.inc $00000000005BC54F line 54 of include/customcontrol.inc $000000000048394F line 316 of include/scrollingwincontrol.inc $0000000000484FF1 line 212 of include/customform.inc $0000000000435E81 line 288 of ../inc/objpas.inc $00000000009BE1AE line 777 of ../designer/jitforms.pp $00000000009BDEDB line 728 of ../designer/jitforms.pp $0000000000435E81 line 288 of ../inc/objpas.inc TCustomFormEditor.JITListException List.CurReadStreamClass=nil nil TApplication.HandleException: there was another exception during showing the first exception Stack trace: $0000000000690829 line 768 of laz_avl_tree.pp $00000000009E6B69 line 2086 of customformeditor.pp $00000000009E0CC1 line 815 of customformeditor.pp $00000000009E0C87 line 806 of customformeditor.pp $0000000000481346 line 2108 of forms.pp $00000000009D9575 line 2995 of ../designer/designer.pp $00000000009D9DEB line 3165 of ../designer/designer.pp $000000000048529F line 288 of include/customform.inc $000000000053492E line 481 of ../objpas/classes/compon.inc $000000000090D446 line 7112 of propedits.pp $0000000000435E81 line 288 of ../inc/objpas.inc $000000000049C913 line 870 of lclproc.pas $00000000004AD6C1 line 1662 of main.pp $0000000000435E81 line 288 of ../inc/objpas.inc $0000000000493A01 line 1093 of include/application.inc $0000000000480986 line 1904 of forms.pp $000000000043B623 line 972 of ../inc/system.inc lazarus.pp - unhandled exception And I need to kill lazarus with a -KILL signal. Luckily I saved my form just before it happened :) Michael. From robin.listas at telefonica.net Sun May 7 13:26:36 2017 From: robin.listas at telefonica.net (Carlos E. R.) Date: Sun, 7 May 2017 13:26:36 +0200 Subject: [Lazarus] Annoying lazarus mailing list behaviour In-Reply-To: References: Message-ID: <7dfe892d-2630-9b65-4e33-d59a0ecefc37@telefonica.net> On 2017-05-07 12:15, Sven Barth via Lazarus wrote: > Am 07.05.2017 12:11 schrieb "Michael Van Canneyt via Lazarus" > >: >> >> >> Hi, >> >> Can we please get rid of the Cc: being added to the mails sent through the lazarus >> mailing list ? ... It doesn't bother me much, I can filter it out (with procmail). In fact, as the "from" is changed, I see the CC as a way to be able to send a personal mail if needed. >> This is VERY annoying. >> >> (not the mails from Mattias, but the mailing list behaviour ;) ) > > If you go back some months it was revealed that this is now necessary > due to increased security in Gmail and Co. Otherwise mails from the list > would be bounced. I subscribe to several mail lists, and I have not seen any problem with gmail. :-? -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From robin.listas at telefonica.net Sun May 7 13:45:45 2017 From: robin.listas at telefonica.net (Carlos E. R.) Date: Sun, 7 May 2017 13:45:45 +0200 Subject: [Lazarus] Annoying lazarus mailing list behaviour In-Reply-To: References: Message-ID: <34c9b3fc-c580-e56f-0758-c43774eff645@telefonica.net> On 2017-05-07 12:18, Michael Van Canneyt via Lazarus wrote: > On Sun, 7 May 2017, Sven Barth via Lazarus wrote: >> Addendum: what E-Mail client do you use? Both Android's GMail App and >> Thunderbird (with Reply to List) handle it correctly. > > Pine. With Pine I get: To: somebody via lazarus Hitting Reply, not to all. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From michael at freepascal.org Sun May 7 14:24:36 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Sun, 7 May 2017 14:24:36 +0200 (CEST) Subject: [Lazarus] Form resize to standard size in IDE. In-Reply-To: <185806b9-149d-d111-952e-51d2930c72c2@holobit.net> References: <185806b9-149d-d111-952e-51d2930c72c2@holobit.net> Message-ID: On Sun, 7 May 2017, zeljko wrote: > On 05/07/2017 12:02 PM, Michael Van Canneyt via Lazarus wrote: >> >> Hi, >> >> Another oddity in the IDE designer. >> >> I have a form which contains some group boxes, radio buttons and a >> buttonpanel. >> Bordertstyle is bsDialog. No special properties regarding autosize or >> whatsoever have been set. >> >> When I switch (using F12) between source and form, it *always* resizes to >> some seemingly standard size and I need to fix the size. >> >> The form just contains the following: >> Height = 279 >> Top = 218 >> Width = 443 >> BorderStyle = bsDialog >> Caption = 'Resize Selected elements' >> ClientHeight = 279 >> ClientWidth = 443 >> Position = poOwnerFormCenter >> LCLVersion = '1.9.0.0' >> >> I have attached it for reference. >> >> I suspect the scaling and high-dpi is at work here: I have a >> dual-monitor system, with xinerama. >> To test that hypothesis, I tried to set scaled to false, but it doesn't >> help. >> >> Also: When the form designer is active, and I press save, the form is >> marked 'dirty' >> (i.e. not saved!) >> >> Anything I can do to help to diagnose the issue ? > > If you suspect on HiDPI then you should disable scaling at application level > (lazaruside) via Application.Scaled := False (or similar prop name) . In that > case TCustomForm.Scaled should not be taken into account in any case. Is there a command-line option for the IDE to disable this ? It seems silly to me that I would have to modify the IDE sources every time I do a SVN update? > Second thing: I assume that you're using Gtk2 ide. What is windowmanager ? > Does it run compositing ? I don't know. I use a standard Linux Mint using Cinnamon desktop. Michael. From mailinglists at geldenhuys.co.uk Sun May 7 14:56:43 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Sun, 7 May 2017 13:56:43 +0100 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <20170505131733.0f67e9df@limapholos.matflo.wg> <30f45e1e-91d2-be4d-7555-3281c40a0f16@geldenhuys.co.uk> <3e65aa41-34ed-fe7a-ac62-94aa46986dae@geldenhuys.co.uk> Message-ID: <6bf3fa92-0650-b539-c5ba-4a18fc37f496@geldenhuys.co.uk> On 2017-05-07 11:17, Florian Klaempfl via Lazarus wrote: > Then something is wrong/broken :) I rest my case. :-P Regards, Graeme From michael at freepascal.org Sun May 7 15:15:29 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Sun, 7 May 2017 15:15:29 +0200 (CEST) Subject: [Lazarus] RTTI grid with multiple objects ? Message-ID: Hello, How to make the RTTI property grid display the properties of a set of TComponents ? Currently I have: (MyGrid is the property grid) Var I : integer; L : TPersistentSelectionList; begin C:=0; L:=MyGrid.Selection; L.BeginUpdate; try L.Clear; if Not Assigned(ObjectList) then exit; For I:=0 to ObjectList.Count-1 do if ObjectList[i].Selected then L.Add(ObjectList[i]); finally L.EndUpdate; Mygrid.RefreshPropertyValues; end; end; But the grid remains empty, even though I know multiple objects have been attached. I tried various things, but the grid remains empty. What should I do so the grid actually shows something ? Michael. From Sascha.Hestermann at gmx.de Sun May 7 15:44:39 2017 From: Sascha.Hestermann at gmx.de (Gabor Boros) Date: Sun, 7 May 2017 17:44:39 +0400 Subject: [Lazarus] =?utf-8?q?how_about_that=3F?= Message-ID: <1229649775.20170507164439@gmx.de> Hi! There is an amazing place I wanted to go with you to, how about that? Take a look at it http://public.fuzzydragons.net Faithfully, Gabor Boros Sent from Mail for Windows 10 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1607EE1AC27C76F916BD5D756D3488CF.jpg Type: image/jpeg Size: 18211 bytes Desc: not available URL: From Sascha.Hestermann at gmx.de Sun May 7 15:44:52 2017 From: Sascha.Hestermann at gmx.de (John Landmesser) Date: Sun, 7 May 2017 08:44:52 -0500 Subject: [Lazarus] =?utf-8?b?4pivcHVyZSBqb3k=?= Message-ID: <1210140766.20170507164452@gmx.de> Hi friend! I wanted to share with you my joy about my latest event, please read more here http://ladon.ferdiworks.mobi Hope this helps, John Landmesser From nc-gaertnma at netcologne.de Sun May 7 17:13:12 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Sun, 7 May 2017 17:13:12 +0200 Subject: [Lazarus] Annoying lazarus mailing list behaviour In-Reply-To: References: Message-ID: <20170507171312.42b31159@limapholos.matflo.wg> On Sun, 7 May 2017 12:11:13 +0200 (CEST) Michael Van Canneyt via Lazarus wrote: >[...] > I suspect that Mattias still uses the 'old' list address in his mails when > posting, and that this is why I get 3 recipients. Sorry. I fixed my setting. Mattias From nc-gaertnma at netcologne.de Sun May 7 17:22:03 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Sun, 7 May 2017 17:22:03 +0200 Subject: [Lazarus] RTTI grid with multiple objects ? In-Reply-To: References: Message-ID: <20170507172203.6b203be8@limapholos.matflo.wg> On Sun, 7 May 2017 15:15:29 +0200 (CEST) Michael Van Canneyt via Lazarus wrote: > Hello, > > How to make the RTTI property grid display the properties of a set of > TComponents ? > > Currently I have: (MyGrid is the property grid) > > Var > I : integer; > L : TPersistentSelectionList; > > begin > C:=0; > L:=MyGrid.Selection; > L.BeginUpdate; > try > L.Clear; > if Not Assigned(ObjectList) then > exit; > For I:=0 to ObjectList.Count-1 do > if ObjectList[i].Selected then > L.Add(ObjectList[i]); > finally > L.EndUpdate; > Mygrid.RefreshPropertyValues; RefreshPropertyValues is for updating the grid, when only property values have changed. When the list have changed use MyGrid.ReloadTIList. Mattias > end; > end; > > But the grid remains empty, even though I know multiple objects have been > attached. I tried various things, but the grid remains empty. > > What should I do so the grid actually shows something ? > > Michael. > > > From zeljko at holobit.net Sun May 7 17:40:41 2017 From: zeljko at holobit.net (zeljko) Date: Sun, 7 May 2017 17:40:41 +0200 Subject: [Lazarus] Form resize to standard size in IDE. In-Reply-To: References: <185806b9-149d-d111-952e-51d2930c72c2@holobit.net> Message-ID: <27e373f9-2d3e-99b3-8c41-b534500fa73f@holobit.net> On 05/07/2017 02:24 PM, Michael Van Canneyt wrote: > > > On Sun, 7 May 2017, zeljko wrote: > >> On 05/07/2017 12:02 PM, Michael Van Canneyt via Lazarus wrote: >>> >>> Hi, >>> >>> Another oddity in the IDE designer. >>> >>> I have a form which contains some group boxes, radio buttons and a >>> buttonpanel. >>> Bordertstyle is bsDialog. No special properties regarding autosize or >>> whatsoever have been set. >>> >>> When I switch (using F12) between source and form, it *always* >>> resizes to >>> some seemingly standard size and I need to fix the size. >>> >>> The form just contains the following: >>> Height = 279 >>> Top = 218 >>> Width = 443 >>> BorderStyle = bsDialog >>> Caption = 'Resize Selected elements' >>> ClientHeight = 279 >>> ClientWidth = 443 >>> Position = poOwnerFormCenter >>> LCLVersion = '1.9.0.0' >>> >>> I have attached it for reference. >>> >>> I suspect the scaling and high-dpi is at work here: I have a >>> dual-monitor system, with xinerama. >>> To test that hypothesis, I tried to set scaled to false, but it doesn't >>> help. >>> >>> Also: When the form designer is active, and I press save, the form is >>> marked 'dirty' >>> (i.e. not saved!) >>> >>> Anything I can do to help to diagnose the issue ? >> >> If you suspect on HiDPI then you should disable scaling at application >> level (lazaruside) via Application.Scaled := False (or similar prop >> name) . In that case TCustomForm.Scaled should not be taken into >> account in any case. > > Is there a command-line option for the IDE to disable this ? It seems > silly to me that I would have to modify the IDE sources every time I do > a SVN update? AFAIK not. > >> Second thing: I assume that you're using Gtk2 ide. What is >> windowmanager ? Does it run compositing ? > > I don't know. I use a standard Linux Mint using Cinnamon desktop. Then compositing is on, and that's probably cause of problems. zeljko From pascaldragon at googlemail.com Sun May 7 17:59:58 2017 From: pascaldragon at googlemail.com (Sven Barth) Date: Sun, 7 May 2017 17:59:58 +0200 Subject: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority) In-Reply-To: References: <90543ea2-3115-7a12-c260-f24558c6e58b@windstream.net> <2df233e2-7a77-8da9-d044-07bcaceaa831@geldenhuys.co.uk> <2c17e11f-9890-a7b4-6b71-194c6c8252c5@geldenhuys.co.uk> <20170505011547.0ff3f5bb@limapholos.matflo.wg> <20170505131733.0f67e9df@limapholos.matflo.wg> <30f45e1e-91d2-be4d-7555-3281c40a0f16@geldenhuys.co.uk> <3e65aa41-34ed-fe7a-ac62-94aa46986dae@geldenhuys.co.uk> Message-ID: On 07.05.2017 12:17, Florian Klaempfl via Lazarus wrote: > Am 07.05.2017 um 12:11 schrieb Sven Barth via Lazarus: >> Am 07.05.2017 12:07 schrieb "Florian Klaempfl via Lazarus" >> >: >>> >>> Am 07.05.2017 um 11:57 schrieb Graeme Geldenhuys via Lazarus: >>>> On 2017-05-07 09:10, Florian Klaempfl via Lazarus wrote: >>>>>> Yeah, that would be the logical thing to do. >>>>> >>>>> Why? What makes a string literal UTF-8? >>>>> >>>> >>>> As Mattias said, the fact that the source unit is UTF-8 encoded. >>>> Defined by a BOM marker, or -Fcutf8 or {$codepage utf8}. If the source >>>> unit is UTF-8 encoded, the literal string constant can't (and >>>> shouldn't) be in any other encoding. >>>> >>>> I would say the same if the source unit was stored in UTF-16 >>>> encoding. Then string literals would be treated as UTF-16. >>> >>> And if a ISO/Ansi codepage is given? Things would probably fail. >>> >>> The point is: FPC is consistent in this regard: also sources with a >>> given iso/ansi codepage are handled the same way. If there is a string >>> literal with non-ascii chars, it is converted to UTF-16 using the >>> codepage of the source. Very simple, very logical. It is a matter of >>> preference if UTF-8, -16, -32 are chosen at this point, but FPC uses >>> UTF-16. If it uses UTF-8, the problem would occur the other way around. >>> >>> If no codepage is given (by directive, command line, BOM), string >>> literals are handled byte-wise as raw strings. >> >> Small correction: FPC only does this conversion if the codepage is >> UTF-8, no other. > > Then something is wrong/broken :) > Well, the code in tscannerfile.readtoken() only does the conversion to UTF-16 if the source codepage is UTF-8, otherwise it only converts to UTF-16 if the string is already an UTF-16 string. So probably not broken as it seems rather on purpose; if at all it's wrong... Regards, Sven From michael at freepascal.org Sun May 7 18:21:48 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Sun, 7 May 2017 18:21:48 +0200 (CEST) Subject: [Lazarus] RTTI grid with multiple objects ? In-Reply-To: <20170507172203.6b203be8@limapholos.matflo.wg> References: <20170507172203.6b203be8@limapholos.matflo.wg> Message-ID: On Sun, 7 May 2017, Mattias Gaertner via Lazarus wrote: > On Sun, 7 May 2017 15:15:29 +0200 (CEST) > Michael Van Canneyt via Lazarus wrote: > >> Hello, >> >> How to make the RTTI property grid display the properties of a set of >> TComponents ? >> >> Currently I have: (MyGrid is the property grid) >> >> Var >> I : integer; >> L : TPersistentSelectionList; >> >> begin >> C:=0; >> L:=MyGrid.Selection; >> L.BeginUpdate; >> try >> L.Clear; >> if Not Assigned(ObjectList) then >> exit; >> For I:=0 to ObjectList.Count-1 do >> if ObjectList[i].Selected then >> L.Add(ObjectList[i]); >> finally >> L.EndUpdate; >> Mygrid.RefreshPropertyValues; > > RefreshPropertyValues is for updating the grid, when only property > values have changed. > When the list have changed use MyGrid.ReloadTIList. fraobjectinspector.pp(197,14) Error: identifier idents no member "ReloadTIList" instead I tried Mygrid.BuildPropertyList(False); That seems to work ? Michael. From michael at freepascal.org Sun May 7 18:24:53 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Sun, 7 May 2017 18:24:53 +0200 (CEST) Subject: [Lazarus] Form resize to standard size in IDE. In-Reply-To: <27e373f9-2d3e-99b3-8c41-b534500fa73f@holobit.net> References: <185806b9-149d-d111-952e-51d2930c72c2@holobit.net> <27e373f9-2d3e-99b3-8c41-b534500fa73f@holobit.net> Message-ID: On Sun, 7 May 2017, zeljko wrote: >>> >>> If you suspect on HiDPI then you should disable scaling at application >>> level (lazaruside) via Application.Scaled := False (or similar prop >>> name) . In that case TCustomForm.Scaled should not be taken into >>> account in any case. >> >> Is there a command-line option for the IDE to disable this ? It seems >> silly to me that I would have to modify the IDE sources every time I do >> a SVN update? > > AFAIK not. > >> >>> Second thing: I assume that you're using Gtk2 ide. What is >>> windowmanager ? Does it run compositing ? >> >> I don't know. I use a standard Linux Mint using Cinnamon desktop. > > Then compositing is on, and that's probably cause of problems. Can you explain why this would cause problems ? Because I see many more straneg things happening. At runtime my StatusBar disappears for some mysterious reason. I need to resize the form and then it appears again. And it doesn't matter whether I allow scaling or not. Michael. From victor.campillo at gmail.com Sun May 7 19:18:23 2017 From: victor.campillo at gmail.com (Victor Campillo) Date: Sun, 7 May 2017 19:18:23 +0200 Subject: [Lazarus] Menu editor unstable? In-Reply-To: <96ea6b61-02ff-d1c5-1bc4-5f01c85888e0@holobit.net> References: <96ea6b61-02ff-d1c5-1bc4-5f01c85888e0@holobit.net> Message-ID: <2100f5df-14f5-89b7-0d71-7c235f1210c2@gmail.com> On 07/05/17 13:08, zeljko via Lazarus wrote: > Not here, but using Lazarus Qt 64-bit + fpc-3.0.2. > Hi, I can't reproduce it here either, using latest Lazarus GTK2, linux 64-bit, FPC 3.0.2 -- Victor Campillo From zeljko at holobit.net Sun May 7 19:40:38 2017 From: zeljko at holobit.net (zeljko) Date: Sun, 7 May 2017 19:40:38 +0200 Subject: [Lazarus] Form resize to standard size in IDE. In-Reply-To: References: <185806b9-149d-d111-952e-51d2930c72c2@holobit.net> <27e373f9-2d3e-99b3-8c41-b534500fa73f@holobit.net> Message-ID: On 05/07/2017 06:24 PM, Michael Van Canneyt wrote: > > > On Sun, 7 May 2017, zeljko wrote: > >>>> >>>> If you suspect on HiDPI then you should disable scaling at application >>>> level (lazaruside) via Application.Scaled := False (or similar prop >>>> name) . In that case TCustomForm.Scaled should not be taken into >>>> account in any case. >>> >>> Is there a command-line option for the IDE to disable this ? It seems >>> silly to me that I would have to modify the IDE sources every time I do >>> a SVN update? >> >> AFAIK not. >> >>> >>>> Second thing: I assume that you're using Gtk2 ide. What is >>>> windowmanager ? Does it run compositing ? >>> >>> I don't know. I use a standard Linux Mint using Cinnamon desktop. >> >> Then compositing is on, and that's probably cause of problems. > > Can you explain why this would cause problems ? Don't know, tried to fix that inside gtk2 many times, besides that on some wm's + compositing sizes are ok, on some not. Really don't know. Using qtlcl for work and don't have such problems. See gtk2wsforms.pp and stuff about form events ... zeljko From fluisgirardi at gmail.com Sun May 7 20:35:46 2017 From: fluisgirardi at gmail.com (Fabio Luis Girardi) Date: Sun, 7 May 2017 15:35:46 -0300 Subject: [Lazarus] Form resize to standard size in IDE. In-Reply-To: References: <185806b9-149d-d111-952e-51d2930c72c2@holobit.net> <27e373f9-2d3e-99b3-8c41-b534500fa73f@holobit.net> Message-ID: I (and others co-workers) have experienced the same behavior on Linux mint cinnamon 17.3 when Lazarus is built using gtk2 (using Lazarus 1.4, 1.6, fixes and trunk). This strange behavior disappeared when Lazarus is built with QT. The cinnamon looking glass can provide some debug information about this. I'll try reproduce this tomorrow, to collect the cinnamon debug info. Em 7 de mai de 2017 14:40, "zeljko via Lazarus" < lazarus at lists.lazarus-ide.org> escreveu: > On 05/07/2017 06:24 PM, Michael Van Canneyt wrote: > >> >> >> On Sun, 7 May 2017, zeljko wrote: >> >> >>>>> If you suspect on HiDPI then you should disable scaling at application >>>>> level (lazaruside) via Application.Scaled := False (or similar prop >>>>> name) . In that case TCustomForm.Scaled should not be taken into >>>>> account in any case. >>>>> >>>> >>>> Is there a command-line option for the IDE to disable this ? It seems >>>> silly to me that I would have to modify the IDE sources every time I do >>>> a SVN update? >>>> >>> >>> AFAIK not. >>> >>> >>>> Second thing: I assume that you're using Gtk2 ide. What is >>>>> windowmanager ? Does it run compositing ? >>>>> >>>> >>>> I don't know. I use a standard Linux Mint using Cinnamon desktop. >>>> >>> >>> Then compositing is on, and that's probably cause of problems. >>> >> >> Can you explain why this would cause problems ? >> > > Don't know, tried to fix that inside gtk2 many times, besides that on some > wm's + compositing sizes are ok, on some not. Really don't know. > Using qtlcl for work and don't have such problems. See gtk2wsforms.pp and > stuff about form events ... > > zeljko > > -- > _______________________________________________ > 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 juha.manninen62 at gmail.com Sun May 7 23:45:44 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Mon, 8 May 2017 00:45:44 +0300 Subject: [Lazarus] Form resize to standard size in IDE. In-Reply-To: References: <185806b9-149d-d111-952e-51d2930c72c2@holobit.net> <27e373f9-2d3e-99b3-8c41-b534500fa73f@holobit.net> Message-ID: On Sun, May 7, 2017 at 9:35 PM, Fabio Luis Girardi via Lazarus wrote: > I (and others co-workers) have experienced the same behavior on Linux mint > cinnamon 17.3 when Lazarus is built using gtk2 (using Lazarus 1.4, 1.6, > fixes and trunk). I have seen similar reports but no common cause was found. Now it starts to look like a Cinnamon related issue. Somebody should debug it there. Juha From juha.manninen62 at gmail.com Mon May 8 00:29:59 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Mon, 8 May 2017 01:29:59 +0300 Subject: [Lazarus] Menu editor unstable? - stack trace In-Reply-To: References: <20170507103651.15696d9d@limapholos.matflo.wg> Message-ID: Can you please create a proper backtrace with gdb using the latest Lazarus trunk. It shows also function names and parameter values etc. I was actually able to reproduce the access violation once but not more however much I tried. Juha From badsectoracula at gmail.com Mon May 8 03:52:47 2017 From: badsectoracula at gmail.com (Kostas Michalopoulos) Date: Mon, 8 May 2017 04:52:47 +0300 Subject: [Lazarus] Form resize to standard size in IDE. In-Reply-To: References: <185806b9-149d-d111-952e-51d2930c72c2@holobit.net> <27e373f9-2d3e-99b3-8c41-b534500fa73f@holobit.net> Message-ID: Maybe it is also related to the problem i mentioned a few days ago? It does sound kind of similar to what i demo in the video here: https://webmshare.com/q78rb On Mon, May 8, 2017 at 12:45 AM, Juha Manninen via Lazarus < lazarus at lists.lazarus-ide.org> wrote: > On Sun, May 7, 2017 at 9:35 PM, Fabio Luis Girardi via Lazarus > wrote: > > I (and others co-workers) have experienced the same behavior on Linux > mint > > cinnamon 17.3 when Lazarus is built using gtk2 (using Lazarus 1.4, 1.6, > > fixes and trunk). > > I have seen similar reports but no common cause was found. > Now it starts to look like a Cinnamon related issue. Somebody should > debug it there. > > Juha > -- > _______________________________________________ > 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 noreply at z505.com Mon May 8 05:36:54 2017 From: noreply at z505.com (noreply at z505.com) Date: Sun, 07 May 2017 22:36:54 -0500 Subject: [Lazarus] Quick Video: A Web Application In-Reply-To: References: <48574413-7f52-ea91-439b-b1f868c92891@geldenhuys.co.uk> Message-ID: Sorry, didn't watch the video yet, but, wasn't Morfik something similar? Or that was mostly offline apps? Then there was also the intraweb for delphi, but AFAIR the Indy authors. From noreply at z505.com Mon May 8 05:39:39 2017 From: noreply at z505.com (noreply at z505.com) Date: Sun, 07 May 2017 22:39:39 -0500 Subject: [Lazarus] Quick Video: A Web Application In-Reply-To: <77565008-1bdc-30a1-7851-020538063002@geldenhuys.co.uk> References: <48574413-7f52-ea91-439b-b1f868c92891@geldenhuys.co.uk> <77565008-1bdc-30a1-7851-020538063002@geldenhuys.co.uk> Message-ID: <0dc60651c29e801192028af1d2922e5e@z505.com> On 2017-04-19 10:21, Graeme Geldenhuys via Lazarus wrote: > On 2017-04-19 15:58, Michael Schnell via Lazarus wrote: >> Lazarus would b able to seamlessly create such programs (even more up >> to >> date, versatile and fast: using WebAssembly compiled from Pascal >> instead >> of hand crafted Java Script). > > > I believe that is what Michael van Canneyt is working on. > I am also working on something like this for chromium embedded Offline Apps (with callbacks that can call native fpc code using html5/js widgets as the GUI), but, as I have many programs on the go, and many ideas, and not sure if it will be open source... I don't want to blow the whistle early. FastCGI would be a good mechanism for events, since it keeps a exe/elf open all the time rather than forking a new one for each event. But fastcgi doesn't run on that many servers. From michael at freepascal.org Mon May 8 09:42:51 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 8 May 2017 09:42:51 +0200 (CEST) Subject: [Lazarus] Form resize to standard size in IDE. In-Reply-To: References: <185806b9-149d-d111-952e-51d2930c72c2@holobit.net> <27e373f9-2d3e-99b3-8c41-b534500fa73f@holobit.net> Message-ID: On Mon, 8 May 2017, Kostas Michalopoulos via Lazarus wrote: > Maybe it is also related to the problem i mentioned a few days ago? It does > sound kind of similar to what i demo in the video here: > > https://webmshare.com/q78rb It certainly looks like it. Michael. > > > > On Mon, May 8, 2017 at 12:45 AM, Juha Manninen via Lazarus < > lazarus at lists.lazarus-ide.org> wrote: > >> On Sun, May 7, 2017 at 9:35 PM, Fabio Luis Girardi via Lazarus >> wrote: >>> I (and others co-workers) have experienced the same behavior on Linux >> mint >>> cinnamon 17.3 when Lazarus is built using gtk2 (using Lazarus 1.4, 1.6, >>> fixes and trunk). >> >> I have seen similar reports but no common cause was found. >> Now it starts to look like a Cinnamon related issue. Somebody should >> debug it there. >> >> Juha >> -- >> _______________________________________________ >> Lazarus mailing list >> Lazarus at lists.lazarus-ide.org >> http://lists.lazarus-ide.org/listinfo/lazarus >> > From fluisgirardi at gmail.com Mon May 8 12:01:05 2017 From: fluisgirardi at gmail.com (Fabio Luis Girardi) Date: Mon, 8 May 2017 07:01:05 -0300 Subject: [Lazarus] Form resize to standard size in IDE. In-Reply-To: References: <185806b9-149d-d111-952e-51d2930c72c2@holobit.net> <27e373f9-2d3e-99b3-8c41-b534500fa73f@holobit.net> Message-ID: Em 8 de mai de 2017 04:43, "Michael Van Canneyt via Lazarus" < lazarus at lists.lazarus-ide.org> escreveu: On Mon, 8 May 2017, Kostas Michalopoulos via Lazarus wrote: Maybe it is also related to the problem i mentioned a few days ago? It does > sound kind of similar to what i demo in the video here: > > https://webmshare.com/q78rb > It certainly looks like it. Maybe, but on Mint cinnamon, one time that the form is resized to default size, it's not resized anymore. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at freepascal.org Mon May 8 12:08:41 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 8 May 2017 12:08:41 +0200 (CEST) Subject: [Lazarus] Form resize to standard size in IDE. In-Reply-To: References: <185806b9-149d-d111-952e-51d2930c72c2@holobit.net> <27e373f9-2d3e-99b3-8c41-b534500fa73f@holobit.net> Message-ID: On Mon, 8 May 2017, Fabio Luis Girardi via Lazarus wrote: > Em 8 de mai de 2017 04:43, "Michael Van Canneyt via Lazarus" < > lazarus at lists.lazarus-ide.org> escreveu: > > > > On Mon, 8 May 2017, Kostas Michalopoulos via Lazarus wrote: > > Maybe it is also related to the problem i mentioned a few days ago? It does >> sound kind of similar to what i demo in the video here: >> >> https://webmshare.com/q78rb >> > > It certainly looks like it. > > > Maybe, but on Mint cinnamon, one time that the form is resized to default > size, it's not resized anymore. I have been experimenting, and the 'default' size depends on what controls are present in the form and what their sizes are. So that definitely smells of the lazarus LCL layouting algorithms... Michael. From michael at freepascal.org Mon May 8 14:59:57 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 8 May 2017 14:59:57 +0200 (CEST) Subject: [Lazarus] Menu editor unstable? - stack trace In-Reply-To: References: <20170507103651.15696d9d@limapholos.matflo.wg> Message-ID: On Mon, 8 May 2017, Juha Manninen via Lazarus wrote: > Can you please create a proper backtrace with gdb using the latest > Lazarus trunk. > It shows also function names and parameter values etc. > > I was actually able to reproduce the access violation once but not > more however much I tried. The stack trace I posted earlier for this issue will have to do. It's simply *impossible* to debug lazarus using GDB. I get exceptions from the code tools *ALL THE TIME* because it is timer triggered. because of this, the working process becomes simply impossible. And so, every *$ç§1@#!!! stacktrace looks like this: #1 0x0000000000c4dcf0 in RAISEEXCEPTIONINSTANCE (this=0x7fffdbad3390, THEEXCEPTION=0x7fffdb508a40, CLEARNICEPOS=true) at customcodetool.pas:2439 #2 0x0000000000c4dd67 in RAISEEXCEPTIONCLASS (this=0x7fffdbad3390, ID=20170421200105, AMESSAGE=0x7fffe0128698 'identifier not found: Name', EXCEPTIONCLASS=0x2225010, CLEARNICEPOS=true) at customcodetool.pas:2450 #3 0x0000000000c47dc0 in RAISEEXCEPTION (this=0x7fffdbad3390, ID=20170421200105, AMESSAGE=0x7fffe0128698 'identifier not found: Name', CLEARNICEPOS=true) at customcodetool.pas:399 #4 0x0000000000c47e62 in RAISEEXCEPTIONFMT (this=0x7fffdbad3390, ID=20170421200105, AMESSAGE=0x1a6e038 'identifier not found: %s', ARGS=..., highARGS=0, CLEARNICEPOS=true) at customcodetool.pas:405 #5 0x0000000000861726 in RAISENOTFOUND (parentfp=0x7fffffffcf50) at finddeclarationtool.pas:4071 #6 0x000000000086159e in CHECKRESULT (parentfp=0x7fffffffcfe0, NEWRESULT=false, CALLONIDENTIFIERFOUND=false) at finddeclarationtool.pas:4177 #7 0x000000000085fd3d in FINDIDENTIFIERINCONTEXT (this=0x7fffdbad3390, PARAMS=0x7fffe927b4e0, IDENTFOUNDRESULT=(unknown: 3685561232)) at finddeclarationtool.pas:4998 #8 0x0000000000867d05 in FINDIDENTIFIERINCONTEXT (this=0x7fffdbad3390, PARAMS=0x7fffe927b4e0) at finddeclarationtool.pas:7163 #9 0x00000000008595f7 in FINDDECLARATION (this=0x7fffdbad3390, CURSORPOS=..., SEARCHSMARTFLAGS=4, NEWEXPRTYPE=..., NEWPOS=..., NEWTOPLINE=-610849184) at finddeclarationtool.pas:2409 #10 0x0000000000859f54 in FINDDECLARATION (this=0x7fffdbad3390, CURSORPOS=..., SEARCHSMARTFLAGS=4, NEWTOOL=0x7fffdbad3390, NEWNODE=0x7fffdb972e60, NEWPOS=..., NEWTOPLINE=-610849184) at finddeclarationtool.pas:2468 #11 0x00000000009b6c13 in GETHTMLHINTFOREXPR (this=0x7fffe9787540, CTEXPRTYPE=..., XYPOS=..., OPTIONS=0, BASEURL=0x1a98e20 'lazdoc://', HTMLHINT=0x0, CACHEWASUSED=false) at codehelp.pas:2601 #12 0x00000000009b6267 in GETHTMLHINT (this=0x7fffe9787540, CODE=0x7fffe82367e0, X=14, Y=1872, OPTIONS=0, BASEURL=0x1a98e20 'lazdoc://', HTMLHINT=0x0, PROPDETAILS=0x0, CACHEWASUSED=false) at codehelp.pas:2469 #13 0x00000000004d96a6 in OICHANGEDTIMERTIMER (this=0x7ffff7f99550, SENDER=0x7fffe80448c0) at main.pp:12191 #14 0x0000000000752b94 in DOONTIMER (this=0x7fffe80448c0) at customtimer.pas:175 #15 0x0000000000752ae5 in TIMER (this=0x7fffe80448c0) at customtimer.pas:150 This error is obviously bogus, since the compiler processes the program fine. So the original stack trace which I posted should suffice to diagnose the problem: ObjectInspectorDlg.FillPersistentComboBox: Updating ComboBox with components TObjectInspectorDlg.FillPersistentComboBox: Updating ComboBox with components TObjectInspectorDlg.FillPersistentComboBox: Updating ComboBox with components TObjectInspectorDlg.FillPersistentComboBox: Updating ComboBox with components TObjectInspectorDlg.FillPersistentComboBox: Updating ComboBox with components Hint: (lazarus) TMainIDE.DesignerRenameComponent Old=MenuItem37:TMenuItem New=MIResize Owner=FPReportDesignerForm:TFPReportDesignerForm WARNING: TShadowItem.Destroy with LCLRefCount>0. Hint: Maybe the component is processing an event? TApplication.HandleException Access violation Stack trace: $0000000000000000 $00000000009FD49D line 1617 of ../designer/menueditor.pp $0000000000A02673 line 2590 of ../designer/menueditor.pp $00000000005B29F8 line 2242 of include/control.inc $00000000005B2E61 line 2375 of include/control.inc $0000000000436562 line 602 of ../inc/objpas.inc $00000000005B28FD line 2202 of include/control.inc $00000000005A580C line 5396 of include/wincontrol.inc $00000000007722AC line 112 of lclmessageglue.pas $000000000066C191 line 3702 of gtk2/gtk2proc.inc $000000000067AEC6 line 2137 of gtk2/gtk2callback.inc $000000000067A5C8 line 1899 of gtk2/gtk2callback.inc $00007F04FDB6EAFC The 2 following lines should tell you everything you need, IMHO: $00000000009FD49D line 1617 of ../designer/menueditor.pp $0000000000A02673 line 2590 of ../designer/menueditor.pp The GDB stack trace will give you little more useful information. Michael. From michael at freepascal.org Mon May 8 15:09:31 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 8 May 2017 15:09:31 +0200 (CEST) Subject: [Lazarus] Menu editor unstable? - stack trace In-Reply-To: References: <20170507103651.15696d9d@limapholos.matflo.wg> Message-ID: y On Mon, 8 May 2017, Michael Van Canneyt via Lazarus wrote: > > > On Mon, 8 May 2017, Juha Manninen via Lazarus wrote: > >> Can you please create a proper backtrace with gdb using the latest >> Lazarus trunk. >> It shows also function names and parameter values etc. >> >> I was actually able to reproduce the access violation once but not >> more however much I tried. > > The stack trace I posted earlier for this issue will have to do. > > It's simply *impossible* to debug lazarus using GDB. As always, you get an idea after sending a mail saying you don't find it... :/ I managed to produce a stacktrace. Hopefully this, combined with the stacktrace at the end is sufficient to solve the issue. Michael. (gdb) cont Continuing. WARNING: TShadowItem.Destroy with LCLRefCount>0. Hint: Maybe the component is processing an event? Thread 1 "lazarus" received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () #1 0x00000000009fd6f2 in SETSELECTEDSHADOW (this=0x7fffe02077b0, PREVSELECTEDITEM=0x7fffe37107c0, CURSELECTEDITEM=0x7fffe03c1e80, VIADESIGNER=false) at ../designer/menueditor.pp:1663 #2 0x00000000009fd49d in SETSELECTEDMENUITEM (this=0x7fffe02077b0, AMI=0x7fffe03c1e80, VIADESIGNER=false, PREVWASDELETED=false) at ../designer/menueditor.pp:1617 #3 0x0000000000a02673 in MOUSEDOWN (this=0x7fffe9371e10, BUTTON=MBLEFT, SHIFT=8, X=73, Y=8) at ../designer/menueditor.pp:2590 #4 0x00000000005b29f8 in DOMOUSEDOWN (this=0x7fffe9371e10, MESSAGE=..., BUTTON=MBLEFT, SHIFT=0) at include/control.inc:2242 #5 0x00000000005b2e61 in WMLBUTTONDOWN (this=0x7fffe9371e10, MESSAGE=...) at include/control.inc:2375 #6 0x0000000000436562 in DISPATCH (this=0x7fffe9371e10, MESSAGE=0) at ../inc/objpas.inc:602 #7 0x00000000005b28fd in WNDPROC (this=0x7fffe9371e10, THEMESSAGE=...) at include/control.inc:2202 #8 0x00000000005a580c in WNDPROC (this=0x7fffe9371e10, MESSAGE=...) at include/wincontrol.inc:5396 #9 0x00000000007722ac in DELIVERMESSAGE (TARGET=0x7fffe9371e10, AMESSAGE=0) at lclmessageglue.pas:112 #10 0x000000000066c191 in DELIVERMESSAGE (TARGET=0x7fffe9371e10, AMESSAGE=0) at gtk2/gtk2proc.inc:3702 #11 0x000000000067aec6 in DELIVERMOUSEDOWNMESSAGE (WIDGET=0x3aced90, EVENT=0x3624ea0, AWINCONTROL=0x7fffe9371e10) at gtk2/gtk2callback.inc:2137 #12 0x000000000067a5c8 in GTKMOUSEBTNPRESS (WIDGET=0x32d2b80, EVENT=0x3624ea0, DATA=0x7fffe9371e10) at gtk2/gtk2callback.inc:1899 #13 0x00007ffff6c8cafc in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #14 0x00007ffff6916fa5 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #15 0x00007ffff6928fc1 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #16 0x00007ffff69317f9 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #17 0x00007ffff693208f in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #18 0x00007ffff6da48cc in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #19 0x00007ffff6c8b294 in gtk_propagate_event () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #20 0x00007ffff6c8b64b in gtk_main_do_event () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #21 0x00007ffff775bc4c in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 #22 0x00007ffff6640197 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #23 0x00007ffff66403f0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #24 0x00007ffff664049c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #25 0x00000000004fc6ec in APPPROCESSMESSAGES (this=0x7ffff7f75230) at gtk2/gtk2widgetset.inc:2338 #26 0x000000000049435d in HANDLEMESSAGE (this=0x7ffff7f74bf0) at include/application.inc:1276 #27 0x00000000004948ac in RUNLOOP (this=0x7ffff7f74bf0) at include/application.inc:1413 #28 0x00000000006585a6 in APPRUN (this=0x7ffff7f75230, ALOOP=...) at include/interfacebase.inc:54 #29 0x0000000000494850 in RUN (this=0x7ffff7f74bf0) at include/application.inc:1401 #30 0x0000000000420127 in main () at lazarus.pp:145 (gdb) cont Continuing. TApplication.HandleException Access violation Stack trace: $0000000000000000 $00000000009FD49D line 1617 of ../designer/menueditor.pp $0000000000A02673 line 2590 of ../designer/menueditor.pp $00000000005B29F8 line 2242 of include/control.inc $00000000005B2E61 line 2375 of include/control.inc $0000000000436562 line 602 of ../inc/objpas.inc $00000000005B28FD line 2202 of include/control.inc $00000000005A580C line 5396 of include/wincontrol.inc $00000000007722AC line 112 of lclmessageglue.pas $000000000066C191 line 3702 of gtk2/gtk2proc.inc $000000000067AEC6 line 2137 of gtk2/gtk2callback.inc $000000000067A5C8 line 1899 of gtk2/gtk2callback.inc $00007FFFF6C8CAFC From zeljko at holobit.net Mon May 8 15:16:39 2017 From: zeljko at holobit.net (zeljko) Date: Mon, 8 May 2017 15:16:39 +0200 Subject: [Lazarus] Form resize to standard size in IDE. In-Reply-To: References: <185806b9-149d-d111-952e-51d2930c72c2@holobit.net> <27e373f9-2d3e-99b3-8c41-b534500fa73f@holobit.net> Message-ID: <74ed64bf-ec48-da0c-8c00-09232ad36629@holobit.net> On 08.05.2017 12:08, Michael Van Canneyt via Lazarus wrote: > > > On Mon, 8 May 2017, Fabio Luis Girardi via Lazarus wrote: > >> Em 8 de mai de 2017 04:43, "Michael Van Canneyt via Lazarus" < >> lazarus at lists.lazarus-ide.org> escreveu: >> >> >> >> On Mon, 8 May 2017, Kostas Michalopoulos via Lazarus wrote: >> >> Maybe it is also related to the problem i mentioned a few days ago? It >> does >>> sound kind of similar to what i demo in the video here: >>> >>> https://webmshare.com/q78rb >>> >> >> It certainly looks like it. >> >> >> Maybe, but on Mint cinnamon, one time that the form is resized to default >> size, it's not resized anymore. > > I have been experimenting, and the 'default' size depends on what controls > are present in the form and what their sizes are. So that definitely > smells of the lazarus LCL layouting algorithms... Probably gtk2 sends some garbled size messages. I cannot reproduce such thing with qtlcl (tried under windowmaker too, as it is mentioned in link) zeljko From m-w-vogel at gmx.de Mon May 8 15:20:36 2017 From: m-w-vogel at gmx.de (Michael W. Vogel) Date: Mon, 8 May 2017 15:20:36 +0200 Subject: [Lazarus] Menu editor unstable? - stack trace In-Reply-To: References: <20170507103651.15696d9d@limapholos.matflo.wg> Message-ID: Am 08.05.2017 um 15:09 schrieb Michael Van Canneyt via Lazarus: > I managed to produce a stacktrace. Hopefully this, combined with the > stacktrace > at the end is sufficient to solve the issue. > > Michael. > > (gdb) cont > Continuing. > WARNING: TShadowItem.Destroy with LCLRefCount>0. Hint: Maybe the > component is processing an event? > Thread 1 "lazarus" received signal SIGSEGV, Segmentation fault. > 0x0000000000000000 in ?? () > (gdb) bt > #0 0x0000000000000000 in ?? () > #1 0x00000000009fd6f2 in SETSELECTEDSHADOW (this=0x7fffe02077b0, > PREVSELECTEDITEM=0x7fffe37107c0, CURSELECTEDITEM=0x7fffe03c1e80, > VIADESIGNER=false) > at ../designer/menueditor.pp:1663 > #2 0x00000000009fd49d in SETSELECTEDMENUITEM (this=0x7fffe02077b0, > AMI=0x7fffe03c1e80, VIADESIGNER=false, PREVWASDELETED=false) > at ../designer/menueditor.pp:1617 > #3 0x0000000000a02673 in MOUSEDOWN (this=0x7fffe9371e10, > BUTTON=MBLEFT, SHIFT=8, X=73, Y=8) at ../designer/menueditor.pp:2590 > #4 0x00000000005b29f8 in DOMOUSEDOWN (this=0x7fffe9371e10, > MESSAGE=..., BUTTON=MBLEFT, SHIFT=0) at include/control.inc:2242 > #5 0x00000000005b2e61 in WMLBUTTONDOWN (this=0x7fffe9371e10, > MESSAGE=...) at include/control.inc:2375 > #6 0x0000000000436562 in DISPATCH (this=0x7fffe9371e10, MESSAGE=0) at > ../inc/objpas.inc:602 > #7 0x00000000005b28fd in WNDPROC (this=0x7fffe9371e10, > THEMESSAGE=...) at include/control.inc:2202 > #8 0x00000000005a580c in WNDPROC (this=0x7fffe9371e10, MESSAGE=...) > at include/wincontrol.inc:5396 > #9 0x00000000007722ac in DELIVERMESSAGE (TARGET=0x7fffe9371e10, > AMESSAGE=0) at lclmessageglue.pas:112 > #10 0x000000000066c191 in DELIVERMESSAGE (TARGET=0x7fffe9371e10, > AMESSAGE=0) at gtk2/gtk2proc.inc:3702 > #11 0x000000000067aec6 in DELIVERMOUSEDOWNMESSAGE (WIDGET=0x3aced90, > EVENT=0x3624ea0, AWINCONTROL=0x7fffe9371e10) at > gtk2/gtk2callback.inc:2137 > #12 0x000000000067a5c8 in GTKMOUSEBTNPRESS (WIDGET=0x32d2b80, > EVENT=0x3624ea0, DATA=0x7fffe9371e10) at gtk2/gtk2callback.inc:1899 > #13 0x00007ffff6c8cafc in ?? () from > /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 > #14 0x00007ffff6916fa5 in g_closure_invoke () from > /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #15 0x00007ffff6928fc1 in ?? () from > /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #16 0x00007ffff69317f9 in g_signal_emit_valist () from > /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #17 0x00007ffff693208f in g_signal_emit () from > /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #18 0x00007ffff6da48cc in ?? () from > /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 > #19 0x00007ffff6c8b294 in gtk_propagate_event () from > /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 > #20 0x00007ffff6c8b64b in gtk_main_do_event () from > /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 > #21 0x00007ffff775bc4c in ?? () from > /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 > #22 0x00007ffff6640197 in g_main_context_dispatch () from > /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #23 0x00007ffff66403f0 in ?? () from > /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #24 0x00007ffff664049c in g_main_context_iteration () from > /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #25 0x00000000004fc6ec in APPPROCESSMESSAGES (this=0x7ffff7f75230) at > gtk2/gtk2widgetset.inc:2338 > #26 0x000000000049435d in HANDLEMESSAGE (this=0x7ffff7f74bf0) at > include/application.inc:1276 > #27 0x00000000004948ac in RUNLOOP (this=0x7ffff7f74bf0) at > include/application.inc:1413 > #28 0x00000000006585a6 in APPRUN (this=0x7ffff7f75230, ALOOP=...) at > include/interfacebase.inc:54 > #29 0x0000000000494850 in RUN (this=0x7ffff7f74bf0) at > include/application.inc:1401 > #30 0x0000000000420127 in main () at lazarus.pp:145 > (gdb) cont > Continuing. > TApplication.HandleException Access violation > Stack trace: > $0000000000000000 > $00000000009FD49D line 1617 of ../designer/menueditor.pp > $0000000000A02673 line 2590 of ../designer/menueditor.pp > $00000000005B29F8 line 2242 of include/control.inc > $00000000005B2E61 line 2375 of include/control.inc > $0000000000436562 line 602 of ../inc/objpas.inc > $00000000005B28FD line 2202 of include/control.inc > $00000000005A580C line 5396 of include/wincontrol.inc > $00000000007722AC line 112 of lclmessageglue.pas > $000000000066C191 line 3702 of gtk2/gtk2proc.inc > $000000000067AEC6 line 2137 of gtk2/gtk2callback.inc > $000000000067A5C8 line 1899 of gtk2/gtk2callback.inc > $00007FFFF6C8CAFC As I've made some bug fixes for the Menueditor last time, I tried to reproduce this error. Till now I wasn't able to reproduce it on Lazarus Trunk revision 54826 with FPC 3.0.2 on Windows 7, 10, OpenSuse 42.2 KDE GTK2 or Linux Mint 17.3 KDE GTK2. I currently install on a VM a 64bit Linux Mint 18.1 Cinnamon (your OS?!), to test the issue there. I'll report. Michl From mailinglists at geldenhuys.co.uk Mon May 8 15:36:30 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 8 May 2017 14:36:30 +0100 Subject: [Lazarus] TColorButton gives errors in console output Message-ID: <9e027148-c7e3-0175-3acb-33a97b48a6ad@geldenhuys.co.uk> Hi, I have a form with many TColorButton widgets (defined in LCL's Dialog unit). Whenever I load that form, I see tons of errors as follows in the console window. ================================ $000000000071B5C5 line 729 of lazloggerbase.pas $0000000000800975 line 5554 of gtk2/gtk2winapi.inc $0000000000765B8B line 485 of include/winapi.inc $00000000007506A1 line 261 of include/brush.inc $0000000000750494 line 210 of include/brush.inc $0000000000755878 line 181 of include/canvas.inc $0000000000759E09 line 1718 of include/canvas.inc $0000000000758A60 line 1162 of include/canvas.inc $0000000000758AC2 line 1175 of include/canvas.inc ERROR: [TGtk2WidgetSet.GetSysColorBrush] Bad Value: 32. Valid Range between 0 and 31 ================================ I presume this should not happen, and is a bug in LCL-GTK2? Regards, Graeme From michael at freepascal.org Mon May 8 15:51:11 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 8 May 2017 15:51:11 +0200 (CEST) Subject: [Lazarus] Form resize to standard size in IDE. In-Reply-To: <74ed64bf-ec48-da0c-8c00-09232ad36629@holobit.net> References: <185806b9-149d-d111-952e-51d2930c72c2@holobit.net> <27e373f9-2d3e-99b3-8c41-b534500fa73f@holobit.net> <74ed64bf-ec48-da0c-8c00-09232ad36629@holobit.net> Message-ID: On Mon, 8 May 2017, zeljko wrote: > On 08.05.2017 12:08, Michael Van Canneyt via Lazarus wrote: >> >> >> On Mon, 8 May 2017, Fabio Luis Girardi via Lazarus wrote: >> >>> Em 8 de mai de 2017 04:43, "Michael Van Canneyt via Lazarus" < >>> lazarus at lists.lazarus-ide.org> escreveu: >>> >>> >>> >>> On Mon, 8 May 2017, Kostas Michalopoulos via Lazarus wrote: >>> >>> Maybe it is also related to the problem i mentioned a few days ago? It >>> does >>>> sound kind of similar to what i demo in the video here: >>>> >>>> https://webmshare.com/q78rb >>>> >>> >>> It certainly looks like it. >>> >>> >>> Maybe, but on Mint cinnamon, one time that the form is resized to default >>> size, it's not resized anymore. >> >> I have been experimenting, and the 'default' size depends on what controls >> are present in the form and what their sizes are. So that definitely >> smells of the lazarus LCL layouting algorithms... > > Probably gtk2 sends some garbled size messages. I cannot reproduce such thing > with qtlcl (tried under windowmaker too, as it is mentioned in link) How can I investigate this ? Where can/should I put some writelns to see what is happening ? I don't mind helping out, but I need some pointers where to start. Michael. From michael at freepascal.org Mon May 8 15:54:17 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 8 May 2017 15:54:17 +0200 (CEST) Subject: [Lazarus] Menu editor unstable? - stack trace In-Reply-To: References: <20170507103651.15696d9d@limapholos.matflo.wg> Message-ID: On Mon, 8 May 2017, Michael W. Vogel via Lazarus wrote: > Am 08.05.2017 um 15:09 schrieb Michael Van Canneyt via Lazarus: >> I managed to produce a stacktrace. Hopefully this, combined with the >> stacktrace >> at the end is sufficient to solve the issue. >> >> Michael. >> >> (gdb) cont >> Continuing. >> WARNING: TShadowItem.Destroy with LCLRefCount>0. Hint: Maybe the >> component is processing an event? >> Thread 1 "lazarus" received signal SIGSEGV, Segmentation fault. >> 0x0000000000000000 in ?? () >> (gdb) bt >> #0 0x0000000000000000 in ?? () >> #1 0x00000000009fd6f2 in SETSELECTEDSHADOW (this=0x7fffe02077b0, >> PREVSELECTEDITEM=0x7fffe37107c0, CURSELECTEDITEM=0x7fffe03c1e80, >> VIADESIGNER=false) >> at ../designer/menueditor.pp:1663 >> #2 0x00000000009fd49d in SETSELECTEDMENUITEM (this=0x7fffe02077b0, >> AMI=0x7fffe03c1e80, VIADESIGNER=false, PREVWASDELETED=false) >> at ../designer/menueditor.pp:1617 >> #3 0x0000000000a02673 in MOUSEDOWN (this=0x7fffe9371e10, >> BUTTON=MBLEFT, SHIFT=8, X=73, Y=8) at ../designer/menueditor.pp:2590 >> #4 0x00000000005b29f8 in DOMOUSEDOWN (this=0x7fffe9371e10, >> MESSAGE=..., BUTTON=MBLEFT, SHIFT=0) at include/control.inc:2242 >> #5 0x00000000005b2e61 in WMLBUTTONDOWN (this=0x7fffe9371e10, >> MESSAGE=...) at include/control.inc:2375 >> #6 0x0000000000436562 in DISPATCH (this=0x7fffe9371e10, MESSAGE=0) at >> ../inc/objpas.inc:602 >> #7 0x00000000005b28fd in WNDPROC (this=0x7fffe9371e10, >> THEMESSAGE=...) at include/control.inc:2202 >> #8 0x00000000005a580c in WNDPROC (this=0x7fffe9371e10, MESSAGE=...) >> at include/wincontrol.inc:5396 >> #9 0x00000000007722ac in DELIVERMESSAGE (TARGET=0x7fffe9371e10, >> AMESSAGE=0) at lclmessageglue.pas:112 >> #10 0x000000000066c191 in DELIVERMESSAGE (TARGET=0x7fffe9371e10, >> AMESSAGE=0) at gtk2/gtk2proc.inc:3702 >> #11 0x000000000067aec6 in DELIVERMOUSEDOWNMESSAGE (WIDGET=0x3aced90, >> EVENT=0x3624ea0, AWINCONTROL=0x7fffe9371e10) at >> gtk2/gtk2callback.inc:2137 >> #12 0x000000000067a5c8 in GTKMOUSEBTNPRESS (WIDGET=0x32d2b80, >> EVENT=0x3624ea0, DATA=0x7fffe9371e10) at gtk2/gtk2callback.inc:1899 >> #13 0x00007ffff6c8cafc in ?? () from >> /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 >> #14 0x00007ffff6916fa5 in g_closure_invoke () from >> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 >> #15 0x00007ffff6928fc1 in ?? () from >> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 >> #16 0x00007ffff69317f9 in g_signal_emit_valist () from >> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 >> #17 0x00007ffff693208f in g_signal_emit () from >> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 >> #18 0x00007ffff6da48cc in ?? () from >> /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 >> #19 0x00007ffff6c8b294 in gtk_propagate_event () from >> /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 >> #20 0x00007ffff6c8b64b in gtk_main_do_event () from >> /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 >> #21 0x00007ffff775bc4c in ?? () from >> /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 >> #22 0x00007ffff6640197 in g_main_context_dispatch () from >> /lib/x86_64-linux-gnu/libglib-2.0.so.0 >> #23 0x00007ffff66403f0 in ?? () from >> /lib/x86_64-linux-gnu/libglib-2.0.so.0 >> #24 0x00007ffff664049c in g_main_context_iteration () from >> /lib/x86_64-linux-gnu/libglib-2.0.so.0 >> #25 0x00000000004fc6ec in APPPROCESSMESSAGES (this=0x7ffff7f75230) at >> gtk2/gtk2widgetset.inc:2338 >> #26 0x000000000049435d in HANDLEMESSAGE (this=0x7ffff7f74bf0) at >> include/application.inc:1276 >> #27 0x00000000004948ac in RUNLOOP (this=0x7ffff7f74bf0) at >> include/application.inc:1413 >> #28 0x00000000006585a6 in APPRUN (this=0x7ffff7f75230, ALOOP=...) at >> include/interfacebase.inc:54 >> #29 0x0000000000494850 in RUN (this=0x7ffff7f74bf0) at >> include/application.inc:1401 >> #30 0x0000000000420127 in main () at lazarus.pp:145 >> (gdb) cont >> Continuing. >> TApplication.HandleException Access violation >> Stack trace: >> $0000000000000000 >> $00000000009FD49D line 1617 of ../designer/menueditor.pp >> $0000000000A02673 line 2590 of ../designer/menueditor.pp >> $00000000005B29F8 line 2242 of include/control.inc >> $00000000005B2E61 line 2375 of include/control.inc >> $0000000000436562 line 602 of ../inc/objpas.inc >> $00000000005B28FD line 2202 of include/control.inc >> $00000000005A580C line 5396 of include/wincontrol.inc >> $00000000007722AC line 112 of lclmessageglue.pas >> $000000000066C191 line 3702 of gtk2/gtk2proc.inc >> $000000000067AEC6 line 2137 of gtk2/gtk2callback.inc >> $000000000067A5C8 line 1899 of gtk2/gtk2callback.inc >> $00007FFFF6C8CAFC > > As I've made some bug fixes for the Menueditor last time, I tried to > reproduce this error. Till now I wasn't able to reproduce it on Lazarus > Trunk revision 54826 with FPC 3.0.2 on Windows 7, 10, OpenSuse 42.2 KDE > GTK2 or Linux Mint 17.3 KDE GTK2. I currently install on a VM a 64bit > Linux Mint 18.1 Cinnamon (your OS?!), to test the issue there. OK. It seems clear to me that something is being freed which should not yet be freed: >> WARNING: TShadowItem.Destroy with LCLRefCount>0. Hint: Maybe the >> component is processing an event? This indicates to me that an unforeseen order of events is happening ? As far as I know, there is a global call to free components once the message processing is finished ? Well, I hope you can reproduce it... Michael. From michael at freepascal.org Mon May 8 17:42:11 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 8 May 2017 17:42:11 +0200 (CEST) Subject: [Lazarus] intercepting keyboard events Message-ID: Hi, How can I respond to keyboard events in a TCustomControl (and hence TWinControl) descendent ? I have asigned the various OnKey* events handlers but they are not called. My control also does not seem to receive focus when clicked, I assume this is why it doesn't get keyboard events either ? Is there something that must be called/set when creating the control to make it receive focus ? Michael. From lazarus at kluug.net Mon May 8 18:22:30 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Mon, 8 May 2017 18:22:30 +0200 Subject: [Lazarus] intercepting keyboard events In-Reply-To: References: Message-ID: On 08.05.2017 17:42, Michael Van Canneyt via Lazarus wrote: > Is there something that must be called/set when creating the control > to make > it receive focus ? If you mean receiving focus by clicking on it then yes, you need to call SetFocus in MouseDown. It's also a good idea to check the csNoFocus flag (from ControlStyle property). For an example look how it is done in TCustomDBGrid.MouseDown. + The control can always get focused by the Tab key, if TabStop=True. Ondrej From zeljko at holobit.net Mon May 8 18:43:58 2017 From: zeljko at holobit.net (zeljko) Date: Mon, 8 May 2017 18:43:58 +0200 Subject: [Lazarus] Form resize to standard size in IDE. In-Reply-To: References: <27e373f9-2d3e-99b3-8c41-b534500fa73f@holobit.net> <74ed64bf-ec48-da0c-8c00-09232ad36629@holobit.net> Message-ID: On 08.05.2017 15:51, Michael Van Canneyt wrote: > > How can I investigate this ? Where can/should I put some writelns to see > what is happening ? > > I don't mind helping out, but I need some pointers where to start. Gtk2WSForms.pp , line 168 see my comment about it. Seem that it's your problem (my comment is about Mint16 WM + compositing). Can you see if your wm name fits into if (Copy(Gtk2WidgetSet.GetWindowManager,1,6) = 'mutter') then ... Just put writeln('WM=',Gtk2WidgetSet.GetWindowManager) above that statement. zeljko From zeljko at holobit.net Mon May 8 18:46:37 2017 From: zeljko at holobit.net (zeljko) Date: Mon, 8 May 2017 18:46:37 +0200 Subject: [Lazarus] intercepting keyboard events In-Reply-To: References: Message-ID: On 08.05.2017 17:42, Michael Van Canneyt via Lazarus wrote: > > Hi, > > How can I respond to keyboard events in a TCustomControl (and hence > TWinControl) descendent ? > > I have asigned the various OnKey* events handlers but they are not called. > > My control also does not seem to receive focus when clicked, I assume > this is why > it doesn't get keyboard events either ? Yep > > Is there something that must be called/set when creating the control to > make > it receive focus ? Just to be sure that control actually can take focus put this ControlStyle := ControlStyle - [csNoFocus]; into constructor of your control. z. From zeljko at holobit.net Mon May 8 18:47:51 2017 From: zeljko at holobit.net (zeljko) Date: Mon, 8 May 2017 18:47:51 +0200 Subject: [Lazarus] TColorButton gives errors in console output In-Reply-To: <9e027148-c7e3-0175-3acb-33a97b48a6ad@geldenhuys.co.uk> References: <9e027148-c7e3-0175-3acb-33a97b48a6ad@geldenhuys.co.uk> Message-ID: On 08.05.2017 15:36, Graeme Geldenhuys via Lazarus wrote: > Hi, > > I have a form with many TColorButton widgets (defined in LCL's Dialog > unit). Whenever I load that form, I see tons of errors as follows in > the console window. > > > ================================ > $000000000071B5C5 line 729 of lazloggerbase.pas > $0000000000800975 line 5554 of gtk2/gtk2winapi.inc > $0000000000765B8B line 485 of include/winapi.inc > $00000000007506A1 line 261 of include/brush.inc > $0000000000750494 line 210 of include/brush.inc > $0000000000755878 line 181 of include/canvas.inc > $0000000000759E09 line 1718 of include/canvas.inc > $0000000000758A60 line 1162 of include/canvas.inc > $0000000000758AC2 line 1175 of include/canvas.inc > ERROR: [TGtk2WidgetSet.GetSysColorBrush] Bad Value: 32. Valid Range between 0 and 31 > ================================ > > I presume this should not happen, and is a bug in LCL-GTK2? Obviously it's bug (if TColorButton calls SysColorBrush with invalid range). z. From aaa5500 at ya.ru Mon May 8 19:35:48 2017 From: aaa5500 at ya.ru (Alexey) Date: Mon, 8 May 2017 20:35:48 +0300 Subject: [Lazarus] TColorButton gives errors in console output In-Reply-To: References: <9e027148-c7e3-0175-3acb-33a97b48a6ad@geldenhuys.co.uk> Message-ID: <7054af61-e6b2-e7da-c86b-64f2a51e81e7@ya.ru> >> I presume this should not happen, and is a bug in LCL-GTK2? Can you post somewhere small proj? I made proj with one btn, I don't see this error. -- Regards, Alexey -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at geldenhuys.co.uk Mon May 8 20:31:08 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 8 May 2017 19:31:08 +0100 Subject: [Lazarus] TColorButton gives errors in console output In-Reply-To: <7054af61-e6b2-e7da-c86b-64f2a51e81e7@ya.ru> References: <9e027148-c7e3-0175-3acb-33a97b48a6ad@geldenhuys.co.uk> <7054af61-e6b2-e7da-c86b-64f2a51e81e7@ya.ru> Message-ID: On 2017-05-08 18:35, Alexey via Lazarus wrote: >>> I presume this should not happen, and is a bug in LCL-GTK2? > Can you post somewhere small proj? I made proj with one btn, I don't see > this error. The usage is in part of a large form and project, but I'll see what I can do of course. I'll post it in Mantis with a bug report. Regards, Graeme From m-w-vogel at gmx.de Mon May 8 20:43:05 2017 From: m-w-vogel at gmx.de (Michael W. Vogel) Date: Mon, 8 May 2017 20:43:05 +0200 Subject: [Lazarus] Menu editor unstable? - stack trace In-Reply-To: References: <20170507103651.15696d9d@limapholos.matflo.wg> Message-ID: <303b5b80-d9c6-c3d4-fd9d-402bec4aca07@gmx.de> Am 08.05.2017 um 15:54 schrieb Michael Van Canneyt via Lazarus: > > OK. It seems clear to me that something is being freed which should > not yet be > freed: > >>> WARNING: TShadowItem.Destroy with LCLRefCount>0. Hint: Maybe the >>> component is processing an event? > > This indicates to me that an unforeseen order of events is happening ? > As far as I know, there is a global call to free components once the > message processing is finished ? > > Well, I hope you can reproduce it... Sorry, I don't get it. After over two hours of testing with 64bit Linux Mint 18.1 Cinnamon and Lazarus 1.9.0 r54833M FPC 3.0.2 x86_64-linux-gtk2, with new or saved projects, without or with AnchorDockingDsgn / Sparta_DockedFormEditor, I'm not able to create a crash. I tried this steps and around: - Open project - Select a popup menu (there are several) - Double click to edit - Select menu item 1 - Immediatly select menu item 2 If you want, you can add a minimal example and explain every single step again, what you do, to create a crash. Then, I'll test again, but for now, I don't know what to do more. What Lazarus revision are you using? Do you have installed AnchorDockingDsgn, Sparta_DockedFormEditor or something similar? Kind regards Michl From michael at freepascal.org Mon May 8 22:50:34 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 8 May 2017 22:50:34 +0200 (CEST) Subject: [Lazarus] Menu editor unstable? - stack trace In-Reply-To: <303b5b80-d9c6-c3d4-fd9d-402bec4aca07@gmx.de> References: <20170507103651.15696d9d@limapholos.matflo.wg> <303b5b80-d9c6-c3d4-fd9d-402bec4aca07@gmx.de> Message-ID: On Mon, 8 May 2017, Michael W. Vogel via Lazarus wrote: > Am 08.05.2017 um 15:54 schrieb Michael Van Canneyt via Lazarus: >> >> OK. It seems clear to me that something is being freed which should >> not yet be >> freed: >> >>>> WARNING: TShadowItem.Destroy with LCLRefCount>0. Hint: Maybe the >>>> component is processing an event? >> >> This indicates to me that an unforeseen order of events is happening ? >> As far as I know, there is a global call to free components once the >> message processing is finished ? >> >> Well, I hope you can reproduce it... > > Sorry, I don't get it. After over two hours of testing with 64bit Linux > Mint 18.1 Cinnamon and Lazarus 1.9.0 r54833M FPC 3.0.2 > x86_64-linux-gtk2, with new or saved projects, without or with > AnchorDockingDsgn / Sparta_DockedFormEditor, I'm not able to create a > crash. > > I tried this steps and around: > - Open project > - Select a popup menu (there are several) > - Double click to edit > - Select menu item 1 > - Immediatly select menu item 2 Here, the crash happens when going to the object inspector. > > > If you want, you can add a minimal example and explain every single step > again, what you do, to create a crash. Then, I'll test again, but for > now, I don't know what to do more. I will try. I do use actions. > What Lazarus revision are you using? > Do you have installed AnchorDockingDsgn, Sparta_DockedFormEditor or > something similar? No, no docking whatsoever. Michael. From bartjunk64 at gmail.com Mon May 8 23:34:56 2017 From: bartjunk64 at gmail.com (Bart) Date: Mon, 8 May 2017 23:34:56 +0200 Subject: [Lazarus] Call for translations updates for 1.8 release In-Reply-To: <2ccacec0-7797-c4d5-0fb2-7f9341672d07@narod.ru> References: <2ccacec0-7797-c4d5-0fb2-7f9341672d07@narod.ru> Message-ID: On 4/18/17, Maxim Ganetsky via Lazarus wrote: > Now that Lazarus 1.8 branch has been created it is time for translators > to review and update their translations. Is there an official translator for the Dutch language files? The state of the dutch translation is rather poor. I started to make some improvements, but it's a rather daunting task. All the more because for me programming is tied to the English language and translating "keywords" like property, event, message etc. just sounds a bit silly to me. Also the dutch language is much more verbose than the english one. I also have seen many resourcestrings I have never encountered in the wild, so I do not know their context. Bart From benjamin at rosseaux.de Tue May 9 04:38:07 2017 From: benjamin at rosseaux.de (Benjamin Rosseaux) Date: Tue, 9 May 2017 04:38:07 +0200 Subject: [Lazarus] Vulkan Library for FreePascal/Lazarus In-Reply-To: References: Message-ID: PasVulkan seems to be have better Platform Support (incl. Support for Wayland, Mir, Android, MoltenVK, etc.) and more Vulkan Utils stuff, like texture loaders for DDS, KTX, PNG, TGA, etc. and a own working memory manager for manage the Vulkan memory (the reason for it, see slide 20 on http://32ipi028l5q82yhj72224m8j.wpengine.netdna-cdn.com/wp-content/uploads/2016/05/Most-common-mistakes-in-Vulkan-apps.pdf with the slide sub-title "PROBLEMATIC AREAS: MEMORY MANAGEMENT" ). The Vulkan memory management stuff is in very many Vulkan code examples and Vulkan frameworks on the web often totally wrong, that there will be often worked without sub-allocations and that the maxMemoryAllocationCount limit is often ignored by the most Vulkan code examples and Vulkan frameworks on the web. In contrast to it, PasVulkan is here in this point fully Vulkan specification compliant. On Thu, Apr 13, 2017 at 6:34 PM, Michalis Kamburelis via Lazarus < lazarus at lists.lazarus-ide.org> wrote: > a2017-04-13 11:30 GMT+02:00 Kostas Michalopoulos via Lazarus > : > > This is nice, although personally i do not like the use of multiple inc > > files. I think Benjamin Rosseaux's pasvulkan does it better with > creating a > > single pas file (he also uses a unit from the vk.xml file): > > > > https://github.com/BeRo1985/pasvulkan/blob/master/src/Vulkan.pas > > > > > > > > On Thu, Apr 13, 2017 at 7:32 AM, James.mcjohnson via Lazarus > > wrote: > >> > >> This is both an announcement and request for help for an open source > >> FreePascal project which strives to provide: > >> 1) a low level access to Vulkan API created directly from the vk.xml > >> specification > >> 2) high level wrapper classes for ease of integration in an FP/Lazarus > >> project > >> > >> The project is located at > >> https://github.com/james-mcjohnson/VulkanLibraryForFreePascal and I > would > >> appreciate any constructive feedback. > >> > >> It is my hope that a better programmer than I am will take an interest > and > >> help create a truly useful Vulkan Library for FreePascal. > >> > > I want to add Vulkan renderer to Castle Game Engine later this year. > Now I don't know which project to choose:) Both approaches > (https://github.com/james-mcjohnson/VulkanLibraryForFreePascal and > https://github.com/BeRo1985/pasvulkan ) seem very fine to me, > > - in both cases you generate the Pascal code automatically from vk.xml, > - in both cases you provide a nicely-looking OOP API, > - both projects have suitable open-source licenses (MIT or zlib). > > I don't mind a couple of include files, they actually include > readability for me. (I know, it's a matter of taste -- do you prefer > to navigate multiple smaller files, or navigate one big file.) > > @James, would you mind removing the "Public Service Announcement" from > https://github.com/james-mcjohnson/VulkanLibraryForFreePascal/ > blob/master/LICENSE.md > ? Don't get me wrong, I understand that you want to promote your faith > and I respect that. Having this in README files, and Pascal sources, > is absolutely OK. But I'm not a lawyer, and I'm unsure how it affects > the legal text of the license. Having just an "unmodified MIT license" > would feel safer for me. > > Regards, > Michalis > -- > _______________________________________________ > 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 michael at freepascal.org Tue May 9 15:15:18 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Tue, 9 May 2017 15:15:18 +0200 (CEST) Subject: [Lazarus] Menu editor unstable? - stack trace In-Reply-To: References: <20170507103651.15696d9d@limapholos.matflo.wg> <303b5b80-d9c6-c3d4-fd9d-402bec4aca07@gmx.de> Message-ID: >> - Open project >> - Select a popup menu (there are several) >> - Double click to edit >> - Select menu item 1 >> - Immediatly select menu item 2 > > Here, the crash happens when going to the object inspector. > >> >> >> If you want, you can add a minimal example and explain every single step >> again, what you do, to create a crash. Then, I'll test again, but for >> now, I don't know what to do more. > > I will try. I do use actions. > >> What Lazarus revision are you using? >> Do you have installed AnchorDockingDsgn, Sparta_DockedFormEditor or >> something similar? Hi, I manage to reliably reproduce it ! 1 Open attached project. 2 Double click MainMenu1 to edit 3 Under MenuItem5, delete MenuItem14,13,12,11 (I use the - button in the menu editor) 4 The last menu item under MenuItem5 is then 'Action3' 5 Add new menu item (I click 'add menu item' below the Action3 item) 6 Click on Action 3 7 Click on the newly added (in step 5) MenuItem11 --->> BOOM Never fails. The delete step 3 is important. Without that, I don't get a crash. I then tested deleting a single item instead of 4 items as described above, then I also get a crash. So as soon as a delete is performed - boom... Michael. From michael at freepascal.org Tue May 9 15:15:53 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Tue, 9 May 2017 15:15:53 +0200 (CEST) Subject: [Lazarus] Menu editor unstable? - stack trace In-Reply-To: References: <20170507103651.15696d9d@limapholos.matflo.wg> <303b5b80-d9c6-c3d4-fd9d-402bec4aca07@gmx.de> Message-ID: Forgot attachment :( Michael. On Tue, 9 May 2017, Michael Van Canneyt via Lazarus wrote: > > >>> - Open project >>> - Select a popup menu (there are several) >>> - Double click to edit >>> - Select menu item 1 >>> - Immediatly select menu item 2 >> >> Here, the crash happens when going to the object inspector. >> >>> >>> >>> If you want, you can add a minimal example and explain every single step >>> again, what you do, to create a crash. Then, I'll test again, but for >>> now, I don't know what to do more. >> >> I will try. I do use actions. >> >>> What Lazarus revision are you using? >>> Do you have installed AnchorDockingDsgn, Sparta_DockedFormEditor or >>> something similar? > > Hi, > > I manage to reliably reproduce it ! > > 1 Open attached project. > 2 Double click MainMenu1 to edit > 3 Under MenuItem5, delete MenuItem14,13,12,11 > (I use the - button in the menu editor) > 4 The last menu item under MenuItem5 is then 'Action3' > 5 Add new menu item (I click 'add menu item' below the Action3 item) > 6 Click on Action 3 > 7 Click on the newly added (in step 5) MenuItem11 > --->> BOOM > > Never fails. > > The delete step 3 is important. Without that, I don't get a crash. > I then tested deleting a single item instead of 4 items as described above, > then I also get a crash. So as soon as a delete is performed - boom... > > Michael. > > > -- > _______________________________________________ > Lazarus mailing list > Lazarus at lists.lazarus-ide.org > http://lists.lazarus-ide.org/listinfo/lazarus > -------------- next part -------------- A non-text attachment was scrubbed... Name: bug.zip Type: application/zip Size: 2854 bytes Desc: URL: From m-w-vogel at gmx.de Tue May 9 22:19:00 2017 From: m-w-vogel at gmx.de (Michael W. Vogel) Date: Tue, 9 May 2017 22:19:00 +0200 Subject: [Lazarus] Menu editor unstable? - stack trace In-Reply-To: References: <20170507103651.15696d9d@limapholos.matflo.wg> <303b5b80-d9c6-c3d4-fd9d-402bec4aca07@gmx.de> Message-ID: <376a6442-beec-3c4e-aae2-e04631ba4c68@gmx.de> Am 09.05.2017 um 15:15 schrieb Michael Van Canneyt via Lazarus: > Hi, > > I manage to reliably reproduce it ! > > 1 Open attached project. > 2 Double click MainMenu1 to edit > 3 Under MenuItem5, delete MenuItem14,13,12,11 > (I use the - button in the menu editor) > 4 The last menu item under MenuItem5 is then 'Action3' > 5 Add new menu item (I click 'add menu item' below the Action3 item) > 6 Click on Action 3 > 7 Click on the newly added (in step 5) MenuItem11 --->> BOOM > > Never fails. > > The delete step 3 is important. Without that, I don't get a crash. > I then tested deleting a single item instead of 4 items as described > above, > then I also get a crash. So as soon as a delete is performed - boom... Thank you for your exact explanation and test project! But sorry again, again I don't get it. I have tested here: 64bit Linux Mint 18.1 Cinnamon, GTK2 version 2.24.30, Lazarus 1.9.0 r54844 FPC 3.0.2 x86_64-linux-gtk2 64bit Linux Mint 17.3 KDE, GTK2 version 2.24.23, Lazarus 1.9.0 r54826 FPC 3.0.2 x86_64-linux-gtk2 64bit OpenSuse Leap 42.2 KDE GTK2 version 2.24.31, Lazarus 1.9.0 r54809 FPC 3.0.2 x86_64-linux-gtk2 64bit Windows 7, Lazarus 1.9.0 r54844 FPC 3.0.2 x86_64-win64-win32/win64 Maybe it is a problem with your GTK2 version? Maybe it is a problem with your OS? Maybe it was fixed in meantime? Maybe you have a broken installation of Lazarus? Maybe it is a timing problem (as my development pc was out of order, I bought a relativ fast Core I5, so I'm not fast enough to click)? Maybe it is better to open a bugreport about that issue? Then we can better gather informations about it. Is there anybody else how can create a crash with the test project and the steps above? Michl From michael at freepascal.org Wed May 10 00:06:35 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Wed, 10 May 2017 00:06:35 +0200 (CEST) Subject: [Lazarus] Menu editor unstable? - stack trace In-Reply-To: <376a6442-beec-3c4e-aae2-e04631ba4c68@gmx.de> References: <20170507103651.15696d9d@limapholos.matflo.wg> <303b5b80-d9c6-c3d4-fd9d-402bec4aca07@gmx.de> <376a6442-beec-3c4e-aae2-e04631ba4c68@gmx.de> Message-ID: On Tue, 9 May 2017, Michael W. Vogel via Lazarus wrote: > Am 09.05.2017 um 15:15 schrieb Michael Van Canneyt via Lazarus: >> Hi, >> >> I manage to reliably reproduce it ! >> >> 1 Open attached project. >> 2 Double click MainMenu1 to edit >> 3 Under MenuItem5, delete MenuItem14,13,12,11 >> (I use the - button in the menu editor) >> 4 The last menu item under MenuItem5 is then 'Action3' >> 5 Add new menu item (I click 'add menu item' below the Action3 item) >> 6 Click on Action 3 >> 7 Click on the newly added (in step 5) MenuItem11 --->> BOOM >> >> Never fails. >> >> The delete step 3 is important. Without that, I don't get a crash. >> I then tested deleting a single item instead of 4 items as described >> above, >> then I also get a crash. So as soon as a delete is performed - boom... > > Thank you for your exact explanation and test project! But sorry again, > again I don't get it. > > I have tested here: > 64bit Linux Mint 18.1 Cinnamon, GTK2 version 2.24.30, Lazarus 1.9.0 > r54844 FPC 3.0.2 x86_64-linux-gtk2 This is the exact version I am using. (lazarus SVN version may differ, but it is the day before yesterday's SVN version) > > Maybe it is a problem with your GTK2 version? > Maybe it is a problem with your OS? They are the same as yours. > Maybe it was fixed in meantime? > Maybe you have a broken installation of Lazarus? Define broken ? It's a clean SVN update. > Maybe it is a timing problem (as my development pc was out of order, I > bought a relativ fast Core I5, so I'm not fast enough to click)? Clicking speed has nothing to do with it. I can wait a second, 2 seconds. Doesn't matter. The only thing that matters is the delete. I wish to point out that there is a LCL warning about freeing an item with LCLCount>1, which clearly points at a logic error: something is probably being freed twice. > Maybe it is better to open a bugreport about that issue? Then we can > better gather informations about it. I will post the steps and project in the bugtracker. Michael. From nc-gaertnma at netcologne.de Wed May 10 00:39:42 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Wed, 10 May 2017 00:39:42 +0200 Subject: [Lazarus] Menu editor unstable? - stack trace In-Reply-To: References: <20170507103651.15696d9d@limapholos.matflo.wg> <303b5b80-d9c6-c3d4-fd9d-402bec4aca07@gmx.de> <376a6442-beec-3c4e-aae2-e04631ba4c68@gmx.de> Message-ID: <20170510003942.24d18cbd@limapholos.matflo.wg> On Wed, 10 May 2017 00:06:35 +0200 (CEST) Michael Van Canneyt via Lazarus wrote: >[...] > > I have tested here: > > 64bit Linux Mint 18.1 Cinnamon, GTK2 version 2.24.30, Lazarus 1.9.0 > > r54844 FPC 3.0.2 x86_64-linux-gtk2 > > This is the exact version I am using. (lazarus SVN version may differ, but > it is the day before yesterday's SVN version) > > > > > Maybe it is a problem with your GTK2 version? > > Maybe it is a problem with your OS? > > They are the same as yours. Maybe the bug is not in the menu editor, but in an installed package and the menu editor is only the symptom? Try uninstalling all unneeded packages. Does that change anything? Mattias From ganmax at narod.ru Wed May 10 01:11:24 2017 From: ganmax at narod.ru (Maxim Ganetsky) Date: Wed, 10 May 2017 02:11:24 +0300 Subject: [Lazarus] Call for translations updates for 1.8 release In-Reply-To: References: <2ccacec0-7797-c4d5-0fb2-7f9341672d07@narod.ru> Message-ID: 09.05.2017 0:34, Bart via Lazarus пишет: > On 4/18/17, Maxim Ganetsky via Lazarus wrote: > >> Now that Lazarus 1.8 branch has been created it is time for translators >> to review and update their translations. > > Is there an official translator for the Dutch language files? No. Feel free to take it over. > The state of the dutch translation is rather poor. > > I started to make some improvements, but it's a rather daunting task. > All the more because for me programming is tied to the English > language and translating "keywords" like property, event, message etc. > just sounds a bit silly to me. > Also the dutch language is much more verbose than the english one. Probably not more than Russian? > I also have seen many resourcestrings I have never encountered in the > wild, so I do not know their context. Just search for their names in codebase. -- Best regards, Maxim Ganetsky mailto:ganmax at narod.ru From michael at freepascal.org Wed May 10 14:25:53 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Wed, 10 May 2017 14:25:53 +0200 (CEST) Subject: [Lazarus] Menu editor unstable? - stack trace In-Reply-To: <20170510003942.24d18cbd@limapholos.matflo.wg> References: <20170507103651.15696d9d@limapholos.matflo.wg> <303b5b80-d9c6-c3d4-fd9d-402bec4aca07@gmx.de> <376a6442-beec-3c4e-aae2-e04631ba4c68@gmx.de> <20170510003942.24d18cbd@limapholos.matflo.wg> Message-ID: On Wed, 10 May 2017, Mattias Gaertner via Lazarus wrote: > On Wed, 10 May 2017 00:06:35 +0200 (CEST) > Michael Van Canneyt via Lazarus wrote: > >> [...] >> > I have tested here: >> > 64bit Linux Mint 18.1 Cinnamon, GTK2 version 2.24.30, Lazarus 1.9.0 >> > r54844 FPC 3.0.2 x86_64-linux-gtk2 >> >> This is the exact version I am using. (lazarus SVN version may differ, but >> it is the day before yesterday's SVN version) >> >> > >> > Maybe it is a problem with your GTK2 version? >> > Maybe it is a problem with your OS? >> >> They are the same as yours. > > Maybe the bug is not in the menu editor, but in an installed package > and the menu editor is only the symptom? > Try uninstalling all unneeded packages. Does that change anything? I created a minimal IDE without any additional packages installed ('make all'). Latest SVN. Revision 54848. (I did an svn update). FPC 3.0.2. No defines are set when building the IDE And I still get the error, I did as I outlined before. I waited 5 (five!) seconds before clicking on the newly added item. That should eliminate any possible timing issues. I remind you that the LCL *warns* that something is wrong: WARNING: TShadowItem.Destroy with LCLRefCount>0. Hint: Maybe the component is processing an event? This line alone should IMHO be enough to tell the IDE people that something is actually going wrong. Below is the output on the console when I do the steps as I outlined them above. I have reported it as a bug. https://bugs.freepascal.org/view.php?id=31791 Michael. TObjectInspectorDlg.FillPersistentComboBox: Updating ComboBox with components WARNING: TShadowItem.Destroy with LCLRefCount>0. Hint: Maybe the component is processing an event? Hint: (lazarus) TMainIDE.OnPropHookDeletePersistent A MenuItem14:TMenuItem TObjectInspectorDlg.FillPersistentComboBox: Updating ComboBox with components Hint: (lazarus) TMainIDE.OnPropHookDeletePersistent A MenuItem13:TMenuItem TObjectInspectorDlg.FillPersistentComboBox: Updating ComboBox with components Hint: (lazarus) TMainIDE.OnPropHookDeletePersistent A MenuItem12:TMenuItem TObjectInspectorDlg.FillPersistentComboBox: Updating ComboBox with components Hint: (lazarus) TMainIDE.OnPropHookDeletePersistent A MenuItem11:TMenuItem TObjectInspectorDlg.FillPersistentComboBox: Updating ComboBox with components WARNING: TShadowItem.Destroy with LCLRefCount>0. Hint: Maybe the component is processing an event? TApplication.HandleException Access violation Stack trace: $0000000000000000 $0000000000A08B7D line 1606 of ../designer/menueditor.pp $0000000000A0DD03 line 2578 of ../designer/menueditor.pp $00000000005B467A line 2242 of include/control.inc $00000000005B4B17 line 2375 of include/control.inc $0000000000434EF2 line 602 of ../inc/objpas.inc $00000000005B457F line 2202 of include/control.inc $00000000005A6FAD line 5396 of include/wincontrol.inc $000000000077B7A2 line 112 of lclmessageglue.pas $0000000000673075 line 3702 of gtk2proc.inc $00000000006826EA line 2137 of gtk2callback.inc $0000000000681D68 line 1899 of gtk2callback.inc $00007FCBE2536AFC From michael at freepascal.org Wed May 10 14:32:23 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Wed, 10 May 2017 14:32:23 +0200 (CEST) Subject: [Lazarus] Menu editor unstable? - stack trace In-Reply-To: References: <20170507103651.15696d9d@limapholos.matflo.wg> <303b5b80-d9c6-c3d4-fd9d-402bec4aca07@gmx.de> <376a6442-beec-3c4e-aae2-e04631ba4c68@gmx.de> <20170510003942.24d18cbd@limapholos.matflo.wg> Message-ID: On Wed, 10 May 2017, Michael Van Canneyt via Lazarus wrote: > > I have reported it as a bug. > https://bugs.freepascal.org/view.php?id=31791 I attached 2 backtraces to the bug report. One when the warning happens (I put a breakpoint there) One when the AV happens. Hopefully this helps. Michael. From mailinglists at geldenhuys.co.uk Wed May 10 15:40:11 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 10 May 2017 14:40:11 +0100 Subject: [Lazarus] visual appearance of ReadOnly state widgets Message-ID: <2ba76119-7f66-7fb3-4919-122873896cc4@geldenhuys.co.uk> Hi, Is it normal for read-only LCL widgets to look identical to their Read/Write state? For example in fpGUI read-only widgets look visibly different. See attached animated GIF. But with a LCL application I'm working on, read-only widgets don't have any indication that they are read-only at all. The only slight change is in the Calendar ComboBox widget where the icon is greyed out. And to make matters worse, a ReadOnly TComboBox allows me to change the focusitem via a mouse, adding to the confusion. I'm using LCL-GTK2 in the second screenshot, but this application run on Linux, Windows and OSX. Is my only LCL option to make them ReadOnly = False, and Enabled = False? Regards, Graeme -------------- next part -------------- A non-text attachment was scrubbed... Name: readonly_test.gif Type: image/gif Size: 22398 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: screenshot_lcl.png Type: image/png Size: 23446 bytes Desc: not available URL: From aaa5500 at ya.ru Wed May 10 16:08:13 2017 From: aaa5500 at ya.ru (Alexey) Date: Wed, 10 May 2017 17:08:13 +0300 Subject: [Lazarus] visual appearance of ReadOnly state widgets In-Reply-To: <2ba76119-7f66-7fb3-4919-122873896cc4@geldenhuys.co.uk> References: <2ba76119-7f66-7fb3-4919-122873896cc4@geldenhuys.co.uk> Message-ID: <68ad7ef0-1d7e-67c8-fa3f-b17371e26d67@ya.ru> On 10.05.2017 16:40, Graeme Geldenhuys via Lazarus wrote: > And to make matters worse, a ReadOnly TComboBox allows me to change the > focusitem via a mouse, adding to the confusion. > It is made like in Delphi's r/o combobox. In Lazarus better use Enabled:=false and it has indication for some controls. Not for all. I suggested indication for disabled Grid. -- Regards, Alexey From vojtech.cihak at atlas.cz Wed May 10 16:26:07 2017 From: vojtech.cihak at atlas.cz (=?utf-8?q?Vojt=C4=9Bch_=C4=8Cih=C3=A1k?=) Date: Wed, 10 May 2017 16:26:07 +0200 Subject: [Lazarus] =?utf-8?q?visual_appearance_of_ReadOnly_state_widgets?= In-Reply-To: 0000000073ac00018ae001165055 References: 0000000073ac00018ae001165055 Message-ID: <20170510162607.64066789@atlas.cz> Hi,   I just did a little test in Qt Designer. There seems to be no difference in QLineEdit (TEdit). There is sometimes difference in editable and non-editable QComboBox (depends on style - QtCurve, Oxygen, Breeze are different, Windows style is identical).   OTOH, your fpGUI read-only controls looks like disabled, which may be confusing.   V. ______________________________________________________________ > Od: Graeme Geldenhuys via Lazarus > Komu: Lazarus mailing list > Datum: 10.05.2017 15:40 > Předmět: [Lazarus] visual appearance of ReadOnly state widgets > Hi, Is it normal for read-only LCL widgets to look identical to their Read/Write state? ... Regards,  Graeme ---------- -- _______________________________________________ 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 mailinglists at geldenhuys.co.uk Wed May 10 16:35:30 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 10 May 2017 15:35:30 +0100 Subject: [Lazarus] visual appearance of ReadOnly state widgets In-Reply-To: <68ad7ef0-1d7e-67c8-fa3f-b17371e26d67@ya.ru> References: <2ba76119-7f66-7fb3-4919-122873896cc4@geldenhuys.co.uk> <68ad7ef0-1d7e-67c8-fa3f-b17371e26d67@ya.ru> Message-ID: <90244568-bfc9-414f-b039-ca88ed474c0b@geldenhuys.co.uk> On 2017-05-10 15:08, Alexey via Lazarus wrote: > It is made like in Delphi's r/o combobox. Well, then both are broken. > In Lazarus better use Enabled:=false and it has indication for some > controls. 1) The problem with Enabled = False is that in then greys the text too. Thus making in very hard to read. See attached screenshot. Alos see the difference in fpGUI's ReadOnly = True where the text is still in Black - only the background indication changed. 2) Some controls?? Here we go with the LCL inconsistency again. :-/ Regards, Graeme -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot_enabled_false.png Type: image/png Size: 10650 bytes Desc: not available URL: From mailinglists at geldenhuys.co.uk Wed May 10 16:39:13 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 10 May 2017 15:39:13 +0100 Subject: [Lazarus] visual appearance of ReadOnly state widgets In-Reply-To: <20170510162607.64066789@atlas.cz> References: <20170510162607.64066789@atlas.cz> Message-ID: On 2017-05-10 15:26, Vojtěch Čihák via Lazarus wrote: > your fpGUI read-only controls looks like disabled, which may be confusing. In fpGUI, with Enabled = False, the text is greyed out too. Same for buttons in ComboBoxes, Edit Button widgets etc. In read-only mode the text is still in Black (or whatever text color the component was set at), and buttons are still visually "enabled". Regards, Graeme From aaa5500 at ya.ru Wed May 10 17:05:10 2017 From: aaa5500 at ya.ru (Alexey) Date: Wed, 10 May 2017 18:05:10 +0300 Subject: [Lazarus] visual appearance of ReadOnly state widgets In-Reply-To: <90244568-bfc9-414f-b039-ca88ed474c0b@geldenhuys.co.uk> References: <2ba76119-7f66-7fb3-4919-122873896cc4@geldenhuys.co.uk> <68ad7ef0-1d7e-67c8-fa3f-b17371e26d67@ya.ru> <90244568-bfc9-414f-b039-ca88ed474c0b@geldenhuys.co.uk> Message-ID: <48f9f772-e0af-734d-daac-30b0125493e0@ya.ru> On 10.05.2017 17:35, Graeme Geldenhuys via Lazarus wrote: > 2) Some controls?? Here we go with the LCL inconsistency again. :-/ I suggested pch [gray color for disabled] for Grids, not accepted yet. Can do pch for Treeview and etc. -- Regards, Alexey From lazarus at kluug.net Wed May 10 17:07:19 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Wed, 10 May 2017 17:07:19 +0200 Subject: [Lazarus] visual appearance of ReadOnly state widgets In-Reply-To: <2ba76119-7f66-7fb3-4919-122873896cc4@geldenhuys.co.uk> References: <2ba76119-7f66-7fb3-4919-122873896cc4@geldenhuys.co.uk> Message-ID: On 10.05.2017 15:40, Graeme Geldenhuys via Lazarus wrote: > Is it normal for read-only LCL widgets to look identical to their > Read/Write state? Yes. Ondrej From mailinglists at geldenhuys.co.uk Wed May 10 17:08:08 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 10 May 2017 16:08:08 +0100 Subject: [Lazarus] visual appearance of ReadOnly state widgets In-Reply-To: <48f9f772-e0af-734d-daac-30b0125493e0@ya.ru> References: <2ba76119-7f66-7fb3-4919-122873896cc4@geldenhuys.co.uk> <68ad7ef0-1d7e-67c8-fa3f-b17371e26d67@ya.ru> <90244568-bfc9-414f-b039-ca88ed474c0b@geldenhuys.co.uk> <48f9f772-e0af-734d-daac-30b0125493e0@ya.ru> Message-ID: On 2017-05-10 16:05, Alexey via Lazarus wrote: > I suggested pch [gray color for disabled] for Grids, not accepted yet. > Can do pch for Treeview and etc. Thanks for your feedback and warning about some controls with Enabled = False state. Regards, Graeme From zeljko at holobit.net Wed May 10 18:21:46 2017 From: zeljko at holobit.net (zeljko) Date: Wed, 10 May 2017 18:21:46 +0200 Subject: [Lazarus] visual appearance of ReadOnly state widgets In-Reply-To: <2ba76119-7f66-7fb3-4919-122873896cc4@geldenhuys.co.uk> References: <2ba76119-7f66-7fb3-4919-122873896cc4@geldenhuys.co.uk> Message-ID: <834cd270-a3de-5bc6-9c65-08cee1e71eaf@holobit.net> On 10.05.2017 15:40, Graeme Geldenhuys via Lazarus wrote: > Hi, > > Is it normal for read-only LCL widgets to look identical to their > Read/Write state? Yes, LCL behaves exactly as underlaying widgetset says so. > > For example in fpGUI read-only widgets look visibly different. > See attached animated GIF. Looks pretty wrong to me. It's big difference between ReadOnly and Enabled. zeljko From mailinglists at geldenhuys.co.uk Wed May 10 18:29:06 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 10 May 2017 17:29:06 +0100 Subject: [Lazarus] visual appearance of ReadOnly state widgets In-Reply-To: <834cd270-a3de-5bc6-9c65-08cee1e71eaf@holobit.net> References: <2ba76119-7f66-7fb3-4919-122873896cc4@geldenhuys.co.uk> <834cd270-a3de-5bc6-9c65-08cee1e71eaf@holobit.net> Message-ID: <979a00ca-85a6-b04c-9698-011192ffce56@geldenhuys.co.uk> On 2017-05-10 17:21, zeljko wrote: >> For example in fpGUI read-only widgets look visibly different. >> See attached animated GIF. > Looks pretty wrong to me. It's big difference between ReadOnly and Enabled. Well, they visually indicate to the end-user the ReadOnly or Enabled state, without the user having to guess or do trial-and-error (try and change something in a widget, just to find out you can't). LCL gives no visual cues. 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 zeljko at holobit.net Wed May 10 18:39:48 2017 From: zeljko at holobit.net (zeljko) Date: Wed, 10 May 2017 18:39:48 +0200 Subject: [Lazarus] visual appearance of ReadOnly state widgets In-Reply-To: <979a00ca-85a6-b04c-9698-011192ffce56@geldenhuys.co.uk> References: <2ba76119-7f66-7fb3-4919-122873896cc4@geldenhuys.co.uk> <834cd270-a3de-5bc6-9c65-08cee1e71eaf@holobit.net> <979a00ca-85a6-b04c-9698-011192ffce56@geldenhuys.co.uk> Message-ID: <8a1d2642-0f7b-4640-4b01-7b460cedb864@holobit.net> On 10.05.2017 18:29, Graeme Geldenhuys via Lazarus wrote: > On 2017-05-10 17:21, zeljko wrote: >>> For example in fpGUI read-only widgets look visibly different. >>> See attached animated GIF. >> Looks pretty wrong to me. It's big difference between ReadOnly and >> Enabled. > > Well, they visually indicate to the end-user the ReadOnly or Enabled > state, without the user having to guess or do trial-and-error (try and > change something in a widget, just to find out you can't). LCL gives no > visual cues. Again: it's not LCL, but widgetset (win32, qt, gtk2 etc). If widgetset gives some visual feedback about readonly state then LCL shows it exactly like it is. No more no less. zeljko From jmlandmesser at gmx.de Thu May 11 09:50:22 2017 From: jmlandmesser at gmx.de (Landmesser John) Date: Thu, 11 May 2017 09:50:22 +0200 Subject: [Lazarus] what do i see left of the Scrollbar? Message-ID: just curious: what do i see left of the Editor windows Scrollbar ... these little colored bars? Lazarus 1.9.0 rUnknown FPC 3.0.0 i386-win32-win32/win64 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cldcpmffipklpbef.png Type: image/png Size: 34702 bytes Desc: not available URL: From zeljko at holobit.net Thu May 11 10:09:20 2017 From: zeljko at holobit.net (zeljko) Date: Thu, 11 May 2017 10:09:20 +0200 Subject: [Lazarus] what do i see left of the Scrollbar? In-Reply-To: References: Message-ID: <2cc9de9d-03fd-10de-8580-60aae6518536@holobit.net> On 11.05.2017 09:50, Landmesser John via Lazarus wrote: > just curious: > > what do i see left of the Editor windows Scrollbar ... these little > colored bars? Changed lines. zeljko From lazarus at mfriebe.de Thu May 11 11:21:22 2017 From: lazarus at mfriebe.de (Martin Frb) Date: Thu, 11 May 2017 10:21:22 +0100 Subject: [Lazarus] what do i see left of the Scrollbar? In-Reply-To: References: Message-ID: <2043771d-78cd-eebf-a0cc-7b1dfc619519@mfriebe.de> On 11/05/2017 08:50, Landmesser John via Lazarus wrote: > > just curious: > > what do i see left of the Editor windows Scrollbar ... these little > colored bars? > > An overview of the entire file (all lines) orange boxes are location of errors (compilation) blue boxes are bookmark red boxes are breakpoints short green/yellow bits indicate changed lines (saved/unsaved) Background color indicates unit section (interface, implementation, init-/finitialization Background also changes for current visible page of the file From mailinglists at geldenhuys.co.uk Thu May 11 12:11:05 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 11 May 2017 11:11:05 +0100 Subject: [Lazarus] what do i see left of the Scrollbar? In-Reply-To: <2043771d-78cd-eebf-a0cc-7b1dfc619519@mfriebe.de> References: <2043771d-78cd-eebf-a0cc-7b1dfc619519@mfriebe.de> Message-ID: <486656a7-1012-bd45-b2ae-d74df639ca87@geldenhuys.co.uk> On 2017-05-11 10:21, Martin Frb via Lazarus wrote: > An overview of the entire file (all lines) It’s amazing all the functionality (information wise) in such a little widget. :) Now all that remains is to make it clickable, so you jump to the part of the file where you clicked. 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 Thu May 11 12:50:11 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Thu, 11 May 2017 12:50:11 +0200 Subject: [Lazarus] what do i see left of the Scrollbar? In-Reply-To: <486656a7-1012-bd45-b2ae-d74df639ca87@geldenhuys.co.uk> References: <2043771d-78cd-eebf-a0cc-7b1dfc619519@mfriebe.de> <486656a7-1012-bd45-b2ae-d74df639ca87@geldenhuys.co.uk> Message-ID: On 11.05.2017 12:11, Graeme Geldenhuys via Lazarus wrote: > Now all that remains is to make it clickable, so you jump to the part > of the file where you clicked. It is clickable :) Ondrej From mailinglists at geldenhuys.co.uk Thu May 11 13:06:11 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 11 May 2017 12:06:11 +0100 Subject: [Lazarus] Insufficient keyboard modifiers support in IDE Message-ID: <7ef389ac-cb34-5fc2-da02-2d82b7e9ddb0@geldenhuys.co.uk> Hi, I'm using an Ergodox keyboard, and have a shortcut layer setup in my keyboard layout. This allows me a single key press, yet sends a complex key sequence to the OS. The same can be achieved with normal keyboards and some extra software. This is extremely useful, and more about that can be read here, with an example setup under OSX. Using the "Hyper" or "Meh" key plus one other key. Hyper = Alt + Ctrl + Shift + Cmd/Win Meh = Alt + Ctrl + Shift all that via a single keypress. * A Hyper key, as described by Brett Terpstra. http://brettterpstra.com/2012/12/08/a-useful-caps-lock-key/ * A Meh key, which is a less-hyper version of the Hyper key (sends Alt+Ctrl+Shift, without Cmd/Win). So in my fpGUI events test program, if I press one of those shortcut keys, the following sequence is registered: [Shift Alt Ctrl Super] Key pressed: U [Shift Alt Ctrl Super] Key released: U Now in Lazarus IDE, I'm trying to customise some of my frequently used actions using such shortcut keys, but the IDE keyboard shortcut interface dialog, doesn't support the Super (aka Hyper) key modifier. It only supports Shift, Ctrl and Alt (Ergodox equivalent of the Meh key). Could the IDE key-grab dialog be extended to support the Super (aka Hyper) modifier key as well, or is there some platform limitation, and why it isn't there? 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 Thu May 11 13:12:09 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 11 May 2017 12:12:09 +0100 Subject: [Lazarus] what do i see left of the Scrollbar? In-Reply-To: References: <2043771d-78cd-eebf-a0cc-7b1dfc619519@mfriebe.de> <486656a7-1012-bd45-b2ae-d74df639ca87@geldenhuys.co.uk> Message-ID: <1b41384b-a52d-3c20-4b56-c0c71795e07b@geldenhuys.co.uk> On 2017-05-11 11:50, Ondrej Pokorny via Lazarus wrote: > It is clickable :) Umm, it doesn't work here. Clicking via LClick or RClick doesn't have any affect. I'm using Lazarus 1.7 r52715 FPC 2.6.4 x86_64-linux-gtk 2, running under CentOS 6.6. Maybe I should update my Lazarus? I then tested my Lazarus 1.9.0 r54792 FPC 2.6.4 x86_64-freebsd-gtk2 system, and there the overview gutter is also not clickable. 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 Thu May 11 13:55:03 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Thu, 11 May 2017 13:55:03 +0200 Subject: [Lazarus] what do i see left of the Scrollbar? In-Reply-To: <1b41384b-a52d-3c20-4b56-c0c71795e07b@geldenhuys.co.uk> References: <2043771d-78cd-eebf-a0cc-7b1dfc619519@mfriebe.de> <486656a7-1012-bd45-b2ae-d74df639ca87@geldenhuys.co.uk> <1b41384b-a52d-3c20-4b56-c0c71795e07b@geldenhuys.co.uk> Message-ID: <638041ee-8a02-578a-95dc-45c0c9ce374e@kluug.net> On 11.05.2017 13:12, Graeme Geldenhuys via Lazarus wrote: > On 2017-05-11 11:50, Ondrej Pokorny via Lazarus wrote: >> It is clickable :) > > Umm, it doesn't work here. Clicking via LClick or RClick doesn't have > any affect. I'm using Lazarus 1.7 r52715 FPC 2.6.4 x86_64-linux-gtk 2, > running under CentOS 6.6. > > Maybe I should update my Lazarus? > > I then tested my Lazarus 1.9.0 r54792 FPC 2.6.4 x86_64-freebsd-gtk2 > system, and there the overview gutter is also not clickable. I don't know. Probably it is some OS/WS-dependent problem. On Windows10/win32 it is clickable and it has always been clickable (this is the only platform I tested) Ondrej From nc-gaertnma at netcologne.de Thu May 11 14:03:07 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Thu, 11 May 2017 14:03:07 +0200 Subject: [Lazarus] what do i see left of the Scrollbar? In-Reply-To: <1b41384b-a52d-3c20-4b56-c0c71795e07b@geldenhuys.co.uk> References: <2043771d-78cd-eebf-a0cc-7b1dfc619519@mfriebe.de> <486656a7-1012-bd45-b2ae-d74df639ca87@geldenhuys.co.uk> <1b41384b-a52d-3c20-4b56-c0c71795e07b@geldenhuys.co.uk> Message-ID: <20170511140307.4543e511@limapholos.matflo.wg> On Thu, 11 May 2017 12:12:09 +0100 Graeme Geldenhuys via Lazarus wrote: > On 2017-05-11 11:50, Ondrej Pokorny via Lazarus wrote: > > It is clickable :) > > Umm, it doesn't work here. Clicking via LClick or RClick doesn't have > any affect. I'm using Lazarus 1.7 r52715 FPC 2.6.4 x86_64-linux-gtk 2, > running under CentOS 6.6. It's clickable under Linux too. Maybe you altered some options? Editor options / Mouse / Advanced / Gutter / Overview Mattias From mailinglists at geldenhuys.co.uk Thu May 11 14:16:11 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 11 May 2017 13:16:11 +0100 Subject: [Lazarus] what do i see left of the Scrollbar? In-Reply-To: <20170511140307.4543e511@limapholos.matflo.wg> References: <2043771d-78cd-eebf-a0cc-7b1dfc619519@mfriebe.de> <486656a7-1012-bd45-b2ae-d74df639ca87@geldenhuys.co.uk> <1b41384b-a52d-3c20-4b56-c0c71795e07b@geldenhuys.co.uk> <20170511140307.4543e511@limapholos.matflo.wg> Message-ID: <18abc055-09ad-a73f-2f67-43e230685564@geldenhuys.co.uk> On 2017-05-11 13:03, Mattias Gaertner via Lazarus wrote: > Maybe you altered some options? > > Editor options / Mouse / Advanced / Gutter / Overview Thanks Mattias, that did the trick. I had nothing defined under the "Overview" section - both under Linux and FreeBSD. Regards, Graeme From aaa5500 at ya.ru Thu May 11 14:47:06 2017 From: aaa5500 at ya.ru (Alexey) Date: Thu, 11 May 2017 15:47:06 +0300 Subject: [Lazarus] Insufficient keyboard modifiers support in IDE In-Reply-To: <7ef389ac-cb34-5fc2-da02-2d82b7e9ddb0@geldenhuys.co.uk> References: <7ef389ac-cb34-5fc2-da02-2d82b7e9ddb0@geldenhuys.co.uk> Message-ID: <7227c5ab-bca6-906d-a854-a064eca1b175@ya.ru> Hm, on OSX, IDE shows key grab dialog [in keymapping opts] with additional checkbox, "Meta". It is what yo need? Ctrl+Meta checkboxes - for keys Ctrl/Command. And dialog works for Meta. Alexey From mailinglists at geldenhuys.co.uk Thu May 11 15:25:29 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 11 May 2017 14:25:29 +0100 Subject: [Lazarus] Insufficient keyboard modifiers support in IDE In-Reply-To: <7227c5ab-bca6-906d-a854-a064eca1b175@ya.ru> References: <7ef389ac-cb34-5fc2-da02-2d82b7e9ddb0@geldenhuys.co.uk> <7227c5ab-bca6-906d-a854-a064eca1b175@ya.ru> Message-ID: <2be1288a-b5d1-6e59-a382-7caf67370148@geldenhuys.co.uk> On 2017-05-11 13:47, Alexey via Lazarus wrote: > Hm, on OSX, IDE shows key grab dialog [in keymapping opts] with > additional checkbox, > "Meta". It is what yo need? Attached is a screenshot of what I see. Both in Lazarus v1.7 and v1.9 using the IDE compiled with LCL-GTK2. Note that there is checkboxes for "Shift", "Alt" and "Ctrl", but not for "Super" (aka Hyper on some systems, or Windows key, or Meta under KDE Plasma etc). These are the possible modifiers I have available for X11 based systems. I presume other operating systems have similar. // modifier keys keyShift = $e300; keyCtrl = $e301; keyAlt = $e302; keyMeta = $e303; keySuper = $e304; keyHyper = $e305; keyAltGr = $e306; keyCaps = $e307; keyNum = $e308; keyScroll = $e309; Wikipedia: Super key (keyboard button) https://en.wikipedia.org/wiki/Super_key_(keyboard_button) 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot.png Type: image/png Size: 6689 bytes Desc: not available URL: From aaa5500 at ya.ru Thu May 11 16:28:49 2017 From: aaa5500 at ya.ru (Alexey) Date: Thu, 11 May 2017 17:28:49 +0300 Subject: [Lazarus] Insufficient keyboard modifiers support in IDE In-Reply-To: <2be1288a-b5d1-6e59-a382-7caf67370148@geldenhuys.co.uk> References: <7ef389ac-cb34-5fc2-da02-2d82b7e9ddb0@geldenhuys.co.uk> <7227c5ab-bca6-906d-a854-a064eca1b175@ya.ru> <2be1288a-b5d1-6e59-a382-7caf67370148@geldenhuys.co.uk> Message-ID: >Both in Lazarus v1.7 and v1.9 using the IDE compiled with LCL-GTK2. Check "Meta" shows on Mac only; you need it for Lin/Win? It is simple fix, one liner. function TCustomShortCutGrabBox.GetDefaultShiftButtons: TShiftState; begin {$IFDEF Darwin} Result:=[ssCtrl,ssShift,ssAlt,ssMeta]; {$ELSE} Result:=[ssCtrl,ssShift,ssAlt]; {$ENDIF} end; -- Regards, Alexey From mailinglists at geldenhuys.co.uk Thu May 11 16:50:14 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 11 May 2017 15:50:14 +0100 Subject: [Lazarus] Insufficient keyboard modifiers support in IDE In-Reply-To: References: <7ef389ac-cb34-5fc2-da02-2d82b7e9ddb0@geldenhuys.co.uk> <7227c5ab-bca6-906d-a854-a064eca1b175@ya.ru> <2be1288a-b5d1-6e59-a382-7caf67370148@geldenhuys.co.uk> Message-ID: <0f0131c9-9b74-1b8b-a79b-0788dfcf2942@geldenhuys.co.uk> On 2017-05-11 15:28, Alexey via Lazarus wrote: > Check "Meta" shows on Mac only; you need it for Lin/Win? It is simple > fix, one liner. 1) That wasn't too clever from whomever implemented that artificial restriction. Meta, Super, Hyper and AltGr are often used on other platforms (Linux,FreeBSD,Windows) too. 2) It seems what your suggestion is just a partial fix and needs more work. I enabled Meta, Super, Hyper and AltGr as well (see attached screenshot). Yet, when I click the "Grab" button and press the key that generates Ctrl+Alt+Shift+Hyper+Up it doesn't recognise any of the new shiftstates that I enabled. So it seems more work is required somewhere in the IDE or wigetset backend. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot.png Type: image/png Size: 9999 bytes Desc: not available URL: From aaa5500 at ya.ru Thu May 11 17:00:01 2017 From: aaa5500 at ya.ru (Alexey) Date: Thu, 11 May 2017 18:00:01 +0300 Subject: [Lazarus] Insufficient keyboard modifiers support in IDE In-Reply-To: <0f0131c9-9b74-1b8b-a79b-0788dfcf2942@geldenhuys.co.uk> References: <7ef389ac-cb34-5fc2-da02-2d82b7e9ddb0@geldenhuys.co.uk> <7227c5ab-bca6-906d-a854-a064eca1b175@ya.ru> <2be1288a-b5d1-6e59-a382-7caf67370148@geldenhuys.co.uk> <0f0131c9-9b74-1b8b-a79b-0788dfcf2942@geldenhuys.co.uk> Message-ID: <1193de6e-0654-722d-a8cb-a5216905ca8f@ya.ru> On 11.05.2017 17:50, Graeme Geldenhuys via Lazarus wrote: > that generates Ctrl+Alt+Shift+Hyper+Up it doesn't recognise any of the > new shiftstates It must not see em. Laz dont know what is Hyper key, and Super. Shiftstate flags are none, AFAIK LCL dont support Hyper/Super keys -- Regards, Alexey From mailinglists at geldenhuys.co.uk Thu May 11 17:21:49 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 11 May 2017 16:21:49 +0100 Subject: [Lazarus] Insufficient keyboard modifiers support in IDE In-Reply-To: <1193de6e-0654-722d-a8cb-a5216905ca8f@ya.ru> References: <7ef389ac-cb34-5fc2-da02-2d82b7e9ddb0@geldenhuys.co.uk> <7227c5ab-bca6-906d-a854-a064eca1b175@ya.ru> <2be1288a-b5d1-6e59-a382-7caf67370148@geldenhuys.co.uk> <0f0131c9-9b74-1b8b-a79b-0788dfcf2942@geldenhuys.co.uk> <1193de6e-0654-722d-a8cb-a5216905ca8f@ya.ru> Message-ID: On 2017-05-11 16:00, Alexey via Lazarus wrote: > It must not see em. Laz dont know what is Hyper key, and Super. So it is a LCL bug then? As I mentioned, I'm using LCL-GTK2, and I know FreeBSD supports those keys (tested with xev), and I know GTK2 supports those keys (test with The GIMP). So does Java applications (tested with jEdit), and fpGUI applications. Attached is a screenshot where I tested keyboard shortcut "capturing" using The GIMP, which is compiled against GTK2 on my system. I'll file a Mantis bug report. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot.png Type: image/png Size: 12368 bytes Desc: not available URL: From mailinglists at geldenhuys.co.uk Thu May 11 17:30:39 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 11 May 2017 16:30:39 +0100 Subject: [Lazarus] Insufficient keyboard modifiers support in IDE In-Reply-To: References: <7ef389ac-cb34-5fc2-da02-2d82b7e9ddb0@geldenhuys.co.uk> <7227c5ab-bca6-906d-a854-a064eca1b175@ya.ru> <2be1288a-b5d1-6e59-a382-7caf67370148@geldenhuys.co.uk> <0f0131c9-9b74-1b8b-a79b-0788dfcf2942@geldenhuys.co.uk> <1193de6e-0654-722d-a8cb-a5216905ca8f@ya.ru> Message-ID: <0b1d4209-9122-e80d-1126-329cc4dfbc10@geldenhuys.co.uk> On 2017-05-11 16:21, Graeme Geldenhuys via Lazarus wrote: > I'll file a Mantis bug report. Reported as: https://mantis.freepascal.org/view.php?id=31797 Many thanks for your help and time Alexey. 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 Thu May 11 18:30:52 2017 From: noreply at z505.com (noreply at z505.com) Date: Thu, 11 May 2017 11:30:52 -0500 Subject: [Lazarus] Vulkan Library for FreePascal/Lazarus In-Reply-To: References: Message-ID: <7dad65b5c9b093116f9c54aa7b362d47@z505.com> On 2017-04-12 23:32, James.mcjohnson via Lazarus wrote: > This is both an announcement and request for help for an open source > FreePascal project which strives to provide: > You may want to also post this to the FPC mailing list rather than just the Lazarus list, as, vulkan can probably be used outside of the Lazarus IDE and just with plain fpc programs! From noreply at z505.com Thu May 11 18:34:08 2017 From: noreply at z505.com (noreply at z505.com) Date: Thu, 11 May 2017 11:34:08 -0500 Subject: [Lazarus] Vulkan Library for FreePascal/Lazarus In-Reply-To: References: Message-ID: <8c8f99a6602cdbb125f7b9dd5da80bf7@z505.com> On 2017-04-13 11:34, Michalis Kamburelis via Lazarus wrote: > @James, would you mind removing the "Public Service Announcement" from > https://github.com/james-mcjohnson/VulkanLibraryForFreePascal/blob/master/LICENSE.md > ? Don't get me wrong, I understand that you want to promote your faith > and I respect that. Having this in README files, and Pascal sources, > is absolutely OK. But I'm not a lawyer, and I'm unsure how it affects > the legal text of the license. Having just an "unmodified MIT license" > would feel safer for me. > Plus, it recommends using GoLang, not fpc, in the faith.. Be Baptized: "Go Not fpc. Just my opinion From marc at dommelstein.nl Thu May 11 21:07:10 2017 From: marc at dommelstein.nl (Marc Weustink) Date: Thu, 11 May 2017 21:07:10 +0200 Subject: [Lazarus] Insufficient keyboard modifiers support in IDE In-Reply-To: References: <7ef389ac-cb34-5fc2-da02-2d82b7e9ddb0@geldenhuys.co.uk> <7227c5ab-bca6-906d-a854-a064eca1b175@ya.ru> <2be1288a-b5d1-6e59-a382-7caf67370148@geldenhuys.co.uk> <0f0131c9-9b74-1b8b-a79b-0788dfcf2942@geldenhuys.co.uk> <1193de6e-0654-722d-a8cb-a5216905ca8f@ya.ru> Message-ID: <699FE839-7C97-4DBD-B4B7-9B588990AD5A@dommelstein.nl> On May 11, 2017 5:21:49 PM GMT+02:00, Graeme Geldenhuys via Lazarus wrote: >On 2017-05-11 16:00, Alexey via Lazarus wrote: >> It must not see em. Laz dont know what is Hyper key, and Super. > >So it is a LCL bug then? Not sure, iirc I've implemented them in gtk. At least I recall me looking at all the different modifiers. Marc > >As I mentioned, I'm using LCL-GTK2, and I know FreeBSD supports those >keys (tested with xev), and I know GTK2 supports those keys (test with >The GIMP). So does Java applications (tested with jEdit), and fpGUI >applications. > >Attached is a screenshot where I tested keyboard shortcut "capturing" >using The GIMP, which is compiled against GTK2 on my system. > >I'll file a Mantis bug report. > >Regards, > Graeme From aaa5500 at ya.ru Thu May 11 21:32:21 2017 From: aaa5500 at ya.ru (Alexey) Date: Thu, 11 May 2017 22:32:21 +0300 Subject: [Lazarus] Insufficient keyboard modifiers support in IDE In-Reply-To: <699FE839-7C97-4DBD-B4B7-9B588990AD5A@dommelstein.nl> References: <7ef389ac-cb34-5fc2-da02-2d82b7e9ddb0@geldenhuys.co.uk> <7227c5ab-bca6-906d-a854-a064eca1b175@ya.ru> <2be1288a-b5d1-6e59-a382-7caf67370148@geldenhuys.co.uk> <0f0131c9-9b74-1b8b-a79b-0788dfcf2942@geldenhuys.co.uk> <1193de6e-0654-722d-a8cb-a5216905ca8f@ya.ru> <699FE839-7C97-4DBD-B4B7-9B588990AD5A@dommelstein.nl> Message-ID: <56232ba3-5b4e-0d9a-4e82-599144339cec@ya.ru> > So it is a LCL bug then? Seems LCL ok: - Windows key works, it is ssMeta [on GTK2 too] - Super key [not Windows key] not known to LCL - Hyper key too not known - AltGr works here, in GTK2 it gives Alt. -- Regards, Alexey -------------- next part -------------- An HTML attachment was scrubbed... URL: From dezlov at gmail.com Fri May 12 01:10:24 2017 From: dezlov at gmail.com (Denis Kozlov) Date: Fri, 12 May 2017 00:10:24 +0100 Subject: [Lazarus] TEdit appears empty when text is too long Message-ID: <4ab166be-91e3-196d-5dad-5b4ad8d9970d@gmail.com> Hi, Has anybody experienced this problem or might know what is going on here? At around 5K characters the content of TEdit suddenly appears empty/blank (visually). The content is correct when retrieved programmatically. If enough characters are removed (programmatically) the content will show up again. Changing the font size changes this limit, where the limit is lower for a larger font size. It is as if the issue is bound by the visual width of entire text content, as opposed to just the small visible part. Tested on Windows 7: Lazarus 1.4.4 r49931 FPC 2.6.4 i386-win32-win32/win64 Lazarus 1.6.4 r54278 FPC 3.0.2 i386-win32-win32/win64 Lazarus 1.9.0 r54874 FPC 3.0.2 i386-win32-win32/win64 Also tested with Delphi 7, where the limit appeared past 50K characters. Sample project is attached. I will appreciate any clues to what's going on here. Thanks, Denis -------------- next part -------------- A non-text attachment was scrubbed... Name: EditTextTooLong.zip Type: application/octet-stream Size: 3586 bytes Desc: not available URL: From steveg at nevets.com.au Fri May 12 11:30:04 2017 From: steveg at nevets.com.au (Steve Gatenby) Date: Fri, 12 May 2017 19:30:04 +1000 Subject: [Lazarus] Compiler errors Message-ID: <0d40b2b7-d77d-3d31-1e44-a19592ec0f37@nevets.com.au> I am compiling my project in i386 mode (on an x64 system) I receive the following error (abridged) related to cross compiling as works ok as 64bit compile Compile Project, Mode: Lin-Intel-32, CPU: i386, Target: LxAazLMA: Exit code 256, Errors: 1, Warnings: 55, Hints: 204 Error: Error while linking Are there any logs created by Laz/fpc that would help find what is missing / wrong with my cross compile load ? Thanks - SteveG From aaa5500 at ya.ru Fri May 12 12:15:07 2017 From: aaa5500 at ya.ru (Alexey) Date: Fri, 12 May 2017 13:15:07 +0300 Subject: [Lazarus] TEdit appears empty when text is too long In-Reply-To: <4ab166be-91e3-196d-5dad-5b4ad8d9970d@gmail.com> References: <4ab166be-91e3-196d-5dad-5b4ad8d9970d@gmail.com> Message-ID: <3c60f0a4-19d0-ee8e-6dc5-44b182bbd98a@ya.ru> I only say that ATBinHex component cannot draw too long lines (by DrawTextW? TextOutW?) when API takes more than 4K chars (fixed to using only small cnt of chars). On 12.05.2017 02:10, Denis Kozlov via Lazarus wrote: > width of entire text content, as opposed to just the small visible part. -- Regards, Alexey From ptrg at freemail.hu Fri May 12 14:20:53 2017 From: ptrg at freemail.hu (=?UTF-8?B?UMOpdGVyIEfDoWJvcg==?=) Date: Fri, 12 May 2017 14:20:53 +0200 Subject: [Lazarus] Compiler errors In-Reply-To: <0d40b2b7-d77d-3d31-1e44-a19592ec0f37@nevets.com.au> References: <0d40b2b7-d77d-3d31-1e44-a19592ec0f37@nevets.com.au> Message-ID: Take a look at "View / Messages" windows where in the last few lines you will see the cause. For example missing libraries or such. Use the context menu of Messages window to filter (show or hide) some kind of messages.... 2017-05-12 11:30 keltezéssel, Steve Gatenby via Lazarus írta: > I am compiling my project in i386 mode (on an x64 system) > > I receive the following error (abridged) related to cross compiling as > works ok as 64bit compile > > Compile Project, Mode: Lin-Intel-32, CPU: i386, Target: LxAazLMA: Exit > code 256, Errors: 1, Warnings: 55, Hints: 204 > Error: Error while linking > > Are there any logs created by Laz/fpc that would help find what is > missing / wrong with my cross compile load ? > > Thanks - SteveG -- Péter Gábor ptrg at freemail.hu From dezlov at gmail.com Fri May 12 21:42:33 2017 From: dezlov at gmail.com (Denis Kozlov) Date: Fri, 12 May 2017 20:42:33 +0100 Subject: [Lazarus] TEdit appears empty when text is too long In-Reply-To: <3c60f0a4-19d0-ee8e-6dc5-44b182bbd98a@ya.ru> References: <4ab166be-91e3-196d-5dad-5b4ad8d9970d@gmail.com> <3c60f0a4-19d0-ee8e-6dc5-44b182bbd98a@ya.ru> Message-ID: <9eaa58a3-9f26-c8e7-3403-8aeb160be71b@gmail.com> Thanks. This seems to confirm my theory. On 12/05/2017 11:15, Alexey via Lazarus wrote: > I only say that ATBinHex component cannot draw too long lines (by > DrawTextW? TextOutW?) when API takes more than 4K chars (fixed to > using only small cnt of chars). > > > On 12.05.2017 02:10, Denis Kozlov via Lazarus wrote: >> width of entire text content, as opposed to just the small visible part. > From dezlov at gmail.com Fri May 12 21:44:09 2017 From: dezlov at gmail.com (Denis Kozlov) Date: Fri, 12 May 2017 20:44:09 +0100 Subject: [Lazarus] TEdit appears empty when text is too long In-Reply-To: <4ab166be-91e3-196d-5dad-5b4ad8d9970d@gmail.com> References: <4ab166be-91e3-196d-5dad-5b4ad8d9970d@gmail.com> Message-ID: <0f01868c-09cc-9150-e6b4-f5e29989973c@gmail.com> I have tested Windows API directly using DrawText, TextOut and ExtTextOut functions - they all suffer from this problem. The problem is bound by the total width of the drawn text (not just the small visible portion), where beyond some point it breaks. There appears to be no feasible workaround. It may be possible to programmatically break apart long text and draw it in chunks, but that is ugly and only addresses the symptoms of an unstable problem within Windows platform. Moving on now... Denis On 12/05/2017 00:10, Denis Kozlov wrote: > Hi, > > Has anybody experienced this problem or might know what is going on here? > > At around 5K characters the content of TEdit suddenly appears > empty/blank (visually). The content is correct when retrieved > programmatically. If enough characters are removed (programmatically) > the content will show up again. Changing the font size changes this > limit, where the limit is lower for a larger font size. > > It is as if the issue is bound by the visual width of entire text > content, as opposed to just the small visible part. > > Tested on Windows 7: > Lazarus 1.4.4 r49931 FPC 2.6.4 i386-win32-win32/win64 > Lazarus 1.6.4 r54278 FPC 3.0.2 i386-win32-win32/win64 > Lazarus 1.9.0 r54874 FPC 3.0.2 i386-win32-win32/win64 > > Also tested with Delphi 7, where the limit appeared past 50K characters. > > Sample project is attached. > > I will appreciate any clues to what's going on here. > > Thanks, > Denis From steveg at nevets.com.au Fri May 12 21:52:47 2017 From: steveg at nevets.com.au (Steve Gatenby) Date: Sat, 13 May 2017 05:52:47 +1000 Subject: [Lazarus] Compiler errors In-Reply-To: References: <0d40b2b7-d77d-3d31-1e44-a19592ec0f37@nevets.com.au> Message-ID: <0e7d0630-3cad-a553-b8ba-969147b36414@nevets.com.au> On 05/12/2017 10:20 PM, Péter Gábor via Lazarus wrote: > Take a look at "View / Messages" windows where in the last few lines you > will see the cause. For example missing libraries or such. > > Use the context menu of Messages window to filter (show or hide) some > kind of messages.... > > 2017-05-12 11:30 keltezéssel, Steve Gatenby via Lazarus írta: >> I am compiling my project in i386 mode (on an x64 system) >> >> I receive the following error (abridged) related to cross compiling as >> works ok as 64bit compile >> >> Compile Project, Mode: Lin-Intel-32, CPU: i386, Target: LxAazLMA: Exit >> code 256, Errors: 1, Warnings: 55, Hints: 204 >> Error: Error while linking >> >> Are there any logs created by Laz/fpc that would help find what is >> missing / wrong with my cross compile load ? >> >> Thanks - SteveG > Thanks Peter - the total info available in the msgs window is Exit code 256, Errors: 1 Error: Error while linking Hoping to to find a log file from the linker as to what it was trying to do - still looking From juha.manninen62 at gmail.com Sat May 13 15:17:52 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Sat, 13 May 2017 16:17:52 +0300 Subject: [Lazarus] Wiki page "Unicode Support in Lazarus" improved Message-ID: I have simplified and improved the page http://wiki.freepascal.org/Unicode_Support_in_Lazarus I tried to move relevant information to the top and remove duplicate information. For example there is a short "Usage" section with simple rules and then: "These rules make most code already compatible with Delphi." which is pretty much what most people need to know. Please check. Juha From werner.pamler at freenet.de Sat May 13 17:55:00 2017 From: werner.pamler at freenet.de (Werner Pamler) Date: Sat, 13 May 2017 17:55:00 +0200 Subject: [Lazarus] Wiki page "Unicode Support in Lazarus" improved In-Reply-To: References: Message-ID: Am 13.05.2017 um 15:17 schrieb Juha Manninen via Lazarus: > I have simplified and improved the page > http://wiki.freepascal.org/Unicode_Support_in_Lazarus > > I tried to move relevant information to the top and remove duplicate > information. > For example there is a short "Usage" section with simple rules and then: > "These rules make most code already compatible with Delphi." > which is pretty much what most people need to know. * In section "Usage", "For string literals to work the source files must have UTF-8 encoding." - Add: "This is the default for source files written by Lazarus" - Otherwise people will begin to unnecessarily add these "$codepage utf8" directives. * In section "CodePoint functions for encoding agnostic code" I am missing information on how "ch" is to be declared (in my test: ch:char and ch:string are working; ch:widechar does not). * Good that the new page appears also in place of the old "Better Unicode Support..." page -------------- next part -------------- An HTML attachment was scrubbed... URL: From pascaldragon at googlemail.com Sat May 13 18:56:18 2017 From: pascaldragon at googlemail.com (Sven Barth) Date: Sat, 13 May 2017 18:56:18 +0200 Subject: [Lazarus] Wiki page "Unicode Support in Lazarus" improved In-Reply-To: References: Message-ID: Am 13.05.2017 17:57 schrieb "Werner Pamler via Lazarus" < lazarus at lists.lazarus-ide.org>: > > Am 13.05.2017 um 15:17 schrieb Juha Manninen via Lazarus: >> >> I have simplified and improved the page http://wiki.freepascal.org/Unicode_Support_in_Lazarus I tried to move relevant information to the top and remove duplicate information. For example there is a short "Usage" section with simple rules and then: "These rules make most code already compatible with Delphi." which is pretty much what most people need to know. > > > In section "Usage", "For string literals to work the source files must have UTF-8 encoding." - Add: "This is the default for source files written by Lazarus" - Otherwise people will begin to unnecessarily add these "$codepage utf8" directives. Warning: the compiler does *not* consider the file as UTF-8 without a BOM or a set codepage! Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From ptrg at freemail.hu Sat May 13 19:26:38 2017 From: ptrg at freemail.hu (=?UTF-8?B?UMOpdGVyIEfDoWJvcg==?=) Date: Sat, 13 May 2017 19:26:38 +0200 Subject: [Lazarus] Compiler errors In-Reply-To: <0e7d0630-3cad-a553-b8ba-969147b36414@nevets.com.au> References: <0d40b2b7-d77d-3d31-1e44-a19592ec0f37@nevets.com.au> <0e7d0630-3cad-a553-b8ba-969147b36414@nevets.com.au> Message-ID: <822301e5-d5e9-bd54-94ea-17c1cb4d2204@freemail.hu> It seems that you have hidden the messages (hints, warnings, errors, etc.). Check the -v (verbosity) option in your fpc.cfg (or .fpc.cfg on Linux) and your Project/Compiler options (Verbosity of course) in the IDE. 2017-05-12 21:52 keltezéssel, Steve Gatenby via Lazarus írta: > > > On 05/12/2017 10:20 PM, Péter Gábor via Lazarus wrote: >> Take a look at "View / Messages" windows where in the last few lines you >> will see the cause. For example missing libraries or such. >> >> Use the context menu of Messages window to filter (show or hide) some >> kind of messages.... >> >> 2017-05-12 11:30 keltezéssel, Steve Gatenby via Lazarus írta: >>> I am compiling my project in i386 mode (on an x64 system) >>> >>> I receive the following error (abridged) related to cross compiling as >>> works ok as 64bit compile >>> >>> Compile Project, Mode: Lin-Intel-32, CPU: i386, Target: LxAazLMA: Exit >>> code 256, Errors: 1, Warnings: 55, Hints: 204 >>> Error: Error while linking >>> >>> Are there any logs created by Laz/fpc that would help find what is >>> missing / wrong with my cross compile load ? >>> >>> Thanks - SteveG >> > > Thanks Peter - > the total info available in the msgs window is > > Exit code 256, Errors: 1 > Error: Error while linking > > Hoping to to find a log file from the linker as to what it was trying to > do - still looking -- Péter Gábor ptrg at freemail.hu From juha.manninen62 at gmail.com Sat May 13 19:27:05 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Sat, 13 May 2017 20:27:05 +0300 Subject: [Lazarus] Wiki page "Unicode Support in Lazarus" improved In-Reply-To: References: Message-ID: On Sat, May 13, 2017 at 6:55 PM, Werner Pamler via Lazarus wrote: > In section "Usage", "For string literals to work the source files must have > UTF-8 encoding." - Add: "This is the default for source files written by > Lazarus" - Otherwise people will begin to unnecessarily add these "$codepage > utf8" directives. Actually that was one more duplicate information and in a wrong place. It is explained in "String Literals" section. It is not part of simple rules because it happens automatically by default. Thanks for noticing. It appears to be more difficult to remove old text than to write new text. Don't know why... > In section "CodePoint functions for encoding agnostic code" I am missing > information on how "ch" is to be declared (in my test: ch:char and ch:string > are working; ch:widechar does not). I added variable types to the example. I plan to improve the codepoint section more. I will replace the page UTF8_strings_and_characters with a similar page that uses the LazUnicode encoding agnostic functions. Then the whole thing will be as Delphi compatible as possible. Juha From juha.manninen62 at gmail.com Sat May 13 19:35:58 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Sat, 13 May 2017 20:35:58 +0300 Subject: [Lazarus] Wiki page "Unicode Support in Lazarus" improved In-Reply-To: References: Message-ID: On Sat, May 13, 2017 at 7:56 PM, Sven Barth via Lazarus wrote: > Warning: the compiler does *not* consider the file as UTF-8 without a BOM or > a set codepage! Yes but that is a very misleading warning. The whole thing works without a BOM better than with it because of the "double cheat". See "String Literals" section for details. It is counter-intuitive and most people can just ignore it. With BOM it did not work for codepoints beyond BMP but that was fixed and backported to FPC 3.0.3, right? Juha From pascaldragon at googlemail.com Sat May 13 23:55:00 2017 From: pascaldragon at googlemail.com (Sven Barth) Date: Sat, 13 May 2017 23:55:00 +0200 Subject: [Lazarus] Wiki page "Unicode Support in Lazarus" improved In-Reply-To: References: Message-ID: Am 13.05.2017 19:45 schrieb "Juha Manninen via Lazarus" < lazarus at lists.lazarus-ide.org>: > With BOM it did not work for codepoints beyond BMP but that was fixed > and backported to FPC 3.0.3, right? Correct. Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveg at nevets.com.au Sun May 14 02:02:46 2017 From: steveg at nevets.com.au (Steve Gatenby) Date: Sun, 14 May 2017 10:02:46 +1000 Subject: [Lazarus] Compiler errors In-Reply-To: <822301e5-d5e9-bd54-94ea-17c1cb4d2204@freemail.hu> References: <0d40b2b7-d77d-3d31-1e44-a19592ec0f37@nevets.com.au> <0e7d0630-3cad-a553-b8ba-969147b36414@nevets.com.au> <822301e5-d5e9-bd54-94ea-17c1cb4d2204@freemail.hu> Message-ID: <1273733e-b343-698c-bb53-4f057e07f04d@nevets.com.au> Thanks. Have now included 'show all' in Lazarus, just need to find where/which fpc.cfg is used/created when using FpcupDeluxe (which is a really handy piece of programming on somebodys part). On 05/14/2017 03:26 AM, Péter Gábor via Lazarus wrote: > It seems that you have hidden the messages (hints, warnings, errors, etc.). > Check the -v (verbosity) option in your fpc.cfg (or .fpc.cfg on Linux) > and your Project/Compiler options (Verbosity of course) in the IDE. > > 2017-05-12 21:52 keltezéssel, Steve Gatenby via Lazarus írta: >> >> >> On 05/12/2017 10:20 PM, Péter Gábor via Lazarus wrote: >>> Take a look at "View / Messages" windows where in the last few lines you >>> will see the cause. For example missing libraries or such. >>> >>> Use the context menu of Messages window to filter (show or hide) some >>> kind of messages.... >>> >>> 2017-05-12 11:30 keltezéssel, Steve Gatenby via Lazarus írta: >>>> I am compiling my project in i386 mode (on an x64 system) >>>> >>>> I receive the following error (abridged) related to cross compiling as >>>> works ok as 64bit compile >>>> >>>> Compile Project, Mode: Lin-Intel-32, CPU: i386, Target: LxAazLMA: Exit >>>> code 256, Errors: 1, Warnings: 55, Hints: 204 >>>> Error: Error while linking >>>> >>>> Are there any logs created by Laz/fpc that would help find what is >>>> missing / wrong with my cross compile load ? >>>> >>>> Thanks - SteveG >>> >> >> Thanks Peter - >> the total info available in the msgs window is >> >> Exit code 256, Errors: 1 >> Error: Error while linking >> >> Hoping to to find a log file from the linker as to what it was trying to >> do - still looking > From Sascha.Hestermann at gmx.de Sun May 14 20:42:12 2017 From: Sascha.Hestermann at gmx.de (Gabor Boros) Date: Mon, 15 May 2017 03:42:12 +0900 Subject: [Lazarus] =?utf-8?q?=E2=98=AFuseful_information?= Message-ID: <1732524445.20170514214212@gmx.de> Dear! I know you were looking for that kind of information, I guess I've just found it, here, take a look http://seifq.homesincaldwellid.com All best, Gabor Boros Sent from Mail for Windows 10 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: BD26E536C1E1F9196D6BC67069334021.jpg Type: image/jpeg Size: 20067 bytes Desc: not available URL: From Sascha.Hestermann at gmx.de Sun May 14 20:42:26 2017 From: Sascha.Hestermann at gmx.de (John Landmesser) Date: Mon, 15 May 2017 03:42:26 +0900 Subject: [Lazarus] =?utf-8?b?4p2jdGhhbmtz?= Message-ID: <1784718288.20170514214226@gmx.de> Dear friend! Just wanted to tell you how thankful I am for all you do, please take a look at what I've made for you http://implication.chicagoproaudio.com Sincerely, John Landmesser From joshyfun at gmail.com Sun May 14 21:08:09 2017 From: joshyfun at gmail.com (=?UTF-8?Q?Jos=c3=a9_Mejuto?=) Date: Sun, 14 May 2017 21:08:09 +0200 Subject: [Lazarus] SPAM - Postfix master Message-ID: <1aa081c8-bdd3-075a-acba-395f4a4a7085@gmail.com> Hello, Can Postfix master ban 14.169.188.113 ? All "Gabor Boros" (I know he is not responsible) spam comes from that mail server (DNS name does not match IP, only reverse resolution) and it looks like a Fiber/DSL user in Vietnam. The IP is listed in at least 15 spam blacklists. -- From marc at dommelstein.nl Sun May 14 22:13:57 2017 From: marc at dommelstein.nl (Marc Weustink) Date: Sun, 14 May 2017 22:13:57 +0200 Subject: [Lazarus] SPAM - Postfix master In-Reply-To: <1aa081c8-bdd3-075a-acba-395f4a4a7085@gmail.com> References: <1aa081c8-bdd3-075a-acba-395f4a4a7085@gmail.com> Message-ID: <050411D9-9C44-4880-A293-98725EE0F7DB@dommelstein.nl> Thank for noticing. I didn't see them since they ended I my spambox Marc On May 14, 2017 9:08:09 PM GMT+02:00, "José Mejuto via Lazarus" wrote: >Hello, > >Can Postfix master ban 14.169.188.113 ? All "Gabor Boros" (I know he is > >not responsible) spam comes from that mail server (DNS name does not >match IP, only reverse resolution) and it looks like a Fiber/DSL user >in >Vietnam. > >The IP is listed in at least 15 spam blacklists. > >-- > >-- >_______________________________________________ >Lazarus mailing list >Lazarus at lists.lazarus-ide.org >http://lists.lazarus-ide.org/listinfo/lazarus From bartjunk64 at gmail.com Sun May 14 23:27:57 2017 From: bartjunk64 at gmail.com (Bart) Date: Sun, 14 May 2017 23:27:57 +0200 Subject: [Lazarus] Oproep aan alle Nederlandstalige Lazarusgebruikers (Attn: all Dutch Lazarus users) Message-ID: Beste allen, De Nederlandse vertaling van de Lazarus IDE laat nogal te wensen over. Slechts 27% van alle strings zijn vertaald. Ik vermoed dat de meesten onder ons,evenals ik, gewoen de engelse taal in de IDE gebruiken. Ik probeer een beetje zicht te krijgen op de zinvolheid van het vertalen van de IDE naar Nederlands. Ik wil een ieder van jullie dan ook dringend verzoeken om de enquête op het forum hierover (http://forum.lazarus.freepascal.org/index.php/topic,36881.0.html) in te vullen. Bij voorbaat mijn dank, Bart Follows English translation: --------------- Dear all, The Dutch translationo f the IDE is in a bad state. Only 27% of the strings are translated. I suspect that most of us, like me, just use the english language in the IDE. I would like to get some insight wether or not it is very usefull at this point in time to translate the IDE into Dutch. I therefore call upon all of you (Duthc lazarus users) to fill in the poll on http://forum.lazarus.freepascal.org/index.php/topic,36881.0.html Greetings, Bart From mailinglists at geldenhuys.co.uk Mon May 15 11:19:10 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 15 May 2017 10:19:10 +0100 Subject: [Lazarus] Oproep aan alle Nederlandstalige Lazarusgebruikers (Attn: all Dutch Lazarus users) In-Reply-To: References: Message-ID: <696939db-cec6-d52f-bbdd-8ffb7fcac1ec@geldenhuys.co.uk> Op 2017-05-14 22:27, het Bart geskryf: > Ik vermoed dat de meesten onder ons,evenals ik, gewoen de engelse taal > in de IDE gebruiken. Dit was ook my ervaring, toe ek Afrikaans met Lazarus IDE probeer gebruik het. Die terminologie was net te vreemd. So nou verkies ek om liewers Engels te gebruik. ;-) Groete, 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 fpc at microbizz.nl Mon May 15 11:39:55 2017 From: fpc at microbizz.nl (Adriaan van Os) Date: Mon, 15 May 2017 11:39:55 +0200 Subject: [Lazarus] Oproep aan alle Nederlandstalige Lazarusgebruikers (Attn: all Dutch Lazarus users) In-Reply-To: References: Message-ID: <5919776B.6070905@microbizz.nl> Bart via Lazarus wrote: > Ik vermoed dat de meesten onder ons,evenals ik, gewoen de engelse taal > in de IDE gebruiken. Ik zou ook noit een IDE in het Nederlands gebruiken. De systeemsoftware staat bij mij ingesteld op Engels. Vele tientallen jaren geleden had ik (in Finland) een fout in een (MS-DOS) programma als gevolg van een slechte vertaling (in het Nederlands) van een boek van Peter Norton. Sindsdien is Nederlands alleen nog iets voor de eindgebruiker ..... Hetzelfde geldt voor programmeren. Gewoon consequent de engelse termonologie gebruiken, anders wordt het een brabbeltaaltje, half engels, half iets anders. Met vriendelijke groet, Adriaan van Os From freepascal at ypa-software.de Mon May 15 22:57:51 2017 From: freepascal at ypa-software.de (Michael Fuchs) Date: Mon, 15 May 2017 22:57:51 +0200 Subject: [Lazarus] German lazarus forum down Message-ID: [Short English version below] Hallo allerseits, wie ihr vielleicht schon gemerkt habe, ist das deutschsprachige Lazarusforum schon wieder nicht erreichbar. Leider kann ich noch keine Prognose abgeben, wann wir wieder online sind. In der Zwischenzeit habe ich die Notfallseite https://www.lazarus-forum.de/ eingerichtet die zumindest eine Anlaufstelle für alle bieten soll, die nach dem Forum suchen und wissen wollen wie der aktuelle Status ist. Über diese Seite könnt ihr auch bei Fragen Kontakt mit mir und weiteren Forumsmitgliedern aufnehmen. [english version] The German lazarus forum is inaccessible. I have set up an emergency page (https://www.lazarus-forum.de/), which shows the actual state of our downtime. A contact possibility is also available. Greetings m.fuchs (mod of lazarusforum.de) From shokwave at gmx.net Tue May 16 09:29:01 2017 From: shokwave at gmx.net (shoKwave) Date: Tue, 16 May 2017 09:29:01 +0200 Subject: [Lazarus] German lazarus forum down In-Reply-To: References: Message-ID: <255c10df-c6d3-d5c2-12c2-1fdb6a653eb5@gmx.net> Danke, es beruhigt schon zu wissen, dass sich jemand darum kümmert. Gutes gelingen. Mfg Ingo Am 15.05.2017 um 22:57 schrieb Michael Fuchs via Lazarus: > [Short English version below] > > Hallo allerseits, > > wie ihr vielleicht schon gemerkt habe, ist das deutschsprachige > Lazarusforum schon wieder nicht erreichbar. Leider kann ich noch keine > Prognose abgeben, wann wir wieder online sind. > > In der Zwischenzeit habe ich die Notfallseite > > https://www.lazarus-forum.de/ > > eingerichtet die zumindest eine Anlaufstelle für alle bieten soll, die > nach dem Forum suchen und wissen wollen wie der aktuelle Status ist. > Über diese Seite könnt ihr auch bei Fragen Kontakt mit mir und weiteren > Forumsmitgliedern aufnehmen. > > > > [english version] > > The German lazarus forum is inaccessible. I have set up an emergency > page (https://www.lazarus-forum.de/), which shows the actual state of > our downtime. A contact possibility is also available. > > Greetings > m.fuchs (mod of lazarusforum.de) > > From m-w-vogel at gmx.de Tue May 16 11:13:27 2017 From: m-w-vogel at gmx.de (Michael W. Vogel) Date: Tue, 16 May 2017 11:13:27 +0200 Subject: [Lazarus] German lazarus forum down In-Reply-To: References: Message-ID: <8b198ad8-575d-7e00-adfa-5ffa9dfe42ca@gmx.de> Am 15.05.2017 um 22:57 schrieb Michael Fuchs via Lazarus: > wie ihr vielleicht schon gemerkt habe, ist das deutschsprachige > Lazarusforum schon wieder nicht erreichbar. Leider kann ich noch keine > Prognose abgeben, wann wir wieder online sind. Na hoffentlich müssen wir keine 300$ in Bitcoins spenden... Michl From mschnell at lumino.de Tue May 16 11:43:47 2017 From: mschnell at lumino.de (Michael Schnell) Date: Tue, 16 May 2017 11:43:47 +0200 Subject: [Lazarus] German lazarus forum down In-Reply-To: References: Message-ID: Vielen Dank für den Hinweis ! -Michael From mailinglists at geldenhuys.co.uk Tue May 16 15:23:03 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Tue, 16 May 2017 14:23:03 +0100 Subject: [Lazarus] German lazarus forum down In-Reply-To: <8b198ad8-575d-7e00-adfa-5ffa9dfe42ca@gmx.de> References: <8b198ad8-575d-7e00-adfa-5ffa9dfe42ca@gmx.de> Message-ID: <1ce5d548-8bdd-336b-b220-2cce7ae5cba5@geldenhuys.co.uk> On 2017-05-16 10:13, Michael W. Vogel via Lazarus wrote: > Na hoffentlich müssen wir keine 300$ in Bitcoins spenden... :-P Regards, Graeme From micsch at gmail.com Tue May 16 15:49:00 2017 From: micsch at gmail.com (micsch at gmail.com) Date: Tue, 16 May 2017 15:49:00 +0200 Subject: [Lazarus] German lazarus forum down In-Reply-To: References: Message-ID: <201705161549.00359.micsch@gmail.com> Danke für den Hinweis. From mlnglsts at bgss.hu Tue May 16 18:08:59 2017 From: mlnglsts at bgss.hu (Gabor Boros) Date: Tue, 16 May 2017 18:08:59 +0200 Subject: [Lazarus] fixes_1_8 - What happened with default height of DBGrid's rows? Message-ID: <9a4ecc0d-fde0-784a-46e8-78173eb8adc0@bgss.hu> Hi All, I switched from revision 54808 to 54920 and got different row heights. What happened? Is this a regression? Gabor -------------- next part -------------- A non-text attachment was scrubbed... Name: fixes_1_8_rev54808.png Type: image/png Size: 21958 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fixes_1_8_rev54920.png Type: image/png Size: 20208 bytes Desc: not available URL: From lazarus at kluug.net Tue May 16 18:13:37 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Tue, 16 May 2017 18:13:37 +0200 Subject: [Lazarus] fixes_1_8 - What happened with default height of DBGrid's rows? In-Reply-To: <9a4ecc0d-fde0-784a-46e8-78173eb8adc0@bgss.hu> References: <9a4ecc0d-fde0-784a-46e8-78173eb8adc0@bgss.hu> Message-ID: On 16.05.2017 18:08, Gabor Boros via Lazarus wrote: > Hi All, > > I switched from revision 54808 to 54920 and got different row heights. > What happened? Is this a regression? Probably yes and problably I am responsible. Please report to Mantis. Ondrej From mmgomez at outlook.com Tue May 16 19:44:12 2017 From: mmgomez at outlook.com (Martin Gomez) Date: Tue, 16 May 2017 17:44:12 +0000 Subject: [Lazarus] unsubscribe Message-ID: unsubscribe Sent from Mail for Windows 10 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlnglsts at bgss.hu Tue May 16 20:29:06 2017 From: mlnglsts at bgss.hu (Gabor Boros) Date: Tue, 16 May 2017 20:29:06 +0200 Subject: [Lazarus] fixes_1_8 - What happened with default height of DBGrid's rows? In-Reply-To: References: <9a4ecc0d-fde0-784a-46e8-78173eb8adc0@bgss.hu> Message-ID: <2ac8a454-4ed7-6a5e-8290-cbf6a2c701b7@bgss.hu> 2017. 05. 16. 18:13 keltezéssel, Ondrej Pokorny via Lazarus írta: > Probably yes and problably I am responsible. Please report to Mantis. Done: https://bugs.freepascal.org/view.php?id=31824 Gabor From michael at freepascal.org Tue May 16 20:44:49 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Tue, 16 May 2017 20:44:49 +0200 (CEST) Subject: [Lazarus] Form resize to standard size in IDE. In-Reply-To: References: <27e373f9-2d3e-99b3-8c41-b534500fa73f@holobit.net> <74ed64bf-ec48-da0c-8c00-09232ad36629@holobit.net> Message-ID: On Mon, 8 May 2017, zeljko wrote: > On 08.05.2017 15:51, Michael Van Canneyt wrote: > >> >> How can I investigate this ? Where can/should I put some writelns to see >> what is happening ? >> >> I don't mind helping out, but I need some pointers where to start. > > Gtk2WSForms.pp , line 168 see my comment about it. Seem that it's your > problem (my comment is about Mint16 WM + compositing). > Can you see if your wm name fits into > if (Copy(Gtk2WidgetSet.GetWindowManager,1,6) = 'mutter') then ... > Just put writeln('WM=',Gtk2WidgetSet.GetWindowManager) above that statement. I did that. I added a print of the GDK geometry. gdk geometry : 10,33,320,240 Warning: GDK_CONFIGURE: Designed form is misconfigured because of bad compositing manager (see issue #25473). Warning: GDK_CONFIGURE: Fixing problem by setting current LCL values l=655,t=220,r=1152,b=461 WM=mutter (muffin) gdk geometry : 10,33,320,240 At the following point I clicked the TLAbel button on the component palette, and the form was again resized to something 'too small': WM=mutter (muffin) gdk geometry : 10,33,497,241 AddComponent TLabel Parent=ReportPropertiesForm:TReportPropertiesForm 38,140,0,0 Parent is 'ReportPropertiesForm:TReportPropertiesForm' TObjectInspectorDlg.FillPersistentComboBox: Updating ComboBox with components WM=mutter (muffin) gdk geometry : 10,33,320,241 WM=mutter (muffin) gdk geometry : 10,33,320,240 The X,Y are of course completely bogus. After this, I disabled compositing in Mint, and the situation is slightly better. Now the window doesn't resize so much any more, but it still resizes. So the "if Gtk2WidgetSet.compositeManagerRunning then" can be removed in fact. Anything else I can do ? (except dumping linux mint, obviously...) Michael. From lazarus at kluug.net Tue May 16 20:52:18 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Tue, 16 May 2017 20:52:18 +0200 Subject: [Lazarus] Form resize to standard size in IDE. In-Reply-To: References: <74ed64bf-ec48-da0c-8c00-09232ad36629@holobit.net> Message-ID: <409132bc-c09a-436b-92f6-1cf9dcb40a01@kluug.net> On 16.05.2017 20:44, Michael Van Canneyt via Lazarus wrote: > Anything else I can do ? (except dumping linux mint, obviously...) Maybe this is an option for you until it gets properly fixed: you could build the IDE for Qt. (You can still develop your own applications for Gtk2 even if the IDE is built for Qt.) Ondrej From michael at freepascal.org Tue May 16 21:08:39 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Tue, 16 May 2017 21:08:39 +0200 (CEST) Subject: [Lazarus] Form resize to standard size in IDE. In-Reply-To: <409132bc-c09a-436b-92f6-1cf9dcb40a01@kluug.net> References: <74ed64bf-ec48-da0c-8c00-09232ad36629@holobit.net> <409132bc-c09a-436b-92f6-1cf9dcb40a01@kluug.net> Message-ID: On Tue, 16 May 2017, Ondrej Pokorny via Lazarus wrote: > On 16.05.2017 20:44, Michael Van Canneyt via Lazarus wrote: >> Anything else I can do ? (except dumping linux mint, obviously...) > > Maybe this is an option for you until it gets properly fixed: you could > build the IDE for Qt. (You can still develop your own applications for > Gtk2 even if the IDE is built for Qt.) I think that is a bad tactical move. It's better to keep nagging if you want things to get fixed sooner than later ;) What I don't get is: Why don't other programs in linux mint seem to have problems with this ? Surely, if the situation is that bad, then things would have been fixed a long time ago, no ? Michael. From lazarus at kluug.net Tue May 16 21:20:47 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Tue, 16 May 2017 21:20:47 +0200 Subject: [Lazarus] German lazarus forum down In-Reply-To: References: Message-ID: <1c374d4f-9fff-30f4-13ba-21c43ad1ed14@kluug.net> Schade, dass das Treffen so weit ist aus Tschechien :/ Sonst würde ich kommen. Lazarus 1.8 hat sicherlich einiges zu bieten. Ondrej From lazarus at kluug.net Tue May 16 21:26:04 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Tue, 16 May 2017 21:26:04 +0200 Subject: [Lazarus] Form resize to standard size in IDE. In-Reply-To: References: <74ed64bf-ec48-da0c-8c00-09232ad36629@holobit.net> <409132bc-c09a-436b-92f6-1cf9dcb40a01@kluug.net> Message-ID: On 16.05.2017 21:08, Michael Van Canneyt via Lazarus wrote: > Surely, if the situation is that bad, then things would have been fixed a > long time ago, no ? IIRC people complained about Gtk2 resizing their windows under some window managers for several years. If I am not mistaken nobody really tried to fix it. Ondrej From zeljko at holobit.net Tue May 16 21:39:40 2017 From: zeljko at holobit.net (zeljko) Date: Tue, 16 May 2017 21:39:40 +0200 Subject: [Lazarus] Form resize to standard size in IDE. In-Reply-To: References: <74ed64bf-ec48-da0c-8c00-09232ad36629@holobit.net> <409132bc-c09a-436b-92f6-1cf9dcb40a01@kluug.net> Message-ID: <6c8d5bf7-6517-0c86-2989-803ab879ab0c@holobit.net> On 16.05.2017 21:08, Michael Van Canneyt via Lazarus wrote: > What I don't get is: > > Why don't other programs in linux mint seem to have problems with this ? > Surely, if the situation is that bad, then things would have been fixed a > long time ago, no ? Just because other gtk2 programs on linux are mostly C (or whatever, but they aren't lcl based), and such programs use gtk2 "as is", without tricks to get gtk2 delphi (lcl) compatibile in case of events and order of events. zeljko From zeljko at holobit.net Tue May 16 21:42:16 2017 From: zeljko at holobit.net (zeljko) Date: Tue, 16 May 2017 21:42:16 +0200 Subject: [Lazarus] Form resize to standard size in IDE. In-Reply-To: References: <74ed64bf-ec48-da0c-8c00-09232ad36629@holobit.net> <409132bc-c09a-436b-92f6-1cf9dcb40a01@kluug.net> Message-ID: <587ad444-22b8-c218-cbee-00477dcb39a1@holobit.net> On 16.05.2017 21:26, Ondrej Pokorny via Lazarus wrote: > On 16.05.2017 21:08, Michael Van Canneyt via Lazarus wrote: >> Surely, if the situation is that bad, then things would have been fixed a >> long time ago, no ? > > IIRC people complained about Gtk2 resizing their windows under some > window managers for several years. If I am not mistaken nobody really > tried to fix it. Problem is not in fixing. When you fix eg this one which is Michael talking about, next year you'll have new one - as soon as new version of wm thinks that something can work in another way :) zeljko From mailinglists at geldenhuys.co.uk Tue May 16 21:57:57 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Tue, 16 May 2017 20:57:57 +0100 Subject: [Lazarus] Form resize to standard size in IDE. In-Reply-To: <409132bc-c09a-436b-92f6-1cf9dcb40a01@kluug.net> References: <74ed64bf-ec48-da0c-8c00-09232ad36629@holobit.net> <409132bc-c09a-436b-92f6-1cf9dcb40a01@kluug.net> Message-ID: On 2017-05-16 19:52, Ondrej Pokorny via Lazarus wrote: >> Anything else I can do ? (except dumping linux mint, obviously...) > Maybe this is an option for you until it gets properly fixed: I agree with Michael... Dumping your OS of choice is not a solution. I would rather nag until the bug is fixed. ;-) @Michael: You could always try JWM (Joe's Window Manager). Thus you keep your OS of choice, just don't use Gnome as desktop environment, but rather a good old-school style Window Manager instead. JWM is extremely light weight (only uses 8MB of RAM), is really simple to even compile from the command line (though most distros should have it in there package managers). Configuration is via a simple XML file. It has a built-it taskbar, virtual desktops, "start menu" anywhere when you click on the desktop background etc. I've used JWM for years, even under Ubuntu Linux (now using FreeBSD), and it has never failed or disappointed me. 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 nc-gaertnma at netcologne.de Wed May 17 14:39:28 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Wed, 17 May 2017 14:39:28 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 Message-ID: <20170517143928.1d2588e4@limapholos.matflo.wg> The Lazarus team is glad to announce the first release candidate of Lazarus 1.8. This release was built with FPC 3.0.2. The previous release Lazarus 1.6.4 was built with FPC 3.0.2 too. The Linux releases are built with FPC 3.0.3 r36152 due to bug https://bugs.freepascal.org/view.php?id=31629 Here is the list of fixes for Lazarus 1.8.x: http://wiki.freepascal.org/Lazarus_1.8_fixes_branch Here is the list of changes for Lazarus and Free Pascal: http://wiki.lazarus.freepascal.org/Lazarus_1.8.0_release_notes http://wiki.lazarus.freepascal.org/User_Changes_3.0.2 The release is available for download on SourceForge: http://sourceforge.net/projects/lazarus/files/ Choose your CPU, OS, distro and then the "Lazarus 1.8 RC1" directory. Checksums for the SourceForge files: http://www.lazarus-ide.org/index.php?page=checksums#1_8_0 Minimum requirements: Windows: 2k, XP, Vista, 7, 8, 8.1 and 10, 32 or 64bit. FreeBSD/Linux: gtk 2.8 for gtk2, qt4.5 for qt, qt5.2 for qt5, 32 or 64bit. Mac OS X: 10.5 to 10.12, LCL only 32bit, non LCL apps can be 64bit. The svn tag is http://svn.freepascal.org/svn/lazarus/tags/lazarus_1_8_0_RC1 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://mirrors.iwi.me/lazarus/ == Why should everybody (including you) test the release candidate? == In the past weeks the Lazarus team has stabilized the 1.8 fixes branch. The resulting 1.8RC1 is now stable enough to be used by any one for test purposes. However many of the fixes and new features that where committed since the release of 1.6 required changes to the code of existing features too. While we have tested those ourself, there may still be problems that only occur with very specific configurations or one project in a million. Yes, it may be that you are the only person with a project, that will not work in the new IDE. So if you do not test, we can not fix it. Please do not wait for the final release, in order to test. It may be too late. Once the release is out we will have to be more selective about which fixes can be merged for further 1.8.x releases. So it may be, that we can not merge the fix you require. And then you will miss out on all the new features. == How to test == Download and install the 1.8 RC1. - On Windows you can install as a 2ndary install, that will not affect your current install: http://wiki.lazarus.freepascal.org/Multiple_Lazarus#Installation_of_multiple_Lazarus - On other platforms, if you install to a new location you need to use --primary-config-path In either case you should make backups. (including your primary config) Open your project in the current Lazarus (1.6.x), and use "Publish Project" from the project menu. This creates a clean copy of your project. You can then open that copy in the RC1. Please test: - If you can edit forms in the designer - rename components / change properties in Object inspector / Add new events - Add components to form / Move components on form - Frames, if you use them - If you can navigate the source code (e.g. jump to implementation) - Auto completion in source code - Compile, debug and run - Anything else you use in your daily work Mattias From zeljko at holobit.net Wed May 17 15:26:14 2017 From: zeljko at holobit.net (zeljko) Date: Wed, 17 May 2017 15:26:14 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <20170517143928.1d2588e4@limapholos.matflo.wg> References: <20170517143928.1d2588e4@limapholos.matflo.wg> Message-ID: On 17.05.2017 14:39, Mattias Gaertner via Lazarus wrote: > > The Lazarus team is glad to announce the first release candidate of > Lazarus 1.8. > > This release was built with FPC 3.0.2. > The previous release Lazarus 1.6.4 was built with FPC 3.0.2 too. > The Linux releases are built with FPC 3.0.3 r36152 due to bug > https://bugs.freepascal.org/view.php?id=31629 > > Here is the list of fixes for Lazarus 1.8.x: > http://wiki.freepascal.org/Lazarus_1.8_fixes_branch > > Here is the list of changes for Lazarus and Free Pascal: > http://wiki.lazarus.freepascal.org/Lazarus_1.8.0_release_notes > http://wiki.lazarus.freepascal.org/User_Changes_3.0.2 > > The release is available for download on SourceForge: > http://sourceforge.net/projects/lazarus/files/ > > Choose your CPU, OS, distro and then the "Lazarus 1.8 RC1" directory. > > Checksums for the SourceForge files: > http://www.lazarus-ide.org/index.php?page=checksums#1_8_0 > > Minimum requirements: > > Windows: > 2k, XP, Vista, 7, 8, 8.1 and 10, 32 or 64bit. > > FreeBSD/Linux: > gtk 2.8 for gtk2, qt4.5 for qt, qt5.2 for qt5, 32 or 64bit. Not good. Qt-5.6 is minimum required version (5.6.xx is LTS) not qt5.2 :) zeljko From nc-gaertnma at netcologne.de Wed May 17 16:29:26 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Wed, 17 May 2017 16:29:26 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 Message-ID: <20170517162926.1605079a@limapholos.matflo.wg> Here is the fixed version with qt5.6 and no dfmk.hu: The Lazarus team is glad to announce the first release candidate of Lazarus 1.8. This release was built with FPC 3.0.2. The previous release Lazarus 1.6.4 was built with FPC 3.0.2 too. The Linux releases are built with FPC 3.0.3 r36152 due to bug https://bugs.freepascal.org/view.php?id=31629 Here is the list of fixes for Lazarus 1.8.x: http://wiki.freepascal.org/Lazarus_1.8_fixes_branch Here is the list of changes for Lazarus and Free Pascal: http://wiki.lazarus.freepascal.org/Lazarus_1.8.0_release_notes http://wiki.lazarus.freepascal.org/User_Changes_3.0.2 The release is available for download on SourceForge: http://sourceforge.net/projects/lazarus/files/ Choose your CPU, OS, distro and then the "Lazarus 1.8 RC1" directory. Checksums for the SourceForge files: http://www.lazarus-ide.org/index.php?page=checksums#1_8_0 Minimum requirements: Windows: 2k, XP, Vista, 7, 8, 8.1 and 10, 32 or 64bit. FreeBSD/Linux: gtk 2.8 for gtk2, qt4.5 for qt, qt5.6 for qt5, 32 or 64bit. Mac OS X: 10.5 to 10.12, LCL only 32bit, non LCL apps can be 64bit. The svn tag is http://svn.freepascal.org/svn/lazarus/tags/lazarus_1_8_0_RC1 For people who are blocked by SF, the Lazarus releases from SourceForge are mirrored at: ftp://ftp.freepascal.org/pub/lazarus/releases/ and later at (after some time for synchronization) http://mirrors.iwi.me/lazarus/ == Why should everybody (including you) test the release candidate? == In the past weeks the Lazarus team has stabilized the 1.8 fixes branch. The resulting 1.8RC1 is now stable enough to be used by any one for test purposes. However many of the fixes and new features that where committed since the release of 1.6 required changes to the code of existing features too. While we have tested those ourself, there may still be problems that only occur with very specific configurations or one project in a million. Yes, it may be that you are the only person with a project, that will not work in the new IDE. So if you do not test, we can not fix it. Please do not wait for the final release, in order to test. It may be too late. Once the release is out we will have to be more selective about which fixes can be merged for further 1.8.x releases. So it may be, that we can not merge the fix you require. And then you will miss out on all the new features. == How to test == Download and install the 1.8 RC1. - On Windows you can install as a 2ndary install, that will not affect your current install: http://wiki.lazarus.freepascal.org/Multiple_Lazarus#Installation_of_multiple_Lazarus - On other platforms, if you install to a new location you need to use --primary-config-path In either case you should make backups. (including your primary config) Open your project in the current Lazarus (1.6.x), and use "Publish Project" from the project menu. This creates a clean copy of your project. You can then open that copy in the RC1. Please test: - If you can edit forms in the designer - rename components / change properties in Object inspector / Add new events - Add components to form / Move components on form - Frames, if you use them - If you can navigate the source code (e.g. jump to implementation) - Auto completion in source code - Compile, debug and run - Anything else you use in your daily work Mattias From luca at wetron.es Wed May 17 16:31:33 2017 From: luca at wetron.es (Luca Olivetti) Date: Wed, 17 May 2017 16:31:33 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <20170517143928.1d2588e4@limapholos.matflo.wg> References: <20170517143928.1d2588e4@limapholos.matflo.wg> Message-ID: <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> El 17/05/17 a les 14:39, Mattias Gaertner via Lazarus ha escrit: > == Why should everybody (including you) test the release candidate? == I didn't test it yet but I checked it out from svn and I see that the patch here https://bugs.freepascal.org/view.php?id=30931 isn't included. Is this version still supposed to work with fpc 2.6.4? 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 Wed May 17 16:34:14 2017 From: luca at wetron.es (Luca Olivetti) Date: Wed, 17 May 2017 16:34:14 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> Message-ID: <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> El 17/05/17 a les 16:31, Luca Olivetti via Lazarus ha escrit: > El 17/05/17 a les 14:39, Mattias Gaertner via Lazarus ha escrit: > >> == Why should everybody (including you) test the release candidate? == > > I didn't test it yet but I checked it out from svn and I see that the > patch here > > https://bugs.freepascal.org/view.php?id=30931 > > isn't included. > > Is this version still supposed to work with fpc 2.6.4? OK, I see now that it doesn't build with fpc 2.6.4 :-( Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From nc-gaertnma at netcologne.de Wed May 17 16:39:07 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Wed, 17 May 2017 16:39:07 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> Message-ID: <20170517163907.22d49fcb@limapholos.matflo.wg> On Wed, 17 May 2017 16:31:33 +0200 Luca Olivetti via Lazarus wrote: > El 17/05/17 a les 14:39, Mattias Gaertner via Lazarus ha escrit: > > > == Why should everybody (including you) test the release candidate? == > > I didn't test it yet but I checked it out from svn and I see that the > patch here > > https://bugs.freepascal.org/view.php?id=30931 > > isn't included. > > Is this version still supposed to work with fpc 2.6.4? Yes. I applied the patch. Thank You! Mattias From luca at wetron.es Wed May 17 16:42:08 2017 From: luca at wetron.es (Luca Olivetti) Date: Wed, 17 May 2017 16:42:08 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <20170517163907.22d49fcb@limapholos.matflo.wg> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <20170517163907.22d49fcb@limapholos.matflo.wg> Message-ID: El 17/05/17 a les 16:39, Mattias Gaertner via Lazarus ha escrit: > On Wed, 17 May 2017 16:31:33 +0200 > Luca Olivetti via Lazarus wrote: > >> El 17/05/17 a les 14:39, Mattias Gaertner via Lazarus ha escrit: >> >>> == Why should everybody (including you) test the release candidate? == >> >> I didn't test it yet but I checked it out from svn and I see that the >> patch here >> >> https://bugs.freepascal.org/view.php?id=30931 >> >> isn't included. >> >> Is this version still supposed to work with fpc 2.6.4? > > Yes. Well, in that case you'll have to comment/ifdef the use of "Default" in components/codetools/finddeclarationtool.pas It seems it's just used to silence a warning. > > I applied the patch. Thank You! Thank you -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From nc-gaertnma at netcologne.de Wed May 17 16:48:46 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Wed, 17 May 2017 16:48:46 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> Message-ID: <20170517164846.371e6245@limapholos.matflo.wg> On Wed, 17 May 2017 16:34:14 +0200 Luca Olivetti via Lazarus wrote: >[...] > > Is this version still supposed to work with fpc 2.6.4? > > OK, I see now that it doesn't build with fpc 2.6.4 :-( Fixed. The Lazarus devels only support the last two FPC releases, which means 3.0.0 and 3.0.2. But as long as FPC 2.6.4 only needs a few IFDEFs, patches are welcome. Mattias From luca at wetron.es Wed May 17 17:29:20 2017 From: luca at wetron.es (Luca Olivetti) Date: Wed, 17 May 2017 17:29:20 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <20170517164846.371e6245@limapholos.matflo.wg> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> <20170517164846.371e6245@limapholos.matflo.wg> Message-ID: El 17/05/17 a les 16:48, Mattias Gaertner via Lazarus ha escrit: > On Wed, 17 May 2017 16:34:14 +0200 > Luca Olivetti via Lazarus wrote: > >> [...] >>> Is this version still supposed to work with fpc 2.6.4? >> >> OK, I see now that it doesn't build with fpc 2.6.4 :-( > > Fixed. > > The Lazarus devels only support the last two FPC releases, which means > 3.0.0 and 3.0.2. > But as long as FPC 2.6.4 only needs a few IFDEFs, patches are welcome. Ok. A thing that broke from lazarus 1.6.4 is TLabel.OptimalFill. It seems that, depending on the width of the label it just uses a tiny amount of space, e.g., I put a label with the caption xxxx, height 140. With width 200 the four x fill all the horizontal space, if I change it to 300 they just occupy the top left corner (see attached image). See also the bogus handles (is that the correct name?) in the middle of the label. I saw those for quite a while (in lazarus 1.6.4) but it didn't bother me. This is on windows 7 32 bits. Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 -------------- next part -------------- A non-text attachment was scrubbed... Name: optimalfill.png Type: image/png Size: 4479 bytes Desc: not available URL: From luca at wetron.es Wed May 17 17:38:17 2017 From: luca at wetron.es (Luca Olivetti) Date: Wed, 17 May 2017 17:38:17 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> <20170517164846.371e6245@limapholos.matflo.wg> Message-ID: El 17/05/17 a les 17:29, Luca Olivetti via Lazarus ha escrit: > El 17/05/17 a les 16:48, Mattias Gaertner via Lazarus ha escrit: >> On Wed, 17 May 2017 16:34:14 +0200 >> Luca Olivetti via Lazarus wrote: >> >>> [...] >>>> Is this version still supposed to work with fpc 2.6.4? >>> >>> OK, I see now that it doesn't build with fpc 2.6.4 :-( >> >> Fixed. >> >> The Lazarus devels only support the last two FPC releases, which means >> 3.0.0 and 3.0.2. >> But as long as FPC 2.6.4 only needs a few IFDEFs, patches are welcome. > > Ok. > A thing that broke from lazarus 1.6.4 is TLabel.OptimalFill. > It seems that, depending on the width of the label it just uses a tiny > amount of space, e.g., I put a label with the caption xxxx, height 140. > With width 200 the four x fill all the horizontal space, if I change it > to 300 they just occupy the top left corner (see attached image). FWIW it does the same with linux/gtk2 and, boy, the ide is *ugly*: giant, blurred, icons everywhere, giant fonts in the tabs of the components' palette, giant fonts in the object inspector...you get the drift. The fonts in the editor seems fine, but maybe it's because I changed the default a long time ago. -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 -------------- next part -------------- A non-text attachment was scrubbed... Name: uglyide.png Type: image/png Size: 61670 bytes Desc: not available URL: From lazarus at kluug.net Wed May 17 17:43:43 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Wed, 17 May 2017 17:43:43 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> <20170517164846.371e6245@limapholos.matflo.wg> Message-ID: On 17.05.2017 17:38, Luca Olivetti via Lazarus wrote: > FWIW it does the same with linux/gtk2 and, boy, the ide is *ugly*: > giant, blurred, icons everywhere, giant fonts in the tabs of the > components' palette, giant fonts in the object inspector...you get the > drift. > The fonts in the editor seems fine, but maybe it's because I changed > the default a long time ago. What is your DPI settings? Ondrej From luca at wetron.es Wed May 17 17:47:53 2017 From: luca at wetron.es (Luca Olivetti) Date: Wed, 17 May 2017 17:47:53 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> <20170517164846.371e6245@limapholos.matflo.wg> Message-ID: El 17/05/17 a les 17:43, Ondrej Pokorny via Lazarus ha escrit: > On 17.05.2017 17:38, Luca Olivetti via Lazarus wrote: >> FWIW it does the same with linux/gtk2 and, boy, the ide is *ugly*: >> giant, blurred, icons everywhere, giant fonts in the tabs of the >> components' palette, giant fonts in the object inspector...you get the >> drift. >> The fonts in the editor seems fine, but maybe it's because I changed >> the default a long time ago. > > What is your DPI settings? Is this the correct way to check? $ xdpyinfo | grep dots resolution: 143x144 dots per inch Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From lazarus at kluug.net Wed May 17 17:52:54 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Wed, 17 May 2017 17:52:54 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> <20170517164846.371e6245@limapholos.matflo.wg> Message-ID: <5258f6ea-eef3-c384-97a3-c695dc4e803a@kluug.net> On 17.05.2017 17:47, Luca Olivetti via Lazarus wrote: > El 17/05/17 a les 17:43, Ondrej Pokorny via Lazarus ha escrit: >> On 17.05.2017 17:38, Luca Olivetti via Lazarus wrote: >>> FWIW it does the same with linux/gtk2 and, boy, the ide is *ugly*: >>> giant, blurred, icons everywhere, giant fonts in the tabs of the >>> components' palette, giant fonts in the object inspector...you get >>> the drift. >>> The fonts in the editor seems fine, but maybe it's because I changed >>> the default a long time ago. >> >> What is your DPI settings? > > Is this the correct way to check? Yes it is. > $ xdpyinfo | grep dots > resolution: 143x144 dots per inch You use 150% scaling (96 DPI = 100%), so Lazarus is also scaled by 150%. It's a new feature :) Ondrej From luca at wetron.es Wed May 17 18:55:47 2017 From: luca at wetron.es (Luca Olivetti) Date: Wed, 17 May 2017 18:55:47 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <5258f6ea-eef3-c384-97a3-c695dc4e803a@kluug.net> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> <20170517164846.371e6245@limapholos.matflo.wg> <5258f6ea-eef3-c384-97a3-c695dc4e803a@kluug.net> Message-ID: <668714f9-3fc0-cef9-f6c2-53557cbfc3c8@wetron.es> El 17/05/17 a les 17:52, Ondrej Pokorny via Lazarus ha escrit: > On 17.05.2017 17:47, Luca Olivetti via Lazarus wrote: >> El 17/05/17 a les 17:43, Ondrej Pokorny via Lazarus ha escrit: >>> On 17.05.2017 17:38, Luca Olivetti via Lazarus wrote: >>>> FWIW it does the same with linux/gtk2 and, boy, the ide is *ugly*: >>>> giant, blurred, icons everywhere, giant fonts in the tabs of the >>>> components' palette, giant fonts in the object inspector...you get >>>> the drift. >>>> The fonts in the editor seems fine, but maybe it's because I changed >>>> the default a long time ago. >>> >>> What is your DPI settings? >> >> Is this the correct way to check? > > Yes it is. > >> $ xdpyinfo | grep dots >> resolution: 143x144 dots per inch > > You use 150% scaling (96 DPI = 100%), so Lazarus is also scaled by 150%. > > It's a new feature :) Well, if it is, it's broken: every other application (either kde or gtk) shows fine, the only ugly one is lazarus :-( OTOH in the plasma control panel I see no option to set the dpi, the only one I could find is "screen scaling" which is set at the lowest possible value (1), if I set it to 3 the preview shows elements (fonts, tabs, buttons, etc.) 3 times as big (duh!). There's a section to select the gtk theme but it doesn't have an option to select the dpi either (just the gtk2 theme, the gtk3 one and the font). Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From lazarus at kluug.net Wed May 17 19:05:56 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Wed, 17 May 2017 19:05:56 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <668714f9-3fc0-cef9-f6c2-53557cbfc3c8@wetron.es> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> <20170517164846.371e6245@limapholos.matflo.wg> <5258f6ea-eef3-c384-97a3-c695dc4e803a@kluug.net> <668714f9-3fc0-cef9-f6c2-53557cbfc3c8@wetron.es> Message-ID: <7c7c82f3-0bd3-cf7e-1015-0bb1ab36c39e@kluug.net> On 17.05.2017 18:55, Luca Olivetti via Lazarus wrote: > El 17/05/17 a les 17:52, Ondrej Pokorny via Lazarus ha escrit: >> You use 150% scaling (96 DPI = 100%), so Lazarus is also scaled by 150%. >> >> It's a new feature :) > > Well, if it is, it's broken: every other application (either kde or > gtk) shows fine, the only ugly one is lazarus :-( > OTOH in the plasma control panel I see no option to set the dpi, the > only one I could find is "screen scaling" which is set at the lowest > possible value (1), if I set it to 3 the preview shows elements > (fonts, tabs, buttons, etc.) 3 times as big (duh!). > There's a section to select the gtk theme but it doesn't have an > option to select the dpi either (just the gtk2 theme, the gtk3 one and > the font). It looks to me like this issue: https://mantis.freepascal.org/view.php?id=31199 Linux is doing something very not-standard again :/ (Having various settings for DPI...) Ondrej From luca at wetron.es Wed May 17 19:08:26 2017 From: luca at wetron.es (Luca Olivetti) Date: Wed, 17 May 2017 19:08:26 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <668714f9-3fc0-cef9-f6c2-53557cbfc3c8@wetron.es> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> <20170517164846.371e6245@limapholos.matflo.wg> <5258f6ea-eef3-c384-97a3-c695dc4e803a@kluug.net> <668714f9-3fc0-cef9-f6c2-53557cbfc3c8@wetron.es> Message-ID: El 17/05/17 a les 18:55, Luca Olivetti via Lazarus ha escrit: > El 17/05/17 a les 17:52, Ondrej Pokorny via Lazarus ha escrit: >> On 17.05.2017 17:47, Luca Olivetti via Lazarus wrote: >>> El 17/05/17 a les 17:43, Ondrej Pokorny via Lazarus ha escrit: >>>> On 17.05.2017 17:38, Luca Olivetti via Lazarus wrote: >>>>> FWIW it does the same with linux/gtk2 and, boy, the ide is *ugly*: >>>>> giant, blurred, icons everywhere, giant fonts in the tabs of the >>>>> components' palette, giant fonts in the object inspector...you get >>>>> the drift. >>>>> The fonts in the editor seems fine, but maybe it's because I >>>>> changed the default a long time ago. >>>> >>>> What is your DPI settings? >>> >>> Is this the correct way to check? >> >> Yes it is. >> >>> $ xdpyinfo | grep dots >>> resolution: 143x144 dots per inch >> >> You use 150% scaling (96 DPI = 100%), so Lazarus is also scaled by 150%. >> >> It's a new feature :) > > Well, if it is, it's broken: every other application (either kde or gtk) > shows fine, the only ugly one is lazarus :-( > OTOH in the plasma control panel I see no option to set the dpi, the > only one I could find is "screen scaling" which is set at the lowest > possible value (1), if I set it to 3 the preview shows elements (fonts, > tabs, buttons, etc.) 3 times as big (duh!). > There's a section to select the gtk theme but it doesn't have an option > to select the dpi either (just the gtk2 theme, the gtk3 one and the font). The ide compiled with the qt widgetset doesn't show the same problem (though it doesn't seem to be using the same fonts as other kde applications) Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 -------------- next part -------------- A non-text attachment was scrubbed... Name: notsouglybutnotquiteright.png Type: image/png Size: 20700 bytes Desc: not available URL: From zeljko at holobit.net Wed May 17 19:19:28 2017 From: zeljko at holobit.net (zeljko) Date: Wed, 17 May 2017 19:19:28 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> <20170517164846.371e6245@limapholos.matflo.wg> <5258f6ea-eef3-c384-97a3-c695dc4e803a@kluug.net> <668714f9-3fc0-cef9-f6c2-53557cbfc3c8@wetron.es> Message-ID: <14a993d8-ea6b-8426-15b8-a9d96f9c3a83@holobit.net> On 17.05.2017 19:08, Luca Olivetti via Lazarus wrote: > The ide compiled with the qt widgetset doesn't show the same problem > (though it doesn't seem to be using the same fonts as other kde > applications) KDE Plasma is using Qt5, but ide is Qt4, so in Qt4 config you can set same fonts as they are in KDE Plasma and they will be exactly same. It's bug in KDE, since applying any setting to Qt5 (via KDE settings), should apply same applicable settings for Qt4 applications. Besides that, you can build cbindings for Qt5 and rebuild lazarus against Qt5 widgetset to see if there's any difference. zeljko From luca at wetron.es Wed May 17 19:22:58 2017 From: luca at wetron.es (Luca Olivetti) Date: Wed, 17 May 2017 19:22:58 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <7c7c82f3-0bd3-cf7e-1015-0bb1ab36c39e@kluug.net> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> <20170517164846.371e6245@limapholos.matflo.wg> <5258f6ea-eef3-c384-97a3-c695dc4e803a@kluug.net> <668714f9-3fc0-cef9-f6c2-53557cbfc3c8@wetron.es> <7c7c82f3-0bd3-cf7e-1015-0bb1ab36c39e@kluug.net> Message-ID: <9c7e0878-870d-0037-f664-44f161e1eb75@wetron.es> El 17/05/17 a les 19:05, Ondrej Pokorny via Lazarus ha escrit: > On 17.05.2017 18:55, Luca Olivetti via Lazarus wrote: >> El 17/05/17 a les 17:52, Ondrej Pokorny via Lazarus ha escrit: >>> You use 150% scaling (96 DPI = 100%), so Lazarus is also scaled by 150%. >>> >>> It's a new feature :) >> >> Well, if it is, it's broken: every other application (either kde or >> gtk) shows fine, the only ugly one is lazarus :-( >> OTOH in the plasma control panel I see no option to set the dpi, the >> only one I could find is "screen scaling" which is set at the lowest >> possible value (1), if I set it to 3 the preview shows elements >> (fonts, tabs, buttons, etc.) 3 times as big (duh!). >> There's a section to select the gtk theme but it doesn't have an >> option to select the dpi either (just the gtk2 theme, the gtk3 one and >> the font). > > It looks to me like this issue: > https://mantis.freepascal.org/view.php?id=31199 > > Linux is doing something very not-standard again :/ (Having various > settings for DPI...) Could be (though I'm using kubuntu instead of ubuntu so the settings are different) but every other application shows (apparently) fine.... 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 Wed May 17 19:59:58 2017 From: luca at wetron.es (Luca Olivetti) Date: Wed, 17 May 2017 19:59:58 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <14a993d8-ea6b-8426-15b8-a9d96f9c3a83@holobit.net> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> <20170517164846.371e6245@limapholos.matflo.wg> <5258f6ea-eef3-c384-97a3-c695dc4e803a@kluug.net> <668714f9-3fc0-cef9-f6c2-53557cbfc3c8@wetron.es> <14a993d8-ea6b-8426-15b8-a9d96f9c3a83@holobit.net> Message-ID: <0e3743c5-0a22-b6c1-0df3-100c8a63043c@wetron.es> El 17/05/17 a les 19:19, zeljko ha escrit: > On 17.05.2017 19:08, Luca Olivetti via Lazarus wrote: > >> The ide compiled with the qt widgetset doesn't show the same problem >> (though it doesn't seem to be using the same fonts as other kde >> applications) > > KDE Plasma is using Qt5, but ide is Qt4, so in Qt4 config you can set > same fonts as they are in KDE Plasma and they will be exactly same. > It's bug in KDE, since applying any setting to Qt5 (via KDE settings), > should apply same applicable settings for Qt4 applications. > Besides that, you can build cbindings for Qt5 and rebuild lazarus > against Qt5 widgetset to see if there's any difference. It took me a while to see that the c bindings are included, the README.txt in the lcl/interfaces/qt5 directory just says: "To use them you also need to download and install at appropriate place the libQt5Pas.so (linux) or Qt5Pas.dll (ms windows) or Qt5Pas.framework (Darwin). For more information see: http://wiki.lazarus.freepascal.org/index.php/Qt_Interface" So, after unsuccessfully compiling the beta version from http://users.telenet.be/Jan.Van.hijfte/qtforfpc/fpcqt4.html I finally found http://wiki.lazarus.freepascal.org/Qt5_Interface which says that the bindings are included :-/ They're building now. 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 Wed May 17 20:16:40 2017 From: luca at wetron.es (Luca Olivetti) Date: Wed, 17 May 2017 20:16:40 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <0e3743c5-0a22-b6c1-0df3-100c8a63043c@wetron.es> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> <20170517164846.371e6245@limapholos.matflo.wg> <5258f6ea-eef3-c384-97a3-c695dc4e803a@kluug.net> <668714f9-3fc0-cef9-f6c2-53557cbfc3c8@wetron.es> <14a993d8-ea6b-8426-15b8-a9d96f9c3a83@holobit.net> <0e3743c5-0a22-b6c1-0df3-100c8a63043c@wetron.es> Message-ID: <378f58ef-64da-7c98-e9fb-3452a63461a9@wetron.es> El 17/05/17 a les 19:59, Luca Olivetti via Lazarus ha escrit: > El 17/05/17 a les 19:19, zeljko ha escrit: >> On 17.05.2017 19:08, Luca Olivetti via Lazarus wrote: >> >>> The ide compiled with the qt widgetset doesn't show the same problem >>> (though it doesn't seem to be using the same fonts as other kde >>> applications) >> >> KDE Plasma is using Qt5, but ide is Qt4, so in Qt4 config you can set >> same fonts as they are in KDE Plasma and they will be exactly same. >> It's bug in KDE, since applying any setting to Qt5 (via KDE settings), >> should apply same applicable settings for Qt4 applications. >> Besides that, you can build cbindings for Qt5 and rebuild lazarus >> against Qt5 widgetset to see if there's any difference. > > > It took me a while to see that the c bindings are included, the > README.txt in the lcl/interfaces/qt5 directory just says: > > "To use them you also need to download and install > at appropriate place the libQt5Pas.so (linux) > or Qt5Pas.dll (ms windows) or Qt5Pas.framework (Darwin). > > For more information see: > http://wiki.lazarus.freepascal.org/index.php/Qt_Interface" > > So, after unsuccessfully compiling the beta version from > http://users.telenet.be/Jan.Van.hijfte/qtforfpc/fpcqt4.html I finally > found http://wiki.lazarus.freepascal.org/Qt5_Interface which says that > the bindings are included :-/ > They're building now. Excellent, this is OK, with my selected fonts and correctly sized icons. It still has the problem with optimalfill, so it's definitely not platform specific. Meanwhile I see that in the plasma font setting I have the dpi forced to 96, a setting that apparently is respected both by qt4 and qt5 (as well as gtk applications). 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 Wed May 17 20:22:41 2017 From: luca at wetron.es (Luca Olivetti) Date: Wed, 17 May 2017 20:22:41 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <378f58ef-64da-7c98-e9fb-3452a63461a9@wetron.es> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> <20170517164846.371e6245@limapholos.matflo.wg> <5258f6ea-eef3-c384-97a3-c695dc4e803a@kluug.net> <668714f9-3fc0-cef9-f6c2-53557cbfc3c8@wetron.es> <14a993d8-ea6b-8426-15b8-a9d96f9c3a83@holobit.net> <0e3743c5-0a22-b6c1-0df3-100c8a63043c@wetron.es> <378f58ef-64da-7c98-e9fb-3452a63461a9@wetron.es> Message-ID: El 17/05/17 a les 20:16, Luca Olivetti via Lazarus ha escrit: > Excellent, this is OK, with my selected fonts and correctly sized icons. > It still has the problem with optimalfill, so it's definitely not > platform specific. See https://youtu.be/NFZGVx7V2C0 Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From zeljko at holobit.net Wed May 17 20:31:52 2017 From: zeljko at holobit.net (zeljko) Date: Wed, 17 May 2017 20:31:52 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <0e3743c5-0a22-b6c1-0df3-100c8a63043c@wetron.es> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> <20170517164846.371e6245@limapholos.matflo.wg> <5258f6ea-eef3-c384-97a3-c695dc4e803a@kluug.net> <668714f9-3fc0-cef9-f6c2-53557cbfc3c8@wetron.es> <14a993d8-ea6b-8426-15b8-a9d96f9c3a83@holobit.net> <0e3743c5-0a22-b6c1-0df3-100c8a63043c@wetron.es> Message-ID: <6845ae3d-af86-ca43-51e4-6c6955386d8c@holobit.net> On 17.05.2017 19:59, Luca Olivetti wrote: > It took me a while to see that the c bindings are included, the > README.txt in the lcl/interfaces/qt5 directory just says: > > "To use them you also need to download and install > at appropriate place the libQt5Pas.so (linux) > or Qt5Pas.dll (ms windows) or Qt5Pas.framework (Darwin). > > For more information see: > http://wiki.lazarus.freepascal.org/index.php/Qt_Interface" > > So, after unsuccessfully compiling the beta version from > http://users.telenet.be/Jan.Van.hijfte/qtforfpc/fpcqt4.html I finally > found http://wiki.lazarus.freepascal.org/Qt5_Interface which says that > the bindings are included :-/ > They're building now. Thanks, I'll fix README.txt ... Jan stopped to support bindings for almost one year, so I've taken his latest Qt5 bindings an manually updated classes and everything and commited it into laz trunk.. You must build it at your own for now, but as soon as I stop update C part of bindings I'll build them for linux64,win32 and macosx qtcocoa 64bit and put it somewhere so ppl can download. I don't have any plans to build linux32 or mac32 (carbon) Qt5 C bindings atm. zeljko From zeljko at holobit.net Wed May 17 20:33:28 2017 From: zeljko at holobit.net (zeljko) Date: Wed, 17 May 2017 20:33:28 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <378f58ef-64da-7c98-e9fb-3452a63461a9@wetron.es> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> <20170517164846.371e6245@limapholos.matflo.wg> <5258f6ea-eef3-c384-97a3-c695dc4e803a@kluug.net> <668714f9-3fc0-cef9-f6c2-53557cbfc3c8@wetron.es> <14a993d8-ea6b-8426-15b8-a9d96f9c3a83@holobit.net> <0e3743c5-0a22-b6c1-0df3-100c8a63043c@wetron.es> <378f58ef-64da-7c98-e9fb-3452a63461a9@wetron.es> Message-ID: On 17.05.2017 20:16, Luca Olivetti via Lazarus wrote: > Meanwhile I see that in the plasma font setting I have the dpi forced to > 96, a setting that apparently is respected both by qt4 and qt5 (as well > as gtk applications). If it's forced than all qt based apps are using forced 96dpi. Even if you set some other dpi in console session, qtlcl app uses forced 96 dpi. zeljko From luca at wetron.es Wed May 17 20:37:36 2017 From: luca at wetron.es (Luca Olivetti) Date: Wed, 17 May 2017 20:37:36 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> <20170517164846.371e6245@limapholos.matflo.wg> <5258f6ea-eef3-c384-97a3-c695dc4e803a@kluug.net> <668714f9-3fc0-cef9-f6c2-53557cbfc3c8@wetron.es> <14a993d8-ea6b-8426-15b8-a9d96f9c3a83@holobit.net> <0e3743c5-0a22-b6c1-0df3-100c8a63043c@wetron.es> <378f58ef-64da-7c98-e9fb-3452a63461a9@wetron.es> Message-ID: <27232e82-dd25-79c8-2672-8e467074b3c3@wetron.es> El 17/05/17 a les 20:33, zeljko ha escrit: > On 17.05.2017 20:16, Luca Olivetti via Lazarus wrote: > >> Meanwhile I see that in the plasma font setting I have the dpi forced to >> 96, a setting that apparently is respected both by qt4 and qt5 (as well >> as gtk applications). > > If it's forced than all qt based apps are using forced 96dpi. > Even if you set some other dpi in console session, qtlcl app uses forced > 96 dpi. Yes, I unchecked the option and now even lazarus/qt5 is ugly :-) Now I see why I set (and forgot about) the option ;-) Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From Special at Joepgen.com Wed May 17 22:27:20 2017 From: Special at Joepgen.com (Joe) Date: Wed, 17 May 2017 22:27:20 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> Message-ID: <9ab6c229-3139-1061-d6f0-e8a6b8df795f@Joepgen.com> Am 17.05.2017 um 16:31 schrieb Luca Olivetti via Lazarus: > El 17/05/17 a les 14:39, Mattias Gaertner via Lazarus ha escrit: > >> == Why should everybody (including you) test the release candidate? == > > I didn't test it yet but I checked it out from svn and I see that the > patch here > > https://bugs.freepascal.org/view.php?id=30931 > > isn't included. > > Is this version still supposed to work with fpc 2.6.4? > > Bye Is this the correct way to report my finding? As a non professional I am not sure. Lazarus 1.8 RC1 under Win 10 (64): "GetEnvironmentVariable('computername')" doesn't work. When compiling, it returns "Error: Wrong number of Parameters specified for call to GetEnvironmentVariable". From friess at gmx.at Wed May 17 23:08:34 2017 From: friess at gmx.at (=?UTF-8?Q?Andreas_Frie=c3=9f?=) Date: Wed, 17 May 2017 23:08:34 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <20170517143928.1d2588e4@limapholos.matflo.wg> References: <20170517143928.1d2588e4@limapholos.matflo.wg> Message-ID: <71bc1b7f-adcc-8abb-5cf9-27745bcedb04@gmx.at> I see with the last patches something goes wrong after r54880 with frames and grid (specially TsWorkSheetGrid). Lazarus claims, the is no valid parent and didnot load and crash. It is only happen if you use frames ? The trouble is, i can only shutdown Lazarus with the Processmanger. Win10/64 with Lazarus 32/svn 1.9RC1 Andreas Any hints ? Am 17.05.2017 um 14:39 schrieb Mattias Gaertner via Lazarus: > The Lazarus team is glad to announce the first release candidate of > Lazarus 1.8. > > From badsectoracula at gmail.com Wed May 17 23:20:51 2017 From: badsectoracula at gmail.com (Kostas Michalopoulos) Date: Thu, 18 May 2017 00:20:51 +0300 Subject: [Lazarus] Patch for fixing the window resizes when switching components Message-ID: Hi all, So i finally figured out why this happens and the reason is the ShowWindow(Handle, SW_SHOWNORMAL) call made when selecting components (this is done to activate the designer form). Under Gtk2 this call always calls gtk_window_unmaximize (among others) but Gtk2 seems to have a bug that always tries to unmaximize the window regardless of its status - with some window managers (like Window Maker) this can cause the window to be resized. The bug is most likely with Gtk2 not ignoring the call for unmaximized windows, but since Gtk2's development has practically stopped (most recent changes are documentation and build fixes) and since Lazarus needs to work with 10+ year old versions of Gtk2, this needs to be addressed on the LCL side. Fortunately LCL already tracks the window state in the WindowState property, so at least for TCustomForm descendants (which would be almost all cases this is needed - 100% of the cases in design time where the bug is mostly visible) we can workaround this by not calling gtk_window_unmaximize for forms that aren't maximized. The description and patch can be found in Mantis here, as well as a video that shows the issue: https://bugs.freepascal.org/view.php?id=31832 The patch was made against SVN but should apply with 1.8RC1 since i originally wrote it there. Kostas -------------- next part -------------- An HTML attachment was scrubbed... URL: From badsectoracula at gmail.com Wed May 17 23:24:10 2017 From: badsectoracula at gmail.com (Kostas Michalopoulos) Date: Thu, 18 May 2017 00:24:10 +0300 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <71bc1b7f-adcc-8abb-5cf9-27745bcedb04@gmx.at> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <71bc1b7f-adcc-8abb-5cf9-27745bcedb04@gmx.at> Message-ID: I've noticed that the window shrinking bug in window maker with Gtk2 is still there, but i finally managed to figure it out and made a fix. I originally wrote the fix in 1.8RC1 so it should apply there, but the patch is against SVN. I posted a more detailed email in the mailing list, but here is the Mantis link https://bugs.freepascal.org/view.php?id=31832 I also see another issue with the form designer - when i have two forms open, despite which one i activated last, the one i created something first is always being focused even if i try to create something in the other form. Note that this happens in 1.8RC1 and SVN with and without the patch i mentioned above. Kostas On Thu, May 18, 2017 at 12:08 AM, Andreas Frieß via Lazarus < lazarus at lists.lazarus-ide.org> wrote: > I see with the last patches something goes wrong after r54880 with frames > and grid (specially TsWorkSheetGrid). > > Lazarus claims, the is no valid parent and didnot load and crash. It is > only happen if you use frames ? The trouble is, i can only shutdown Lazarus > with the Processmanger. > > Win10/64 with Lazarus 32/svn 1.9RC1 > > Andreas > > Any hints ? > > > Am 17.05.2017 um 14:39 schrieb Mattias Gaertner via Lazarus: > >> The Lazarus team is glad to announce the first release candidate of >> Lazarus 1.8. >> >> >> > -- > _______________________________________________ > 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 michael at freepascal.org Thu May 18 00:24:19 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Thu, 18 May 2017 00:24:19 +0200 (CEST) Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: References: <20170517143928.1d2588e4@limapholos.matflo.wg> <71bc1b7f-adcc-8abb-5cf9-27745bcedb04@gmx.at> Message-ID: On Thu, 18 May 2017, Kostas Michalopoulos via Lazarus wrote: > I've noticed that the window shrinking bug in window maker with Gtk2 is > still there, but i finally managed to figure it out and made a fix. I > originally wrote the fix in 1.8RC1 so it should apply there, but the patch > is against SVN. I posted a more detailed email in the mailing list, but > here is the Mantis link https://bugs.freepascal.org/view.php?id=31832 I think it would be very good to apply this patch for the release. Michael. From nc-gaertnma at netcologne.de Thu May 18 00:30:06 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Thu, 18 May 2017 00:30:06 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <9ab6c229-3139-1061-d6f0-e8a6b8df795f@Joepgen.com> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <9ab6c229-3139-1061-d6f0-e8a6b8df795f@Joepgen.com> Message-ID: <20170518003006.70d8edac@limapholos.matflo.wg> On Wed, 17 May 2017 22:27:20 +0200 Joe via Lazarus wrote: >[...] > Is this the correct way to report my finding? As a non professional I am > not sure. > > Lazarus 1.8 RC1 under Win 10 (64): Yes, although this is more exact: Help / About Lazarus / Right mouse click on logo / Copy version info to clipboard. > "GetEnvironmentVariable('computername')" doesn't work. > When compiling, it returns "Error: Wrong number of Parameters specified > for call to GetEnvironmentVariable". The SysUtils GetEnvironmentVariable expects one string. So, maybe you have somewhere another GetEnvironmentVariable? Use Find Declaration to find out. Mattias From werner.pamler at freenet.de Thu May 18 00:41:56 2017 From: werner.pamler at freenet.de (Werner Pamler) Date: Thu, 18 May 2017 00:41:56 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <71bc1b7f-adcc-8abb-5cf9-27745bcedb04@gmx.at> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <71bc1b7f-adcc-8abb-5cf9-27745bcedb04@gmx.at> Message-ID: Am 17.05.2017 um 23:08 schrieb Andreas Frieß via Lazarus: > I see with the last patches something goes wrong after r54880 with > frames and grid (specially TsWorkSheetGrid). > > Lazarus claims, the is no valid parent and didnot load and crash. It > is only happen if you use frames ? The trouble is, i can only shutdown > Lazarus with the Processmanger. > > Win10/64 with Lazarus 32/svn 1.9RC1 This is confusing: Are you using Laz trunk (v1.9) or 1.8RC1? I don't see an issue with WorksheetGrid on frames with Laz trunk. Can you post a demo? From nc-gaertnma at netcologne.de Thu May 18 01:17:38 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Thu, 18 May 2017 01:17:38 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <71bc1b7f-adcc-8abb-5cf9-27745bcedb04@gmx.at> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <71bc1b7f-adcc-8abb-5cf9-27745bcedb04@gmx.at> Message-ID: <20170518011738.175e8962@limapholos.matflo.wg> On Wed, 17 May 2017 23:08:34 +0200 Andreas Frieß via Lazarus wrote: > I see with the last patches something goes wrong after r54880 with > frames and grid (specially TsWorkSheetGrid). > > Lazarus claims, the is no valid parent and didnot load and crash. It is > only happen if you use frames ? The trouble is, i can only shutdown > Lazarus with the Processmanger. > > Win10/64 with Lazarus 32/svn 1.9RC1 > > Andreas > > Any hints ? Please create a bug report. Mattias From Special at Joepgen.com Thu May 18 01:34:54 2017 From: Special at Joepgen.com (Joe) Date: Thu, 18 May 2017 01:34:54 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <20170518003006.70d8edac@limapholos.matflo.wg> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <9ab6c229-3139-1061-d6f0-e8a6b8df795f@Joepgen.com> <20170518003006.70d8edac@limapholos.matflo.wg> Message-ID: <0c5932da-6ed7-e2cd-cfc6-57d29e8eb17c@Joepgen.com> Am 18.05.2017 um 00:30 schrieb Mattias Gaertner via Lazarus: > On Wed, 17 May 2017 22:27:20 +0200 > Joe via Lazarus wrote: > >> [...] >> Is this the correct way to report my finding? As a non professional I am >> not sure. >> >> Lazarus 1.8 RC1 under Win 10 (64): > Yes, although this is more exact: > Help / About Lazarus / Right mouse click on logo / Copy version info to > clipboard. > > >> "GetEnvironmentVariable('computername')" doesn't work. >> When compiling, it returns "Error: Wrong number of Parameters specified >> for call to GetEnvironmentVariable". > The SysUtils GetEnvironmentVariable expects one string. So, maybe you > have somewhere another GetEnvironmentVariable? > Use Find Declaration to find out. > > Mattias Mattias, Find Declaration shows two entries in file osutilsh.inc, lines 25 and 26: Function GetEnvironmentVariable(Const EnvVar : AnsiString) : AnsiString; Function GetEnvironmentVariable(Const EnvVar : UnicodeString) : UnicodeString; But Code Completion offers three functions named GetEnvironmentVariable: The Ansistring function and the Unicode String function above plus "GetEnvironmentVariable(lpName: LPCSTR; lpBuffer: LPSTR; nSize: DWORD): DWORD". Seems, Lazarus tries to use only the latter. No, I don't have another GetEnvironmentVariable. You can reproduce this easily: Put a TButton Button1 on a form. In the OnClick Event for this button write "Button1.Caption := GetEnvironmentVariable ('computername');" Version Info (Thank you for this hint): Lazarus 1.8.0RC1 r54919 FPC 3.0.2 x86_64-win64-win32/win64 Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From badsectoracula at gmail.com Thu May 18 01:43:10 2017 From: badsectoracula at gmail.com (Kostas Michalopoulos) Date: Thu, 18 May 2017 02:43:10 +0300 Subject: [Lazarus] Patch for fixing the window resizes when switching components In-Reply-To: References: Message-ID: I see the patch was added and Lazarus seems to work fine now, but the check was altered a little. The current check assumes that the Control will never be nil, but is this the case? I ask because i see in other places in the same source code file that there are checks for that - almost all calls to GetLCLObject either check for nil or use "if object is something then use object" (with the "is" operator returning false for nil, essentially making it an indirect test for nil). This might be just an instance defensive programming, but i think it is a good idea to bring this up. On Thu, May 18, 2017 at 12:20 AM, Kostas Michalopoulos < badsectoracula at gmail.com> wrote: > Hi all, > > So i finally figured out why this happens and the reason is the > ShowWindow(Handle, SW_SHOWNORMAL) call made when selecting components (this > is done to activate the designer form). > > Under Gtk2 this call always calls gtk_window_unmaximize (among others) but > Gtk2 seems to have a bug that always tries to unmaximize the window > regardless of its status - with some window managers (like Window Maker) > this can cause the window to be resized. The bug is most likely with Gtk2 > not ignoring the call for unmaximized windows, but since Gtk2's development > has practically stopped (most recent changes are documentation and build > fixes) and since Lazarus needs to work with 10+ year old versions of Gtk2, > this needs to be addressed on the LCL side. > > Fortunately LCL already tracks the window state in the WindowState > property, so at least for TCustomForm descendants (which would be almost > all cases this is needed - 100% of the cases in design time where the bug > is mostly visible) we can workaround this by not calling > gtk_window_unmaximize for forms that aren't maximized. > > The description and patch can be found in Mantis here, as well as a video > that shows the issue: > > https://bugs.freepascal.org/view.php?id=31832 > > The patch was made against SVN but should apply with 1.8RC1 since i > originally wrote it there. > > Kostas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lazarus at mfriebe.de Thu May 18 02:24:39 2017 From: lazarus at mfriebe.de (Martin Frb) Date: Thu, 18 May 2017 01:24:39 +0100 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <0c5932da-6ed7-e2cd-cfc6-57d29e8eb17c@Joepgen.com> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <9ab6c229-3139-1061-d6f0-e8a6b8df795f@Joepgen.com> <20170518003006.70d8edac@limapholos.matflo.wg> <0c5932da-6ed7-e2cd-cfc6-57d29e8eb17c@Joepgen.com> Message-ID: <4c08c405-f0de-1ed4-5475-51b0cb937b30@mfriebe.de> On 18/05/2017 00:34, Joe via Lazarus wrote: > But Code Completion offers three functions named GetEnvironmentVariable: > The Ansistring function and the Unicode String function above plus > "GetEnvironmentVariable(lpName: LPCSTR; lpBuffer: LPSTR; nSize: > DWORD): DWORD". Looks like you may have the unit "windows" in your uses clause. From lazarus at kluug.net Thu May 18 07:25:48 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Thu, 18 May 2017 07:25:48 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <71bc1b7f-adcc-8abb-5cf9-27745bcedb04@gmx.at> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <71bc1b7f-adcc-8abb-5cf9-27745bcedb04@gmx.at> Message-ID: On 17.05.2017 23:08, Andreas Frieß via Lazarus wrote: > I see with the last patches something goes wrong after r54880 with > frames and grid (specially TsWorkSheetGrid). > > Lazarus claims, the is no valid parent and didnot load and crash. It > is only happen if you use frames ? The trouble is, i can only shutdown > Lazarus with the Processmanger. > > Win10/64 with Lazarus 32/svn 1.9RC1 > > Andreas > > Any hints ? There may be troubles with the scaling code (that needs a parent). As Mattias already said - please report to mantis with a test application, thanks! Ondrej From friess at gmx.at Thu May 18 08:52:04 2017 From: friess at gmx.at (Andreas) Date: Thu, 18 May 2017 08:52:04 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: References: <20170517143928.1d2588e4@limapholos.matflo.wg> <71bc1b7f-adcc-8abb-5cf9-27745bcedb04@gmx.at> Message-ID: <0M1RHp-1dze5S0Ol7-00tVF2@mail.gmx.com> THX, this is a good hint for me ‚scaling code‘, so i can isolate that issue and test. If i can create a testapp, so send it to mantis. Andreas Gesendet von Mail für Windows 10 Von: Ondrej Pokorny via Lazarus Gesendet: Donnerstag, 18. Mai 2017 07:26 An: Lazarus mailing list Cc: Ondrej Pokorny Betreff: Re: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 On 17.05.2017 23:08, Andreas Frieß via Lazarus wrote: > I see with the last patches something goes wrong after r54880 with > frames and grid (specially TsWorkSheetGrid). > > Lazarus claims, the is no valid parent and didnot load and crash. It > is only happen if you use frames ? The trouble is, i can only shutdown > Lazarus with the Processmanger. > > Win10/64 with Lazarus 32/svn 1.9RC1 > > Andreas > > Any hints ? There may be troubles with the scaling code (that needs a parent). As Mattias already said - please report to mantis with a test application, thanks! Ondrej -- _______________________________________________ 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 luca at wetron.es Thu May 18 09:17:38 2017 From: luca at wetron.es (Luca Olivetti) Date: Thu, 18 May 2017 09:17:38 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> <20170517164846.371e6245@limapholos.matflo.wg> <5258f6ea-eef3-c384-97a3-c695dc4e803a@kluug.net> <668714f9-3fc0-cef9-f6c2-53557cbfc3c8@wetron.es> <14a993d8-ea6b-8426-15b8-a9d96f9c3a83@holobit.net> <0e3743c5-0a22-b6c1-0df3-100c8a63043c@wetron.es> <378f58ef-64da-7c98-e9fb-3452a63461a9@wetron.es> Message-ID: <611b18a5-253b-fa09-e03b-116e9450831a@wetron.es> El 17/05/17 a les 20:22, Luca Olivetti via Lazarus ha escrit: > El 17/05/17 a les 20:16, Luca Olivetti via Lazarus ha escrit: >> Excellent, this is OK, with my selected fonts and correctly sized icons. >> It still has the problem with optimalfill, so it's definitely not >> platform specific. > > > See https://youtu.be/NFZGVx7V2C0 > FWIW if I revert the implementation of CalcFittingFontHeight (lcl/include/customlabel.inc) to the one in lazarus 1.6.4 this doesn't happen anymore. I'll try to see what changed and what broke it. Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From benjamin at rosseaux.de Thu May 18 09:22:59 2017 From: benjamin at rosseaux.de (Benjamin Rosseaux) Date: Thu, 18 May 2017 09:22:59 +0200 Subject: [Lazarus] Vulkan Library for FreePascal/Lazarus In-Reply-To: References: Message-ID: http://www.phoronix.com/scan.php?page=news_item&px=PasVulkan-Vulkan--Pascal-Bind :-) On Tue, May 9, 2017 at 4:38 AM, Benjamin Rosseaux wrote: > PasVulkan seems to be have better Platform Support (incl. Support for > Wayland, Mir, Android, MoltenVK, etc.) and more Vulkan Utils stuff, like > texture loaders for DDS, KTX, PNG, TGA, etc. and a own working memory > manager for manage the Vulkan memory (the reason for it, see slide 20 on > http://32ipi028l5q82yhj72224m8j.wpengine.netdna-cdn.com/wp- > content/uploads/2016/05/Most-common-mistakes-in-Vulkan-apps.pdf with the > slide sub-title "PROBLEMATIC AREAS: MEMORY MANAGEMENT" ). > > The Vulkan memory management stuff is in very many Vulkan code examples > and Vulkan frameworks on the web often totally wrong, that there will be > often worked without sub-allocations and that the maxMemoryAllocationCount > limit is often ignored by the most Vulkan code examples and Vulkan > frameworks on the web. In contrast to it, PasVulkan is here in this point > fully Vulkan specification compliant. > > > On Thu, Apr 13, 2017 at 6:34 PM, Michalis Kamburelis via Lazarus < > lazarus at lists.lazarus-ide.org> wrote: > >> a2017-04-13 11:30 GMT+02:00 Kostas Michalopoulos via Lazarus >> : >> > This is nice, although personally i do not like the use of multiple inc >> > files. I think Benjamin Rosseaux's pasvulkan does it better with >> creating a >> > single pas file (he also uses a unit from the vk.xml file): >> > >> > https://github.com/BeRo1985/pasvulkan/blob/master/src/Vulkan.pas >> > >> > >> > >> > On Thu, Apr 13, 2017 at 7:32 AM, James.mcjohnson via Lazarus >> > wrote: >> >> >> >> This is both an announcement and request for help for an open source >> >> FreePascal project which strives to provide: >> >> 1) a low level access to Vulkan API created directly from the vk.xml >> >> specification >> >> 2) high level wrapper classes for ease of integration in an FP/Lazarus >> >> project >> >> >> >> The project is located at >> >> https://github.com/james-mcjohnson/VulkanLibraryForFreePascal and I >> would >> >> appreciate any constructive feedback. >> >> >> >> It is my hope that a better programmer than I am will take an interest >> and >> >> help create a truly useful Vulkan Library for FreePascal. >> >> >> >> I want to add Vulkan renderer to Castle Game Engine later this year. >> Now I don't know which project to choose:) Both approaches >> (https://github.com/james-mcjohnson/VulkanLibraryForFreePascal and >> https://github.com/BeRo1985/pasvulkan ) seem very fine to me, >> >> - in both cases you generate the Pascal code automatically from vk.xml, >> - in both cases you provide a nicely-looking OOP API, >> - both projects have suitable open-source licenses (MIT or zlib). >> >> I don't mind a couple of include files, they actually include >> readability for me. (I know, it's a matter of taste -- do you prefer >> to navigate multiple smaller files, or navigate one big file.) >> >> @James, would you mind removing the "Public Service Announcement" from >> https://github.com/james-mcjohnson/VulkanLibraryForFreePasca >> l/blob/master/LICENSE.md >> ? Don't get me wrong, I understand that you want to promote your faith >> and I respect that. Having this in README files, and Pascal sources, >> is absolutely OK. But I'm not a lawyer, and I'm unsure how it affects >> the legal text of the license. Having just an "unmodified MIT license" >> would feel safer for me. >> >> Regards, >> Michalis >> -- >> _______________________________________________ >> 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 nc-gaertnma at netcologne.de Thu May 18 09:28:12 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Thu, 18 May 2017 09:28:12 +0200 Subject: [Lazarus] Patch for fixing the window resizes when switching components In-Reply-To: References: Message-ID: <20170518092812.1d7dda22@limapholos.matflo.wg> On Thu, 18 May 2017 02:43:10 +0300 Kostas Michalopoulos via Lazarus wrote: > I see the patch was added and Lazarus seems to work fine now, but the check > was altered a little. The current check assumes that the Control will never > be nil, but is this the case? The "is" operator checks for nil. if Assigned(Control) and (Control is TCustomForm) then <=> if Control is TCustomForm then Mattias From nc-gaertnma at netcologne.de Thu May 18 09:32:13 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Thu, 18 May 2017 09:32:13 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <4c08c405-f0de-1ed4-5475-51b0cb937b30@mfriebe.de> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <9ab6c229-3139-1061-d6f0-e8a6b8df795f@Joepgen.com> <20170518003006.70d8edac@limapholos.matflo.wg> <0c5932da-6ed7-e2cd-cfc6-57d29e8eb17c@Joepgen.com> <4c08c405-f0de-1ed4-5475-51b0cb937b30@mfriebe.de> Message-ID: <20170518093213.0575a62e@limapholos.matflo.wg> On Thu, 18 May 2017 01:24:39 +0100 Martin Frb via Lazarus wrote: > On 18/05/2017 00:34, Joe via Lazarus wrote: > > But Code Completion offers three functions named GetEnvironmentVariable: > > The Ansistring function and the Unicode String function above plus > > "GetEnvironmentVariable(lpName: LPCSTR; lpBuffer: LPSTR; nSize: > > DWORD): DWORD". > > Looks like you may have the unit "windows" in your uses clause. Either move the Windows unit in front of the SysUtils unit, or use SysUtils.GetEnvironmentVariable Mattias From luca at wetron.es Thu May 18 09:38:41 2017 From: luca at wetron.es (Luca Olivetti) Date: Thu, 18 May 2017 09:38:41 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <611b18a5-253b-fa09-e03b-116e9450831a@wetron.es> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> <20170517164846.371e6245@limapholos.matflo.wg> <5258f6ea-eef3-c384-97a3-c695dc4e803a@kluug.net> <668714f9-3fc0-cef9-f6c2-53557cbfc3c8@wetron.es> <14a993d8-ea6b-8426-15b8-a9d96f9c3a83@holobit.net> <0e3743c5-0a22-b6c1-0df3-100c8a63043c@wetron.es> <378f58ef-64da-7c98-e9fb-3452a63461a9@wetron.es> <611b18a5-253b-fa09-e03b-116e9450831a@wetron.es> Message-ID: <00653559-21d5-d146-0aed-2c7d2c611ebb@wetron.es> El 18/05/17 a les 09:17, Luca Olivetti via Lazarus ha escrit: > El 17/05/17 a les 20:22, Luca Olivetti via Lazarus ha escrit: >> El 17/05/17 a les 20:16, Luca Olivetti via Lazarus ha escrit: >>> Excellent, this is OK, with my selected fonts and correctly sized icons. >>> It still has the problem with optimalfill, so it's definitely not >>> platform specific. >> >> >> See https://youtu.be/NFZGVx7V2C0 >> > FWIW if I revert the implementation of CalcFittingFontHeight > (lcl/include/customlabel.inc) to the one in lazarus 1.6.4 this doesn't > happen anymore. > I'll try to see what changed and what broke it. This seems to fix it, maybe fpc 2.6.4 doesn't manage well a "in" with a range of integers? Index: lcl/include/customlabel.inc =================================================================== --- lcl/include/customlabel.inc (revision 54949) +++ lcl/include/customlabel.inc (working copy) @@ -355,7 +355,7 @@ NeededWidth := R.Right - R.Left; NeededHeight := R.Bottom - R.Top; //debugln('TCustomLabel.CalcFittingFontHeight B NeededWidth=',dbgs(NeededWidth),' NeededHeight=',dbgs(NeededHeight),' MaxWidth=',dbgs(MaxWidth),' MaxHeight=',dbgs(MaxHeight)); - if (NeededWidth in [1..MaxWidth]) and (NeededHeight in [1..MaxHeight]) then + if (NeededWidth > 0) and (NeededWidth <= MaxWidth) and (NeededHeight > 0) and (NeededHeight <= MaxHeight) then begin // TheText fits into the bounds if (not Result) or (FontHeight < TestFont.Height) then -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From michael at freepascal.org Thu May 18 10:16:39 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Thu, 18 May 2017 10:16:39 +0200 (CEST) Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <00653559-21d5-d146-0aed-2c7d2c611ebb@wetron.es> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> <20170517164846.371e6245@limapholos.matflo.wg> <5258f6ea-eef3-c384-97a3-c695dc4e803a@kluug.net> <668714f9-3fc0-cef9-f6c2-53557cbfc3c8@wetron.es> <14a993d8-ea6b-8426-15b8-a9d96f9c3a83@holobit.net> <0e3743c5-0a22-b6c1-0df3-100c8a63043c@wetron.es> <378f58ef-64da-7c98-e9fb-3452a63461a9@wetron.es> <611b18a5-253b-fa09-e03b-116e9450831a@wetron.es> <00653559-21d5-d146-0aed-2c7d2c611ebb@wetron.es> Message-ID: On Thu, 18 May 2017, Luca Olivetti via Lazarus wrote: > El 18/05/17 a les 09:17, Luca Olivetti via Lazarus ha escrit: >> El 17/05/17 a les 20:22, Luca Olivetti via Lazarus ha escrit: >>> El 17/05/17 a les 20:16, Luca Olivetti via Lazarus ha escrit: >>>> Excellent, this is OK, with my selected fonts and correctly sized icons. >>>> It still has the problem with optimalfill, so it's definitely not >>>> platform specific. >>> >>> >>> See https://youtu.be/NFZGVx7V2C0 >>> >> FWIW if I revert the implementation of CalcFittingFontHeight >> (lcl/include/customlabel.inc) to the one in lazarus 1.6.4 this doesn't >> happen anymore. >> I'll try to see what changed and what broke it. > > This seems to fix it, maybe fpc 2.6.4 doesn't manage well a "in" with a > range of integers? An "In" was limited to a range of 0..255. As far as I know, this is still so, but a compiler guru will need to confirm. If (NeededWidth in [1..MaxWidth]) was used for speed reasons, I'm not sure that that is a good idea. Michael. > > > Index: lcl/include/customlabel.inc > =================================================================== > --- lcl/include/customlabel.inc (revision 54949) > +++ lcl/include/customlabel.inc (working copy) > @@ -355,7 +355,7 @@ > NeededWidth := R.Right - R.Left; > NeededHeight := R.Bottom - R.Top; > //debugln('TCustomLabel.CalcFittingFontHeight B > NeededWidth=',dbgs(NeededWidth),' NeededHeight=',dbgs(NeededHeight),' > MaxWidth=',dbgs(MaxWidth),' MaxHeight=',dbgs(MaxHeight)); > - if (NeededWidth in [1..MaxWidth]) and (NeededHeight in > [1..MaxHeight]) then > + if (NeededWidth > 0) and (NeededWidth <= MaxWidth) and > (NeededHeight > 0) and (NeededHeight <= MaxHeight) then > begin > // TheText fits into the bounds > if (not Result) or (FontHeight < TestFont.Height) then > > > -- > 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 > From de.jean.7777 at gmail.com Thu May 18 10:21:38 2017 From: de.jean.7777 at gmail.com (Dejan Boras) Date: Thu, 18 May 2017 08:21:38 +0000 Subject: [Lazarus] Vulkan Library for FreePascal/Lazarus In-Reply-To: References: Message-ID: Awesome :) On Thu, May 18, 2017 at 9:23 AM Benjamin Rosseaux via Lazarus < lazarus at lists.lazarus-ide.org> wrote: > > http://www.phoronix.com/scan.php?page=news_item&px=PasVulkan-Vulkan--Pascal-Bind > :-) > > On Tue, May 9, 2017 at 4:38 AM, Benjamin Rosseaux > wrote: > >> PasVulkan seems to be have better Platform Support (incl. Support for >> Wayland, Mir, Android, MoltenVK, etc.) and more Vulkan Utils stuff, like >> texture loaders for DDS, KTX, PNG, TGA, etc. and a own working memory >> manager for manage the Vulkan memory (the reason for it, see slide 20 on >> http://32ipi028l5q82yhj72224m8j.wpengine.netdna-cdn.com/wp-content/uploads/2016/05/Most-common-mistakes-in-Vulkan-apps.pdf >> with the slide sub-title "PROBLEMATIC AREAS: MEMORY MANAGEMENT" ). >> >> The Vulkan memory management stuff is in very many Vulkan code examples >> and Vulkan frameworks on the web often totally wrong, that there will be >> often worked without sub-allocations and that the maxMemoryAllocationCount >> limit is often ignored by the most Vulkan code examples and Vulkan >> frameworks on the web. In contrast to it, PasVulkan is here in this point >> fully Vulkan specification compliant. >> >> >> On Thu, Apr 13, 2017 at 6:34 PM, Michalis Kamburelis via Lazarus < >> lazarus at lists.lazarus-ide.org> wrote: >> >>> a2017-04-13 11:30 GMT+02:00 Kostas Michalopoulos via Lazarus >>> : >>> > This is nice, although personally i do not like the use of multiple inc >>> > files. I think Benjamin Rosseaux's pasvulkan does it better with >>> creating a >>> > single pas file (he also uses a unit from the vk.xml file): >>> > >>> > https://github.com/BeRo1985/pasvulkan/blob/master/src/Vulkan.pas >>> > >>> > >>> > >>> > On Thu, Apr 13, 2017 at 7:32 AM, James.mcjohnson via Lazarus >>> > wrote: >>> >> >>> >> This is both an announcement and request for help for an open source >>> >> FreePascal project which strives to provide: >>> >> 1) a low level access to Vulkan API created directly from the vk.xml >>> >> specification >>> >> 2) high level wrapper classes for ease of integration in an FP/Lazarus >>> >> project >>> >> >>> >> The project is located at >>> >> https://github.com/james-mcjohnson/VulkanLibraryForFreePascal and I >>> would >>> >> appreciate any constructive feedback. >>> >> >>> >> It is my hope that a better programmer than I am will take an >>> interest and >>> >> help create a truly useful Vulkan Library for FreePascal. >>> >> >>> >>> I want to add Vulkan renderer to Castle Game Engine later this year. >>> Now I don't know which project to choose:) Both approaches >>> (https://github.com/james-mcjohnson/VulkanLibraryForFreePascal and >>> https://github.com/BeRo1985/pasvulkan ) seem very fine to me, >>> >>> - in both cases you generate the Pascal code automatically from vk.xml, >>> - in both cases you provide a nicely-looking OOP API, >>> - both projects have suitable open-source licenses (MIT or zlib). >>> >>> I don't mind a couple of include files, they actually include >>> readability for me. (I know, it's a matter of taste -- do you prefer >>> to navigate multiple smaller files, or navigate one big file.) >>> >>> @James, would you mind removing the "Public Service Announcement" from >>> >>> https://github.com/james-mcjohnson/VulkanLibraryForFreePascal/blob/master/LICENSE.md >>> ? Don't get me wrong, I understand that you want to promote your faith >>> and I respect that. Having this in README files, and Pascal sources, >>> is absolutely OK. But I'm not a lawyer, and I'm unsure how it affects >>> the legal text of the license. Having just an "unmodified MIT license" >>> would feel safer for me. >>> >>> Regards, >>> Michalis >>> -- >>> _______________________________________________ >>> 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 badsectoracula at gmail.com Thu May 18 10:34:03 2017 From: badsectoracula at gmail.com (Kostas Michalopoulos) Date: Thu, 18 May 2017 11:34:03 +0300 Subject: [Lazarus] Patch for fixing the window resizes when switching components In-Reply-To: <20170518092812.1d7dda22@limapholos.matflo.wg> References: <20170518092812.1d7dda22@limapholos.matflo.wg> Message-ID: Oops, indeed, i was tripped up by the not in "(not (Control is TCustomForm)) or ..." part. On Thu, May 18, 2017 at 10:28 AM, Mattias Gaertner via Lazarus < lazarus at lists.lazarus-ide.org> wrote: > On Thu, 18 May 2017 02:43:10 +0300 > Kostas Michalopoulos via Lazarus wrote: > > > I see the patch was added and Lazarus seems to work fine now, but the > check > > was altered a little. The current check assumes that the Control will > never > > be nil, but is this the case? > > The "is" operator checks for nil. > > if Assigned(Control) and (Control is TCustomForm) then > > <=> > > if Control is TCustomForm then > > > 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 aaa5500 at ya.ru Thu May 18 10:34:16 2017 From: aaa5500 at ya.ru (Alexey) Date: Thu, 18 May 2017 11:34:16 +0300 Subject: [Lazarus] Hi-dpi: skip logout on Win10 Message-ID: In Win10 when you change scale, you must logout, but can skip logout. Interesting, how Laz apps behave if you skip logouts, and change scale 2-3 times: 100% to 150%, then to 200%, then to 150%. -- Regards, Alexey From lazarus at kluug.net Thu May 18 10:47:10 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Thu, 18 May 2017 10:47:10 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <00653559-21d5-d146-0aed-2c7d2c611ebb@wetron.es> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> <20170517164846.371e6245@limapholos.matflo.wg> <5258f6ea-eef3-c384-97a3-c695dc4e803a@kluug.net> <668714f9-3fc0-cef9-f6c2-53557cbfc3c8@wetron.es> <14a993d8-ea6b-8426-15b8-a9d96f9c3a83@holobit.net> <0e3743c5-0a22-b6c1-0df3-100c8a63043c@wetron.es> <378f58ef-64da-7c98-e9fb-3452a63461a9@wetron.es> <611b18a5-253b-fa09-e03b-116e9450831a@wetron.es> <00653559-21d5-d146-0aed-2c7d2c611ebb@wetron.es> Message-ID: <8ffa8bdc-e9b7-0b3e-ded0-730b44c6388b@kluug.net> On 18.05.2017 9:38, Luca Olivetti via Lazarus wrote: > This seems to fix it, maybe fpc 2.6.4 doesn't manage well a "in" with > a range of integers? Thank you for the patch, applied! Does the bug have a report in mantis so that I can resolve it? Ondrej From luca at wetron.es Thu May 18 11:17:45 2017 From: luca at wetron.es (Luca Olivetti) Date: Thu, 18 May 2017 11:17:45 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <8ffa8bdc-e9b7-0b3e-ded0-730b44c6388b@kluug.net> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> <20170517164846.371e6245@limapholos.matflo.wg> <5258f6ea-eef3-c384-97a3-c695dc4e803a@kluug.net> <668714f9-3fc0-cef9-f6c2-53557cbfc3c8@wetron.es> <14a993d8-ea6b-8426-15b8-a9d96f9c3a83@holobit.net> <0e3743c5-0a22-b6c1-0df3-100c8a63043c@wetron.es> <378f58ef-64da-7c98-e9fb-3452a63461a9@wetron.es> <611b18a5-253b-fa09-e03b-116e9450831a@wetron.es> <00653559-21d5-d146-0aed-2c7d2c611ebb@wetron.es> <8ffa8bdc-e9b7-0b3e-ded0-730b44c6388b@kluug.net> Message-ID: <763f9936-72d7-4414-7cc6-5fa52a497370@wetron.es> El 18/05/17 a les 10:47, Ondrej Pokorny via Lazarus ha escrit: > On 18.05.2017 9:38, Luca Olivetti via Lazarus wrote: >> This seems to fix it, maybe fpc 2.6.4 doesn't manage well a "in" with >> a range of integers? > > Thank you for the patch, applied! Does the bug have a report in mantis > so that I can resolve it? No, I just reported it here. Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From zeljko at holobit.net Thu May 18 13:20:52 2017 From: zeljko at holobit.net (zeljko) Date: Thu, 18 May 2017 13:20:52 +0200 Subject: [Lazarus] Patch for fixing the window resizes when switching components In-Reply-To: References: Message-ID: <9abc9e0c-3493-3961-f5a2-afd9284d244c@holobit.net> On 18.05.2017 01:43, Kostas Michalopoulos via Lazarus wrote: > I see the patch was added and Lazarus seems to work fine now, but the > check was altered a little. The current check assumes that the Control > will never be nil, but is this the case? I ask because i see in other > places in the same source code file that there are checks for that - > almost all calls to GetLCLObject either check for nil or use "if object > is something then use object" (with the "is" operator returning false > for nil, essentially making it an indirect test for nil). > > This might be just an instance defensive programming, but i think it is > a good idea to bring this up. > Yes, this is clearly gtk2 bug, but maybe we can take another approach instead of getting LCL object and using "is". We should check if GdkWindow of widget is valid and then check it's state and in case it's = GDK_WINDOW_STATE_MAXIMIZED call gtk_window_unmaximize() if GDK_IS_WINDOW(PGtkWindow(OurWidget)^.window) and (gdk_window_get_state(PGtkWindow(OurWidget)^.window) = GDK_WINDOW_STATE_MAXIMIZED) then gtk_window_unmaximize() ... Same for unfullscreen and other "un" routines which we use inside that procedure. What other devels think about this ? Should I correct that patch in this way and fix future problems with eg gtk_window_unfullscreen() which isn't covered by this patch atm ? zeljko From marc at dommelstein.nl Thu May 18 13:38:37 2017 From: marc at dommelstein.nl (Marc Weustink) Date: Thu, 18 May 2017 13:38:37 +0200 Subject: [Lazarus] Patch for fixing the window resizes when switching components In-Reply-To: <9abc9e0c-3493-3961-f5a2-afd9284d244c@holobit.net> References: <9abc9e0c-3493-3961-f5a2-afd9284d244c@holobit.net> Message-ID: <2fbd3fa9-a7a0-ef19-3ad8-70c9063f53b9@dommelstein.nl> zeljko via Lazarus wrote: > On 18.05.2017 01:43, Kostas Michalopoulos via Lazarus wrote: > > if GDK_IS_WINDOW(PGtkWindow(OurWidget)^.window) and > (gdk_window_get_state(PGtkWindow(OurWidget)^.window) = > GDK_WINDOW_STATE_MAXIMIZED) then > gtk_window_unmaximize() ... > Same for unfullscreen and other "un" routines which we use inside that > procedure. > > What other devels think about this ? Should I correct that patch in this > way and fix future problems with eg gtk_window_unfullscreen() which > isn't covered by this patch atm ? I prefer using the gtk/gdk functions and avoid getting (win)controls from the widgetsets Marc From nc-gaertnma at netcologne.de Thu May 18 13:43:04 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Thu, 18 May 2017 13:43:04 +0200 Subject: [Lazarus] Patch for fixing the window resizes when switching components In-Reply-To: <9abc9e0c-3493-3961-f5a2-afd9284d244c@holobit.net> References: <9abc9e0c-3493-3961-f5a2-afd9284d244c@holobit.net> Message-ID: <20170518134304.718d6c73@limapholos.matflo.wg> On Thu, 18 May 2017 13:20:52 +0200 zeljko via Lazarus wrote: >[...] > if GDK_IS_WINDOW(PGtkWindow(OurWidget)^.window) and > (gdk_window_get_state(PGtkWindow(OurWidget)^.window) = > GDK_WINDOW_STATE_MAXIMIZED) then > gtk_window_unmaximize() ... > Same for unfullscreen and other "un" routines which we use inside that > procedure. > > What other devels think about this ? Should I correct that patch in this > way and fix future problems with eg gtk_window_unfullscreen() which > isn't covered by this patch atm ? Your solution looks more correct. But since this issue can only be reproduced on some systems, can you test it? Mattias From zeljko at holobit.net Thu May 18 13:43:48 2017 From: zeljko at holobit.net (zeljko) Date: Thu, 18 May 2017 13:43:48 +0200 Subject: [Lazarus] Patch for fixing the window resizes when switching components In-Reply-To: <2fbd3fa9-a7a0-ef19-3ad8-70c9063f53b9@dommelstein.nl> References: <9abc9e0c-3493-3961-f5a2-afd9284d244c@holobit.net> <2fbd3fa9-a7a0-ef19-3ad8-70c9063f53b9@dommelstein.nl> Message-ID: <10441ff7-fa05-9576-7b73-1f9918f09e9d@holobit.net> On 18.05.2017 13:38, Marc Weustink via Lazarus wrote: > zeljko via Lazarus wrote: >> On 18.05.2017 01:43, Kostas Michalopoulos via Lazarus wrote: >> >> if GDK_IS_WINDOW(PGtkWindow(OurWidget)^.window) and >> (gdk_window_get_state(PGtkWindow(OurWidget)^.window) = >> GDK_WINDOW_STATE_MAXIMIZED) then >> gtk_window_unmaximize() ... >> Same for unfullscreen and other "un" routines which we use inside that >> procedure. >> >> What other devels think about this ? Should I correct that patch in this >> way and fix future problems with eg gtk_window_unfullscreen() which >> isn't covered by this patch atm ? > > I prefer using the gtk/gdk functions and avoid getting (win)controls > from the widgetsets I've attached new patch https://bugs.freepascal.org/view.php?id=31832 ...maybe we need one more check if GdkWindow is toplevel but that's all, approach is clear gtk2/gdk instead involving lcl in this part of code for no reason. zeljko From Special at Joepgen.com Thu May 18 13:46:07 2017 From: Special at Joepgen.com (Joe) Date: Thu, 18 May 2017 13:46:07 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <20170518093213.0575a62e@limapholos.matflo.wg> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <9ab6c229-3139-1061-d6f0-e8a6b8df795f@Joepgen.com> <20170518003006.70d8edac@limapholos.matflo.wg> <0c5932da-6ed7-e2cd-cfc6-57d29e8eb17c@Joepgen.com> <4c08c405-f0de-1ed4-5475-51b0cb937b30@mfriebe.de> <20170518093213.0575a62e@limapholos.matflo.wg> Message-ID: <5bafe4d1-4fc9-0903-a847-3eb84f011e39@Joepgen.com> Am 18.05.2017 um 09:32 schrieb Mattias Gaertner via Lazarus: > On Thu, 18 May 2017 01:24:39 +0100 > Martin Frb via Lazarus wrote: > >> On 18/05/2017 00:34, Joe via Lazarus wrote: >>> But Code Completion offers three functions named GetEnvironmentVariable: >>> The Ansistring function and the Unicode String function above plus >>> "GetEnvironmentVariable(lpName: LPCSTR; lpBuffer: LPSTR; nSize: >>> DWORD): DWORD". >> Looks like you may have the unit "windows" in your uses clause. > Either move the Windows unit in front of the SysUtils unit, or use > SysUtils.GetEnvironmentVariable > > Mattias Yes, both solutions work; thank you, Martin and Mattias. Are they documented anywhere? Joe From zeljko at holobit.net Thu May 18 14:17:04 2017 From: zeljko at holobit.net (zeljko) Date: Thu, 18 May 2017 14:17:04 +0200 Subject: [Lazarus] Patch for fixing the window resizes when switching components In-Reply-To: <20170518134304.718d6c73@limapholos.matflo.wg> References: <9abc9e0c-3493-3961-f5a2-afd9284d244c@holobit.net> <20170518134304.718d6c73@limapholos.matflo.wg> Message-ID: <8d08ca57-fc0e-afe7-8d8f-6efb4e7b9583@holobit.net> On 18.05.2017 13:43, Mattias Gaertner via Lazarus wrote: > On Thu, 18 May 2017 13:20:52 +0200 > zeljko via Lazarus wrote: > >> [...] >> if GDK_IS_WINDOW(PGtkWindow(OurWidget)^.window) and >> (gdk_window_get_state(PGtkWindow(OurWidget)^.window) = >> GDK_WINDOW_STATE_MAXIMIZED) then >> gtk_window_unmaximize() ... >> Same for unfullscreen and other "un" routines which we use inside that >> procedure. >> >> What other devels think about this ? Should I correct that patch in this >> way and fix future problems with eg gtk_window_unfullscreen() which >> isn't covered by this patch atm ? > > Your solution looks more correct. But since this issue can only be > reproduced on some systems, can you test it? Just attached new patch which checks if our GdkWindow is toplevel, so it's correct now. Tested on Fedora 24 gtk2 64bit and it works for me :) IMHO, nothing bad can happen with this patch since we check at the beginning if window is mapped or not, so there's nothing to unmaximize,unfullscreen or uniconify without mapped GdkWindow. zeljko From nc-gaertnma at netcologne.de Thu May 18 14:17:54 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Thu, 18 May 2017 14:17:54 +0200 Subject: [Lazarus] Attn Michael, uses section In-Reply-To: <5bafe4d1-4fc9-0903-a847-3eb84f011e39@Joepgen.com> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <9ab6c229-3139-1061-d6f0-e8a6b8df795f@Joepgen.com> <20170518003006.70d8edac@limapholos.matflo.wg> <0c5932da-6ed7-e2cd-cfc6-57d29e8eb17c@Joepgen.com> <4c08c405-f0de-1ed4-5475-51b0cb937b30@mfriebe.de> <20170518093213.0575a62e@limapholos.matflo.wg> <5bafe4d1-4fc9-0903-a847-3eb84f011e39@Joepgen.com> Message-ID: <20170518141754.0479199a@limapholos.matflo.wg> On Thu, 18 May 2017 13:46:07 +0200 Joe via Lazarus wrote: >[...] > > Either move the Windows unit in front of the SysUtils unit, or use > > SysUtils.GetEnvironmentVariable > > Yes, both solutions work; thank you, Martin and Mattias. Are they > documented anywhere? The rule is simple: If an identifier is searched via the uses section, and it does not start with a unitname, the interfaces of the units of the uses section are searched from right to the left. Michael, where are the uses section resolve rules explained? I would expect the documentation of the uses section somewhere here: https://www.freepascal.org/docs-html/current/ref/refse106.html#x216-23800016.2 Btw, the docs about Dotted units https://www.freepascal.org/docs-html/current/ref/refse107.html states: "When resolving symbols, unit scopes always take precedence over symbols inside units." IMO this is misleading. For example: uses foo; type TMy = class foo: TMy; procedure DoSome; end; procedure TMy.DoSome; begin foo:=nil; // nearest symbol wins foo.foo:=nil; // symbol inside unit wins end; The rule is more like this: If the first symbol of a dotted identifier is an unit in the uses section, the longest match wins. Mattias From zeljko at holobit.net Thu May 18 14:26:15 2017 From: zeljko at holobit.net (zeljko) Date: Thu, 18 May 2017 14:26:15 +0200 Subject: [Lazarus] Patch for fixing the window resizes when switching components In-Reply-To: <20170518134304.718d6c73@limapholos.matflo.wg> References: <9abc9e0c-3493-3961-f5a2-afd9284d244c@holobit.net> <20170518134304.718d6c73@limapholos.matflo.wg> Message-ID: On 18.05.2017 13:43, Mattias Gaertner via Lazarus wrote: > On Thu, 18 May 2017 13:20:52 +0200 > zeljko via Lazarus wrote: > >> [...] >> if GDK_IS_WINDOW(PGtkWindow(OurWidget)^.window) and >> (gdk_window_get_state(PGtkWindow(OurWidget)^.window) = >> GDK_WINDOW_STATE_MAXIMIZED) then >> gtk_window_unmaximize() ... >> Same for unfullscreen and other "un" routines which we use inside that >> procedure. >> >> What other devels think about this ? Should I correct that patch in this >> way and fix future problems with eg gtk_window_unfullscreen() which >> isn't covered by this patch atm ? > > Your solution looks more correct. But since this issue can only be > reproduced on some systems, can you test it? Pls, do not apply that patch yet. Must check what happens with GdkWindowState. zeljko From michael at freepascal.org Thu May 18 14:29:38 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Thu, 18 May 2017 14:29:38 +0200 (CEST) Subject: [Lazarus] Attn Michael, uses section In-Reply-To: <20170518141754.0479199a@limapholos.matflo.wg> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <9ab6c229-3139-1061-d6f0-e8a6b8df795f@Joepgen.com> <20170518003006.70d8edac@limapholos.matflo.wg> <0c5932da-6ed7-e2cd-cfc6-57d29e8eb17c@Joepgen.com> <4c08c405-f0de-1ed4-5475-51b0cb937b30@mfriebe.de> <20170518093213.0575a62e@limapholos.matflo.wg> <5bafe4d1-4fc9-0903-a847-3eb84f011e39@Joepgen.com> <20170518141754.0479199a@limapholos.matflo.wg> Message-ID: On Thu, 18 May 2017, Mattias Gaertner via Lazarus wrote: > On Thu, 18 May 2017 13:46:07 +0200 > Joe via Lazarus wrote: > >> [...] >> > Either move the Windows unit in front of the SysUtils unit, or use >> > SysUtils.GetEnvironmentVariable >> >> Yes, both solutions work; thank you, Martin and Mattias. Are they >> documented anywhere? > > The rule is simple: > If an identifier is searched via the uses section, and it does not > start with a unitname, the interfaces of the units of the uses section > are searched from right to the left. > > > Michael, where are the uses section resolve rules explained? > I would expect the documentation of the uses section somewhere > here: > https://www.freepascal.org/docs-html/current/ref/refse106.html#x216-23800016.2 Close, https://www.freepascal.org/docs-html/current/ref/refse105.html#x215-23700016.1 > > > Btw, the docs about Dotted units > https://www.freepascal.org/docs-html/current/ref/refse107.html > states: > "When resolving symbols, unit scopes always take precedence over symbols > inside units." > > IMO this is misleading. For example: > > uses foo; > type > TMy = class > foo: TMy; > procedure DoSome; > end; > procedure TMy.DoSome; > begin > foo:=nil; // nearest symbol wins > foo.foo:=nil; // symbol inside unit wins > end; > > The rule is more like this: > If the first symbol of a dotted identifier is an unit in the uses > section, the longest match wins. Yes, it is somewhat like black magic :) I will adapt it. Michael. From zeljko at holobit.net Thu May 18 16:15:13 2017 From: zeljko at holobit.net (zeljko) Date: Thu, 18 May 2017 16:15:13 +0200 Subject: [Lazarus] Patch for fixing the window resizes when switching components In-Reply-To: <20170518134304.718d6c73@limapholos.matflo.wg> References: <9abc9e0c-3493-3961-f5a2-afd9284d244c@holobit.net> <20170518134304.718d6c73@limapholos.matflo.wg> Message-ID: <5a855b20-81f8-cd4d-59e3-944bd2708d35@holobit.net> On 18.05.2017 13:43, Mattias Gaertner via Lazarus wrote: > On Thu, 18 May 2017 13:20:52 +0200 > zeljko via Lazarus wrote: > >> [...] >> if GDK_IS_WINDOW(PGtkWindow(OurWidget)^.window) and >> (gdk_window_get_state(PGtkWindow(OurWidget)^.window) = >> GDK_WINDOW_STATE_MAXIMIZED) then >> gtk_window_unmaximize() ... >> Same for unfullscreen and other "un" routines which we use inside that >> procedure. >> >> What other devels think about this ? Should I correct that patch in this >> way and fix future problems with eg gtk_window_unfullscreen() which >> isn't covered by this patch atm ? > > Your solution looks more correct. But since this issue can only be > reproduced on some systems, can you test it? Mattias, please if you merge something (at least related to resolved/closed issues) add it to http://wiki.freepascal.org/Lazarus_1.8_fixes_branch (I've added r54958 to the merged revisions for RC2) zeljko From luca at wetron.es Thu May 18 16:57:40 2017 From: luca at wetron.es (Luca Olivetti) Date: Thu, 18 May 2017 16:57:40 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <20170517164846.371e6245@limapholos.matflo.wg> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> <20170517164846.371e6245@limapholos.matflo.wg> Message-ID: <06609223-6129-8cb3-20f1-30147df18b3f@wetron.es> El 17/05/17 a les 16:48, Mattias Gaertner via Lazarus ha escrit: > On Wed, 17 May 2017 16:34:14 +0200 > Luca Olivetti via Lazarus wrote: > >> [...] >>> Is this version still supposed to work with fpc 2.6.4? >> >> OK, I see now that it doesn't build with fpc 2.6.4 :-( > > Fixed. > > The Lazarus devels only support the last two FPC releases, which means > 3.0.0 and 3.0.2. > But as long as FPC 2.6.4 only needs a few IFDEFs, patches are welcome. Here's another one. Not sure it's correct but the dialog seems to be working fine Index: components/codetools/ide/codyidentifiersdlg.pas =================================================================== --- components/codetools/ide/codyidentifiersdlg.pas (revision 54949) +++ components/codetools/ide/codyidentifiersdlg.pas (working copy) @@ -1366,7 +1366,7 @@ NewY: integer; NewTopLine: integer; CurUnit: TUDUnit; - MainPath: RawByteString; + MainPath: {$IF FPC_FULLVERSION < 30000} string {$ELSE} RawByteString {$ENDIF}; function OpenDependency: boolean; // returns false to abort -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From nc-gaertnma at netcologne.de Thu May 18 17:02:53 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Thu, 18 May 2017 17:02:53 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <06609223-6129-8cb3-20f1-30147df18b3f@wetron.es> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> <20170517164846.371e6245@limapholos.matflo.wg> <06609223-6129-8cb3-20f1-30147df18b3f@wetron.es> Message-ID: <20170518170253.5c1bc854@limapholos.matflo.wg> On Thu, 18 May 2017 16:57:40 +0200 Luca Olivetti via Lazarus wrote: >[...] > Index: components/codetools/ide/codyidentifiersdlg.pas > =================================================================== > --- components/codetools/ide/codyidentifiersdlg.pas (revision 54949) > +++ components/codetools/ide/codyidentifiersdlg.pas (working copy) > @@ -1366,7 +1366,7 @@ > NewY: integer; > NewTopLine: integer; > CurUnit: TUDUnit; > - MainPath: RawByteString; > + MainPath: {$IF FPC_FULLVERSION < 30000} string {$ELSE} RawByteString > {$ENDIF}; It must be string. Fixed. Mattias From lazarus at kluug.net Thu May 18 17:14:03 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Thu, 18 May 2017 17:14:03 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <20170518170253.5c1bc854@limapholos.matflo.wg> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> <20170517164846.371e6245@limapholos.matflo.wg> <06609223-6129-8cb3-20f1-30147df18b3f@wetron.es> <20170518170253.5c1bc854@limapholos.matflo.wg> Message-ID: <36a8f4e6-e9d6-7f7c-84a4-b1b0f3fa2093@kluug.net> On 18.05.2017 17:02, Mattias Gaertner via Lazarus wrote: > On Thu, 18 May 2017 16:57:40 +0200 > Luca Olivetti via Lazarus wrote: > >> [...] >> Index: components/codetools/ide/codyidentifiersdlg.pas >> =================================================================== >> --- components/codetools/ide/codyidentifiersdlg.pas (revision 54949) >> +++ components/codetools/ide/codyidentifiersdlg.pas (working copy) >> @@ -1366,7 +1366,7 @@ >> NewY: integer; >> NewTopLine: integer; >> CurUnit: TUDUnit; >> - MainPath: RawByteString; >> + MainPath: {$IF FPC_FULLVERSION < 30000} string {$ELSE} RawByteString >> {$ENDIF}; > It must be string. Fixed. IMO, we should create a new option for CodeTools to override string result types for Ctrl+Shift+C. It could be both easy to implement and easy to understand: if the first argument is some kind of 8bit-string (RawByteString/AnsiString/String), and the result is an 8bit string as well, use the argument string type as result type. In this case var S: string; begin X := ExtractFilePath(S); end; should create var S, X: string; begin X := ExtractFilePath(S); end; and not (what is now) var S: string; X: RawByteString; begin X := ExtractFilePath(S); end; A lot of the above issues would never happen. Ondrej From nc-gaertnma at netcologne.de Thu May 18 17:20:37 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Thu, 18 May 2017 17:20:37 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <36a8f4e6-e9d6-7f7c-84a4-b1b0f3fa2093@kluug.net> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> <20170517164846.371e6245@limapholos.matflo.wg> <06609223-6129-8cb3-20f1-30147df18b3f@wetron.es> <20170518170253.5c1bc854@limapholos.matflo.wg> <36a8f4e6-e9d6-7f7c-84a4-b1b0f3fa2093@kluug.net> Message-ID: <20170518172037.38e618e4@limapholos.matflo.wg> On Thu, 18 May 2017 17:14:03 +0200 Ondrej Pokorny via Lazarus wrote: >[...] > IMO, we should create a new option for CodeTools to override string > result types for Ctrl+Shift+C. It could be both easy to implement and > easy to understand: > > if the first argument is some kind of 8bit-string > (RawByteString/AnsiString/String), and the result is an 8bit string as > well, use the argument string type as result type. > > In this case > > var > S: string; > begin > X := ExtractFilePath(S); > end; > > should create > > var > S, X: string; > begin > X := ExtractFilePath(S); > end; > > and not (what is now) > > var > S: string; > X: RawByteString; > begin > X := ExtractFilePath(S); > end; > > > A lot of the above issues would never happen. True. Mattias From lazarus at kluug.net Thu May 18 17:22:18 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Thu, 18 May 2017 17:22:18 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <20170518172037.38e618e4@limapholos.matflo.wg> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> <20170517164846.371e6245@limapholos.matflo.wg> <06609223-6129-8cb3-20f1-30147df18b3f@wetron.es> <20170518170253.5c1bc854@limapholos.matflo.wg> <36a8f4e6-e9d6-7f7c-84a4-b1b0f3fa2093@kluug.net> <20170518172037.38e618e4@limapholos.matflo.wg> Message-ID: On 18.05.2017 17:20, Mattias Gaertner via Lazarus wrote: > True. I'll do that. Ondrej From zeljko at holobit.net Thu May 18 19:37:36 2017 From: zeljko at holobit.net (zeljko) Date: Thu, 18 May 2017 19:37:36 +0200 Subject: [Lazarus] Patch for fixing the window resizes when switching components In-Reply-To: <2fbd3fa9-a7a0-ef19-3ad8-70c9063f53b9@dommelstein.nl> References: <9abc9e0c-3493-3961-f5a2-afd9284d244c@holobit.net> <2fbd3fa9-a7a0-ef19-3ad8-70c9063f53b9@dommelstein.nl> Message-ID: <46db7873-f7b4-8c7e-f8c4-1e87f4084338@holobit.net> On 18.05.2017 13:38, Marc Weustink via Lazarus wrote: > zeljko via Lazarus wrote: >> On 18.05.2017 01:43, Kostas Michalopoulos via Lazarus wrote: >> >> if GDK_IS_WINDOW(PGtkWindow(OurWidget)^.window) and >> (gdk_window_get_state(PGtkWindow(OurWidget)^.window) = >> GDK_WINDOW_STATE_MAXIMIZED) then >> gtk_window_unmaximize() ... >> Same for unfullscreen and other "un" routines which we use inside that >> procedure. >> >> What other devels think about this ? Should I correct that patch in this >> way and fix future problems with eg gtk_window_unfullscreen() which >> isn't covered by this patch atm ? > > I prefer using the gtk/gdk functions and avoid getting (win)controls > from the widgetsets I've removed workaround introduced in r54958 with pure gdk/gtk implementation in r54975. Please guys test, since I cannot reproduce problem here (even without any patch): Fedora 24 64bit, KDE Plasma (kwin is window manager). I need info from users from Mint 16..18 and Cinnamon DE which uses mutter or metacity if this finally fixes problem. Positive feedback = merge to 1.8RC2 Important note: Gtk2 changes window state in async mode under x11, so statement like this won't work (it works ok under qt or win32) and you can expect problems with such code :) with TForm2.Create(Self) do begin Show; LCLIntf.ShowWindow(Handle, SW_SHOWMAXIMIZED); LCLIntf.ShowWindow(Handle, SW_RESTORE); end; zeljko From badsectoracula at gmail.com Thu May 18 20:24:37 2017 From: badsectoracula at gmail.com (Kostas Michalopoulos) Date: Thu, 18 May 2017 21:24:37 +0300 Subject: [Lazarus] Patch for fixing the window resizes when switching components In-Reply-To: <46db7873-f7b4-8c7e-f8c4-1e87f4084338@holobit.net> References: <9abc9e0c-3493-3961-f5a2-afd9284d244c@holobit.net> <2fbd3fa9-a7a0-ef19-3ad8-70c9063f53b9@dommelstein.nl> <46db7873-f7b4-8c7e-f8c4-1e87f4084338@holobit.net> Message-ID: Yes the new code works perfectly fine here and is a better solution. My original thought was to use pure Gtk but i forgot about gdk_ and only looked for something like gtk_window_get_state - which i couldn't find :-). On Thu, May 18, 2017 at 8:37 PM, zeljko via Lazarus < lazarus at lists.lazarus-ide.org> wrote: > On 18.05.2017 13:38, Marc Weustink via Lazarus wrote: > >> zeljko via Lazarus wrote: >> >>> On 18.05.2017 01:43, Kostas Michalopoulos via Lazarus wrote: >>> >>> if GDK_IS_WINDOW(PGtkWindow(OurWidget)^.window) and >>> (gdk_window_get_state(PGtkWindow(OurWidget)^.window) = >>> GDK_WINDOW_STATE_MAXIMIZED) then >>> gtk_window_unmaximize() ... >>> Same for unfullscreen and other "un" routines which we use inside that >>> procedure. >>> >>> What other devels think about this ? Should I correct that patch in this >>> way and fix future problems with eg gtk_window_unfullscreen() which >>> isn't covered by this patch atm ? >>> >> >> I prefer using the gtk/gdk functions and avoid getting (win)controls >> from the widgetsets >> > > I've removed workaround introduced in r54958 with pure gdk/gtk > implementation in r54975. > Please guys test, since I cannot reproduce problem here (even without any > patch): Fedora 24 64bit, KDE Plasma (kwin is window manager). > I need info from users from Mint 16..18 and Cinnamon DE which uses mutter > or metacity if this finally fixes problem. > Positive feedback = merge to 1.8RC2 > > Important note: Gtk2 changes window state in async mode under x11, so > statement like this won't work (it works ok under qt or win32) and you can > expect problems with such code :) > > with TForm2.Create(Self) do > begin > Show; > LCLIntf.ShowWindow(Handle, SW_SHOWMAXIMIZED); > LCLIntf.ShowWindow(Handle, SW_RESTORE); > end; > > > zeljko > > > > -- > _______________________________________________ > 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 zeljko at holobit.net Thu May 18 21:11:54 2017 From: zeljko at holobit.net (zeljko) Date: Thu, 18 May 2017 21:11:54 +0200 Subject: [Lazarus] Patch for fixing the window resizes when switching components In-Reply-To: References: <9abc9e0c-3493-3961-f5a2-afd9284d244c@holobit.net> <2fbd3fa9-a7a0-ef19-3ad8-70c9063f53b9@dommelstein.nl> <46db7873-f7b4-8c7e-f8c4-1e87f4084338@holobit.net> Message-ID: On 18.05.2017 20:24, Kostas Michalopoulos via Lazarus wrote: > Yes the new code works perfectly fine here and is a better solution. My > original thought was to use pure Gtk but i forgot about gdk_ and only > looked for something like gtk_window_get_state - which i couldn't find :-). Thanks for feedback :) zeljko From lazarus at kluug.net Thu May 18 21:48:10 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Thu, 18 May 2017 21:48:10 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <20170518172037.38e618e4@limapholos.matflo.wg> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> <20170517164846.371e6245@limapholos.matflo.wg> <06609223-6129-8cb3-20f1-30147df18b3f@wetron.es> <20170518170253.5c1bc854@limapholos.matflo.wg> <36a8f4e6-e9d6-7f7c-84a4-b1b0f3fa2093@kluug.net> <20170518172037.38e618e4@limapholos.matflo.wg> Message-ID: On 18.05.2017 17:20, Mattias Gaertner via Lazarus wrote: > On Thu, 18 May 2017 17:14:03 +0200 > Ondrej Pokorny via Lazarus wrote: > >> [...] >> IMO, we should create a new option for CodeTools to override string >> result types for Ctrl+Shift+C. It could be both easy to implement and >> easy to understand: >> >> if the first argument is some kind of 8bit-string >> (RawByteString/AnsiString/String), and the result is an 8bit string as >> well, use the argument string type as result type. >> >> In this case >> >> var >> S: string; >> begin >> X := ExtractFilePath(S); >> end; >> >> should create >> >> var >> S, X: string; >> begin >> X := ExtractFilePath(S); >> end; >> >> and not (what is now) >> >> var >> S: string; >> X: RawByteString; >> begin >> X := ExtractFilePath(S); >> end; >> >> >> A lot of the above issues would never happen. > True. Should I enable it by default? Ondrej From lazarus at kluug.net Thu May 18 22:10:28 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Thu, 18 May 2017 22:10:28 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> <20170517164846.371e6245@limapholos.matflo.wg> <06609223-6129-8cb3-20f1-30147df18b3f@wetron.es> <20170518170253.5c1bc854@limapholos.matflo.wg> <36a8f4e6-e9d6-7f7c-84a4-b1b0f3fa2093@kluug.net> <20170518172037.38e618e4@limapholos.matflo.wg> Message-ID: On 18.05.2017 21:48, Ondrej Pokorny via Lazarus wrote: > On 18.05.2017 17:20, Mattias Gaertner via Lazarus wrote: >> True. > > Should I enable it by default? I implemented it in r54976 and made it default because all 8-bit string types are equivalent for the compiler, so it makes perfect sense not to mix them; if I am not mistaken. Ondrej From nc-gaertnma at netcologne.de Thu May 18 22:15:57 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Thu, 18 May 2017 22:15:57 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2d357595-dcf9-fa68-94f8-a63a3a27a265@wetron.es> <2c8fb49d-2d80-65ec-8cd0-70dc4da95057@wetron.es> <20170517164846.371e6245@limapholos.matflo.wg> <06609223-6129-8cb3-20f1-30147df18b3f@wetron.es> <20170518170253.5c1bc854@limapholos.matflo.wg> <36a8f4e6-e9d6-7f7c-84a4-b1b0f3fa2093@kluug.net> <20170518172037.38e618e4@limapholos.matflo.wg> Message-ID: <20170518221557.2de43429@limapholos.matflo.wg> On Thu, 18 May 2017 21:48:10 +0200 Ondrej Pokorny via Lazarus wrote: >[...] > Should I enable it by default? Yes. Mattias From aaa5500 at ya.ru Thu May 18 23:21:37 2017 From: aaa5500 at ya.ru (Alexey) Date: Fri, 19 May 2017 00:21:37 +0300 Subject: [Lazarus] Cannot install FPC 3.0.2/3.0.3 from Lazarus Message-ID: On Ubuntu 14.4 I get this error, and after /ignore/ package cannot install fully: IDE cannot rebuild then. Linker error with "missing section on dddddd.o file". Picture of DEB install error -- Regards, Alexey -------------- next part -------------- A non-text attachment was scrubbed... Name: fpc302-warn.png Type: image/png Size: 41935 bytes Desc: not available URL: From aaa5500 at ya.ru Thu May 18 23:28:01 2017 From: aaa5500 at ya.ru (Alexey) Date: Fri, 19 May 2017 00:28:01 +0300 Subject: [Lazarus] Cannot install FPC 3.0.2/3.0.3 from Lazarus In-Reply-To: References: Message-ID: <45f03804-9d1b-47c3-cc49-d6ab749b5914@ya.ru> After this not ok install (ignore error) I cannot build IDE: Clean Lazarus Source: Success .. main.pp(240,40) Parameter "Sender" not used main.pp(423,35) Parameter "Sender" not used Compiling resource /home/user/lazarus/units/x86_64-linux/gtk2/lazarus.or Linking ../lazarus /usr/bin/ld: warning: ../link.res contains output sections; did you forget -T? /usr/bin/ld: /usr/lib/fpc/3.0.2/units/x86_64-linux/rtl/cprt0.o: unrecognized relocation (0x2a) in section `.text' /usr/bin/ld: final link failed: Bad value [lazarus] Error 1 [idepkg] Error 2 make: *** [idepkg] Error 2 lazarus.pp(161,1) Error: Error while linking From werner.pamler at freenet.de Thu May 18 23:45:13 2017 From: werner.pamler at freenet.de (Werner Pamler) Date: Thu, 18 May 2017 23:45:13 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <20170517143928.1d2588e4@limapholos.matflo.wg> References: <20170517143928.1d2588e4@limapholos.matflo.wg> Message-ID: An issue with the installer for 1.8RC1 32bit Windows (I hope it has not been discussed already...): the checkbox to create a desktop icob is disabled. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: kaghndbcbckilogh.png Type: image/png Size: 15652 bytes Desc: not available URL: From werner.pamler at freenet.de Fri May 19 01:30:53 2017 From: werner.pamler at freenet.de (Werner Pamler) Date: Fri, 19 May 2017 01:30:53 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: References: <20170517143928.1d2588e4@limapholos.matflo.wg> <71bc1b7f-adcc-8abb-5cf9-27745bcedb04@gmx.at> Message-ID: <2b6fb59c-42e0-79f0-4c01-faeff6cd3c59@freenet.de> Am 18.05.2017 um 00:41 schrieb Werner Pamler via Lazarus: > Am 17.05.2017 um 23:08 schrieb Andreas Frieß via Lazarus: >> I see with the last patches something goes wrong after r54880 with >> frames and grid (specially TsWorkSheetGrid). >> >> Lazarus claims, the is no valid parent and didnot load and crash. It >> is only happen if you use frames ? The trouble is, i can only >> shutdown Lazarus with the Processmanger. >> >> Win10/64 with Lazarus 32/svn 1.9RC1 > > This is confusing: Are you using Laz trunk (v1.9) or 1.8RC1? I don't > see an issue with WorksheetGrid on frames with Laz trunk. Can you post > a demo? Andreas, could you try r5868 of fpspreadsheet? I fixed a "Window has no parent" error with frames which had crept in, again... From nc-gaertnma at netcologne.de Fri May 19 02:03:40 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Fri, 19 May 2017 02:03:40 +0200 Subject: [Lazarus] Cannot install FPC 3.0.2/3.0.3 from Lazarus In-Reply-To: References: Message-ID: <20170519020340.4333492b@limapholos.matflo.wg> On Fri, 19 May 2017 00:21:37 +0300 Alexey via Lazarus wrote: > On Ubuntu 14.4 > I get this error, and after /ignore/ package cannot install fully: > IDE cannot rebuild then. Linker error with "missing section on dddddd.o file". > > Picture of DEB install error Please create a bug report. Mattias From werner.pamler at freenet.de Fri May 19 10:27:55 2017 From: werner.pamler at freenet.de (Werner Pamler) Date: Fri, 19 May 2017 10:27:55 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: References: <20170517143928.1d2588e4@limapholos.matflo.wg> Message-ID: <2ddba3e4-9b8d-77ce-4cbd-e661eadb8e64@freenet.de> Am 18.05.2017 um 23:45 schrieb Werner Pamler via Lazarus: > An issue with the installer for 1.8RC1 32bit Windows (I hope it has > not been discussed already...): the checkbox to create a desktop icob > is disabled. This happens when "Create a seconary installation" is checked. And I looked at previous versions: all versions back to 1.2 have the same behavior (1.0 did not have the secondary installation option yet). So, I guess this is intended. But why should a secondardy installation be inhibited to create a desktop icon? From marc at dommelstein.nl Fri May 19 11:49:35 2017 From: marc at dommelstein.nl (Marc Weustink) Date: Fri, 19 May 2017 11:49:35 +0200 Subject: [Lazarus] SPAM - Postfix master In-Reply-To: <1aa081c8-bdd3-075a-acba-395f4a4a7085@gmail.com> References: <1aa081c8-bdd3-075a-acba-395f4a4a7085@gmail.com> Message-ID: José Mejuto via Lazarus wrote: > Hello, > > Can Postfix master ban 14.169.188.113 ? All "Gabor Boros" (I know he is > not responsible) spam comes from that mail server (DNS name does not > match IP, only reverse resolution) and it looks like a Fiber/DSL user in > Vietnam. > > The IP is listed in at least 15 spam blacklists. Yup... that's why my spamassassin marked it as spam. I've enabled spamassassin on the lazarus server for all lists. Positives are for now put on hold (to check for false positives). In the future messages will be discarded. Marc From aaa5500 at ya.ru Fri May 19 12:02:44 2017 From: aaa5500 at ya.ru (Alexey) Date: Fri, 19 May 2017 13:02:44 +0300 Subject: [Lazarus] Icon in Find dialog: same as debug icon Message-ID: <330689e4-ff66-2f01-9420-6c5cce6cd52d@ya.ru> Not sure this is for purpose: icons are the same. Picture. -- Regards, Alexey -------------- next part -------------- A non-text attachment was scrubbed... Name: icon-acp.png Type: image/png Size: 24501 bytes Desc: not available URL: From lazarus at mfriebe.de Fri May 19 12:24:00 2017 From: lazarus at mfriebe.de (Martin Frb) Date: Fri, 19 May 2017 11:24:00 +0100 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <2ddba3e4-9b8d-77ce-4cbd-e661eadb8e64@freenet.de> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <2ddba3e4-9b8d-77ce-4cbd-e661eadb8e64@freenet.de> Message-ID: <710289ea-c0ca-32ab-b2c6-f2e391bb0692@mfriebe.de> On 19/05/2017 09:27, Werner Pamler via Lazarus wrote: > Am 18.05.2017 um 23:45 schrieb Werner Pamler via Lazarus: >> An issue with the installer for 1.8RC1 32bit Windows (I hope it has >> not been discussed already...): the checkbox to create a desktop icob >> is disabled. > > This happens when "Create a seconary installation" is checked. And I > looked at previous versions: all versions back to 1.2 have the same > behavior (1.0 did not have the secondary installation option yet). So, > I guess this is intended. But why should a secondardy installation be > inhibited to create a desktop icon? No idea (that is, I do not remember) Probably to avoid overwriting the desktop icon of the primary install. So basically it would need implementation to create a meaningful icon. (If inno can be tweaked). If so then it is a missing feature. patches welcome. From robin.listas at telefonica.net Fri May 19 12:52:01 2017 From: robin.listas at telefonica.net (Carlos E. R.) Date: Fri, 19 May 2017 12:52:01 +0200 Subject: [Lazarus] SPAM - Postfix master In-Reply-To: References: <1aa081c8-bdd3-075a-acba-395f4a4a7085@gmail.com> Message-ID: <05a9777f-2091-dc53-17a2-70e6a9e4de11@telefonica.net> On 2017-05-19 11:49, Marc Weustink via Lazarus wrote: > José Mejuto via Lazarus wrote: >> Hello, >> >> Can Postfix master ban 14.169.188.113 ? All "Gabor Boros" (I know he is >> not responsible) spam comes from that mail server (DNS name does not >> match IP, only reverse resolution) and it looks like a Fiber/DSL user in >> Vietnam. >> >> The IP is listed in at least 15 spam blacklists. > > Yup... that's why my spamassassin marked it as spam. > I've enabled spamassassin on the lazarus server for all lists. > Positives are for now put on hold (to check for false positives). In the > future messages will be discarded. Be careful, spamassassin has false positives now and then. If you are going to do automatic discards, do it for a score of 10 or more. I don't ever do automatic discards. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP digital signature URL: From Special at Joepgen.com Fri May 19 13:40:01 2017 From: Special at Joepgen.com (Joe) Date: Fri, 19 May 2017 13:40:01 +0200 Subject: [Lazarus] Lazarus RC1 - Test finding at TSQLQuery.RecordCount Message-ID: <88b894e7-f96d-fcc4-8f6b-50aaf341b0e9@Joepgen.com> I am using a TSQLQuery named Query on a Form. Code Completion offers a property 'RecordCount' for Query. See first Screen Shot 'Offer.png'. But the "Liste der überwachten Ausdrücke" says: "Type TSQLQUERY has no component named RECORDCOUNT". See second screen shot 'refusal.png'. Regards - Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: Offer.png Type: image/png Size: 12033 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: refusal.png Type: image/png Size: 12594 bytes Desc: not available URL: From aaa5500 at ya.ru Fri May 19 15:08:47 2017 From: aaa5500 at ya.ru (Alexey) Date: Fri, 19 May 2017 16:08:47 +0300 Subject: [Lazarus] Revert ButtonPanel button size Message-ID: Can you return old height of buttons on TButtonPanel, which is now 2pixels less? Ie, revert patch which gave such effect. I dont like such small buttons on Ubuntu. -- Regards, Alexey From m-w-vogel at gmx.de Wed May 17 23:28:32 2017 From: m-w-vogel at gmx.de (Michael W. Vogel) Date: Wed, 17 May 2017 23:28:32 +0200 Subject: [Lazarus] Lazarus RC1 - Test finding at TSQLQuery.RecordCount In-Reply-To: <88b894e7-f96d-fcc4-8f6b-50aaf341b0e9@Joepgen.com> References: <88b894e7-f96d-fcc4-8f6b-50aaf341b0e9@Joepgen.com> Message-ID: <1ef6f157-8d24-9f7b-9f80-195833047993@gmx.de> Am 19.05.2017 um 13:40 schrieb Joe via Lazarus: > I am using a TSQLQuery named Query on a Form. > Code Completion offers a property 'RecordCount' for Query. See first > Screen Shot 'Offer.png'. > But the "Liste der überwachten Ausdrücke" says: "Type TSQLQUERY has no > component named RECORDCOUNT". Maybe the hint is a bit misleading (imho "property" would be better than "component"), but yes, "currently the debugger does not support any method execution. Therefore only properties that refer directly to a variable can be inspected", see also: http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Properties Kind regards Michl From giuliano.colla at fastwebnet.it Sat May 20 12:24:01 2017 From: giuliano.colla at fastwebnet.it (Giuliano Colla) Date: Sat, 20 May 2017 12:24:01 +0200 Subject: [Lazarus] A simple way to stop the never ending story of long executable? Message-ID: I had tried in remote times to activate the "use external gdb debug symbols file" option, and it didn't work properly, so I forgot about it. But some time ago I tried again, and now it turns out to work perfectly, at least under Linux. Wouldn't it be nice to set it active by default? This could make unnecessary in many cases a different build mode for testing and for deploying, and would stop the complaints about "long executable". Giuliano From aaa5500 at ya.ru Sat May 20 12:53:33 2017 From: aaa5500 at ya.ru (Alexey) Date: Sat, 20 May 2017 13:53:33 +0300 Subject: [Lazarus] A simple way to stop the never ending story of long executable? In-Reply-To: References: Message-ID: External debug symbols file? +1 for ON default On 20.05.2017 13:24, Giuliano Colla via Lazarus wrote: > Wouldn't it be nice to set it active by default? -- Regards, Alexey From bartjunk64 at gmail.com Sat May 20 13:20:09 2017 From: bartjunk64 at gmail.com (Bart) Date: Sat, 20 May 2017 13:20:09 +0200 Subject: [Lazarus] A simple way to stop the never ending story of long executable? In-Reply-To: References: Message-ID: On 5/20/17, Alexey via Lazarus wrote: > External debug symbols file? No, please. Bart From giuliano.colla at fastwebnet.it Sat May 20 13:29:52 2017 From: giuliano.colla at fastwebnet.it (Giuliano Colla) Date: Sat, 20 May 2017 13:29:52 +0200 Subject: [Lazarus] A simple way to stop the never ending story of long executable? In-Reply-To: References: Message-ID: <93cdb0b5-8a57-daf5-d030-9427825a6004@fastwebnet.it> Il 20/05/2017 13:20, Bart via Lazarus ha scritto: >> External debug symbols file? > No, please. Why? Giuliano -------------- next part -------------- An HTML attachment was scrubbed... URL: From lazarus at mfriebe.de Sat May 20 13:51:23 2017 From: lazarus at mfriebe.de (Martin Frb) Date: Sat, 20 May 2017 12:51:23 +0100 Subject: [Lazarus] A simple way to stop the never ending story of long executable? In-Reply-To: References: Message-ID: <55a7f556-1dd9-e5ab-aafb-3f34371c8da9@mfriebe.de> On 20/05/2017 11:24, Giuliano Colla via Lazarus wrote: > I had tried in remote times to activate the "use external gdb debug > symbols file" option, and it didn't work properly, so I forgot about > it. But some time ago I tried again, and now it turns out to work > perfectly, at least under Linux. > > Wouldn't it be nice to set it active by default? > > This could make unnecessary in many cases a different build mode for > testing and for deploying, and would stop the complaints about "long > executable". 1) It would need a lot of testing. - On ALL platforms. - With lots of different versions of gdb - and with fpdebug - and with -gl (dump line numbers in traces) - and with the IDE tool "Leaks and traces", the button "resolve" 2) The statement "make unnecessary in many cases a different build mode..." is wrong. If you are serious about developing or teaching to do so, then I see no case where this applies. Debug mode still needs -Criot -gt -gh and assertions, and maybe others. --------------------- Also people complain about the size of a debug free exe too. So the problem persists, yet with less people complaining. Anyway the issue is not to change the size of the debug exe, the issue is to make sure people realize that there is debug and release (so the benefit from -Criot... in debug too). If you have ideas how to highlight them better... Maybe the debug mode can be set to create it's output in a folder named debug? Then people who look at the exe will be forced to notice (well, some may notice the obvious, others may not) From bartjunk64 at gmail.com Sat May 20 14:04:51 2017 From: bartjunk64 at gmail.com (Bart) Date: Sat, 20 May 2017 14:04:51 +0200 Subject: [Lazarus] A simple way to stop the never ending story of long executable? In-Reply-To: <93cdb0b5-8a57-daf5-d030-9427825a6004@fastwebnet.it> References: <93cdb0b5-8a57-daf5-d030-9427825a6004@fastwebnet.it> Message-ID: On 5/20/17, Giuliano Colla via Lazarus wrote: >>> External debug symbols file? >> No, please. > > Why? 1. I regularly deploy applications with debug info. 2. There are reports (or at least I remeber seeing them) that antivirus programs tend to barf on external debug files. 3. Any serious developer should have a debug and release mode for anything he releases, which would make the "why are my executales so big" discussion a bit obsolete. 4. The "why are my executales so big" is in the FAQ, just refer people to the FAQ, don't discuss with them. 5. I don't like it when you alter default settings for compilation/linking. 6. I don't like changes (unless introduced by me) in general. 7. I'm out of arguments right now. Bart From giuliano.colla at fastwebnet.it Sun May 21 00:00:41 2017 From: giuliano.colla at fastwebnet.it (Giuliano Colla) Date: Sun, 21 May 2017 00:00:41 +0200 Subject: [Lazarus] A simple way to stop the never ending story of long executable? In-Reply-To: References: <93cdb0b5-8a57-daf5-d030-9427825a6004@fastwebnet.it> Message-ID: <529218c4-31d2-2342-397f-305f90236119@fastwebnet.it> Il 20/05/2017 14:04, Bart via Lazarus ha scritto: > On 5/20/17, Giuliano Colla via Lazarus wrote: > >>>> External debug symbols file? >>> No, please. >> Why? > 1. I regularly deploy applications with debug info. > 2. There are reports (or at least I remeber seeing them) that > antivirus programs tend to barf on external debug files. > 3. Any serious developer should have a debug and release mode for > anything he releases, which would make the "why are my executales so > big" discussion a bit obsolete. > 4. The "why are my executales so big" is in the FAQ, just refer people > to the FAQ, don't discuss with them. > 5. I don't like it when you alter default settings for compilation/linking. > 6. I don't like changes (unless introduced by me) in general. > 7. I'm out of arguments right now. > > Bart I'm afraid that there's a big misunderstanding (which also explains Martin's answer). I wasn't suggesting to make the external debug symbol file the default Lazarus behaviour, removing the flexibility which is currently provided. I was just suggesting to change the default of the "external debug symbol file" checkbox from *unchecked* to *checked*, when you start a new project. This would provide a new user a better experience, before he learns how to take advantage of different build modes, and gets acquainted wit all the extra options available to generate debug and production compiler switches. The default checkbox settings are intended to provide users with a minimum starting point, and to suggest some reasonable options. External debug symbol file is one of them, IMHO. Giuliano From dezlov at gmail.com Sun May 21 00:16:37 2017 From: dezlov at gmail.com (Denis Kozlov) Date: Sat, 20 May 2017 23:16:37 +0100 Subject: [Lazarus] A simple way to stop the never ending story of long executable? In-Reply-To: References: Message-ID: <10331b51-d0f1-559b-6f03-6337b2be5a13@gmail.com> I also agree with "Use external gdb debug symbols file" being ON by default for a new Lazarus project. Unless of course some debug info formats didn't support it, which would raise other questions. This is only a default option for new projects, which would affect mostly new users or quick test projects, where it should always be beneficial to keep executable file small. Denis On 20/05/2017 11:24, Giuliano Colla via Lazarus wrote: > I had tried in remote times to activate the "use external gdb debug > symbols file" option, and it didn't work properly, so I forgot about > it. But some time ago I tried again, and now it turns out to work > perfectly, at least under Linux. > > Wouldn't it be nice to set it active by default? > > This could make unnecessary in many cases a different build mode for > testing and for deploying, and would stop the complaints about "long > executable". > > Giuliano > > From erickom at metropolitancollege.co.za Mon May 22 10:41:28 2017 From: erickom at metropolitancollege.co.za (Eric Kom) Date: Mon, 22 May 2017 10:41:28 +0200 Subject: [Lazarus] Error: Identifier not found "FileExistsUTF8" Message-ID: <19e45ace-ac10-b17a-f89d-ffb1f21077d6@metropolitancollege.co.za> Good day Folks, I got a program that was coded with lazarus 16.x using fpc 2.7. Now I have installed lazarus 1.9 with fpc 3.1.1 During compiled process, I receieved an Error: Identifier not found "FileExistsUTF8" The function FileExistsUTF8 in the fileUtil it is depreciated? Please how to I resolve this? Thanks From zeljko at holobit.net Mon May 22 10:47:49 2017 From: zeljko at holobit.net (zeljko) Date: Mon, 22 May 2017 10:47:49 +0200 Subject: [Lazarus] Error: Identifier not found "FileExistsUTF8" In-Reply-To: <19e45ace-ac10-b17a-f89d-ffb1f21077d6@metropolitancollege.co.za> References: <19e45ace-ac10-b17a-f89d-ffb1f21077d6@metropolitancollege.co.za> Message-ID: On 05/22/2017 10:41 AM, Eric Kom via Lazarus wrote: > Good day Folks, > > I got a program that was coded with lazarus 16.x using fpc 2.7. > > Now I have installed lazarus 1.9 with fpc 3.1.1 > > During compiled process, I receieved an Error: Identifier not found > "FileExistsUTF8" > > The function FileExistsUTF8 in the fileUtil it is depreciated? Yes > Please how to I resolve this? Add lazutils package to your project, add LazFileUtils unit instead of FileUtils. zeljko From nc-gaertnma at netcologne.de Mon May 22 10:54:22 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Mon, 22 May 2017 10:54:22 +0200 Subject: [Lazarus] Error: Identifier not found "FileExistsUTF8" In-Reply-To: References: <19e45ace-ac10-b17a-f89d-ffb1f21077d6@metropolitancollege.co.za> Message-ID: <20170522105422.2664130e@limapholos.matflo.wg> On Mon, 22 May 2017 10:47:49 +0200 zeljko via Lazarus wrote: > On 05/22/2017 10:41 AM, Eric Kom via Lazarus wrote: > > Good day Folks, > > > > I got a program that was coded with lazarus 16.x using fpc 2.7. > > > > Now I have installed lazarus 1.9 with fpc 3.1.1 > > > > During compiled process, I receieved an Error: Identifier not found > > "FileExistsUTF8" > > > > The function FileExistsUTF8 in the fileUtil it is depreciated? > > Yes > > > Please how to I resolve this? > > Add lazutils package to your project, add LazFileUtils unit instead of > FileUtils. Note: You don't need to add package LazUtils to the project. If your code used FileExistsUTF8 you already have it directly or indirectly. Mattias From erickom at metropolitancollege.co.za Mon May 22 10:59:49 2017 From: erickom at metropolitancollege.co.za (Eric Kom) Date: Mon, 22 May 2017 10:59:49 +0200 Subject: [Lazarus] Error: Identifier not found "FileExistsUTF8" In-Reply-To: References: <19e45ace-ac10-b17a-f89d-ffb1f21077d6@metropolitancollege.co.za> Message-ID: On 22/05/2017 10:47, zeljko via Lazarus wrote: > On 05/22/2017 10:41 AM, Eric Kom via Lazarus wrote: >> Good day Folks, >> >> I got a program that was coded with lazarus 16.x using fpc 2.7. >> >> Now I have installed lazarus 1.9 with fpc 3.1.1 >> >> During compiled process, I receieved an Error: Identifier not found >> "FileExistsUTF8" >> >> The function FileExistsUTF8 in the fileUtil it is depreciated? > > Yes > >> Please how to I resolve this? > > Add lazutils package to your project, add LazFileUtils unit instead of > FileUtils. Instructed, and work fine. Thanks > > zeljko > > From mailinglists at geldenhuys.co.uk Mon May 22 15:57:27 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 22 May 2017 14:57:27 +0100 Subject: [Lazarus] intercepting keyboard events In-Reply-To: References: Message-ID: <5c80352f-1e5b-3198-8532-0ce58631bcec@geldenhuys.co.uk> On 2017-05-08 17:46, zeljko via Lazarus wrote: > Just to be sure that control actually can take focus put this > ControlStyle := ControlStyle - [csNoFocus]; > into constructor of your control. And what if that doesn't work? I've set that in the constructor, but still it doesn't receive keyboard focus (after I've clicked on the custom control)? What else can I try? eg: I have a PageControl which contains my custom control. I then have a treeview on the right. If the treeview had focus, and I click on my custom control and then press some keys (eg: Up/Down) then the focused node in the treeview changes. Keyboard focus doesn't seem to want to move to the custom control. ps #2: Interacting with a mouse on my custom control seems to work (but then I have SetFocus in the MouseDown too). Regards, Graeme From lazarus at kluug.net Mon May 22 16:01:04 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Mon, 22 May 2017 16:01:04 +0200 Subject: [Lazarus] intercepting keyboard events In-Reply-To: <5c80352f-1e5b-3198-8532-0ce58631bcec@geldenhuys.co.uk> References: <5c80352f-1e5b-3198-8532-0ce58631bcec@geldenhuys.co.uk> Message-ID: <384715a4-d58c-82fd-bd23-9abbdc94ecdc@kluug.net> On 22.05.2017 15:57, Graeme Geldenhuys via Lazarus wrote: > On 2017-05-08 17:46, zeljko via Lazarus wrote: >> Just to be sure that control actually can take focus put this >> ControlStyle := ControlStyle - [csNoFocus]; >> into constructor of your control. > > And what if that doesn't work? I've set that in the constructor, but > still it doesn't receive keyboard focus (after I've clicked on the > custom control)? > > What else can I try? > > eg: > I have a PageControl which contains my custom control. I then have a > treeview on the right. If the treeview had focus, and I click on my > custom control and then press some keys (eg: Up/Down) then the focused > node in the treeview changes. Keyboard focus doesn't seem to want to > move to the custom control. > > ps #2: > Interacting with a mouse on my custom control seems to work (but > then I have SetFocus in the MouseDown too). Zeljko was wrong in his statement. The csNoFocus is just a helper flag that custom controls should follow but don't have to. TWinControl directly doesn't do anything. with csNoFocus - it doesn't have any meaning for it. Follow my instruction from my previous email in this thread: If you mean receiving focus by clicking on it then yes, you need to call SetFocus in MouseDown. It's also a good idea to check the csNoFocus flag (from ControlStyle property). For an example look how it is done in TCustomDBGrid.MouseDown. + The control can always get focused by the Tab key, if TabStop=True. Ondrej From aaa5500 at ya.ru Mon May 22 16:01:11 2017 From: aaa5500 at ya.ru (Alexey) Date: Mon, 22 May 2017 17:01:11 +0300 Subject: [Lazarus] intercepting keyboard events In-Reply-To: <5c80352f-1e5b-3198-8532-0ce58631bcec@geldenhuys.co.uk> References: <5c80352f-1e5b-3198-8532-0ce58631bcec@geldenhuys.co.uk> Message-ID: <0850169b-1252-3b02-abac-dea131928c1f@ya.ru> On 22.05.2017 16:57, Graeme Geldenhuys via Lazarus wrote: > What else can I try? Adding public SetFocus; override;-- procedure TATSynEdit.SetFocus; begin LCLIntf.SetFocus(Handle); end; -- Regards, Alexey From mailinglists at geldenhuys.co.uk Mon May 22 16:02:22 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 22 May 2017 15:02:22 +0100 Subject: [Lazarus] intercepting keyboard events In-Reply-To: <5c80352f-1e5b-3198-8532-0ce58631bcec@geldenhuys.co.uk> References: <5c80352f-1e5b-3198-8532-0ce58631bcec@geldenhuys.co.uk> Message-ID: <0ce00c2c-9443-0c68-bcc8-9a1b76b0cd29@geldenhuys.co.uk> On 2017-05-22 14:57, Graeme Geldenhuys via Lazarus wrote: > And what if that doesn't work? Ignore that. I forced a Rebuild of all units, and now suddenly it is working as expected. Regards, Graeme From mailinglists at geldenhuys.co.uk Mon May 22 16:05:23 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 22 May 2017 15:05:23 +0100 Subject: [Lazarus] intercepting keyboard events In-Reply-To: <384715a4-d58c-82fd-bd23-9abbdc94ecdc@kluug.net> References: <5c80352f-1e5b-3198-8532-0ce58631bcec@geldenhuys.co.uk> <384715a4-d58c-82fd-bd23-9abbdc94ecdc@kluug.net> Message-ID: <08416541-1a8c-7b18-9c39-08e98bd7379b@geldenhuys.co.uk> On 2017-05-22 15:01, Ondrej Pokorny via Lazarus wrote: > For an example look how it is done in TCustomDBGrid.MouseDown. > > + The control can always get focused by the Tab key, if TabStop=True. I'll double check that as well, just to be sure. Thanks to both for the very prompt replies. Much appreciated. Regards, Graeme From lazarus at kluug.net Mon May 22 16:19:46 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Mon, 22 May 2017 16:19:46 +0200 Subject: [Lazarus] intercepting keyboard events In-Reply-To: <08416541-1a8c-7b18-9c39-08e98bd7379b@geldenhuys.co.uk> References: <5c80352f-1e5b-3198-8532-0ce58631bcec@geldenhuys.co.uk> <384715a4-d58c-82fd-bd23-9abbdc94ecdc@kluug.net> <08416541-1a8c-7b18-9c39-08e98bd7379b@geldenhuys.co.uk> Message-ID: <48b25b9e-3bf9-5d2a-0681-d7b6c12d6d4b@kluug.net> On 22.05.2017 16:05, Graeme Geldenhuys via Lazarus wrote: > On 2017-05-22 15:01, Ondrej Pokorny via Lazarus wrote: >> For an example look how it is done in TCustomDBGrid.MouseDown. >> >> + The control can always get focused by the Tab key, if TabStop=True. > > > I'll double check that as well, just to be sure. > Thanks to both for the very prompt replies. Much appreciated. I checked again and it seems that Zeljko wrote Qt bindings so that they take care of the csNoFocus flag. But no other WidgetSet does so. So there probably is an incompatibility between LCL WidgetSets regarding this. csNoFocus has no effect on plain win32 TWinControl and it's descendants that do not handle csNoFocus explicitely (and are not bound to native widgets - they are special, see below). It is also so that some (maybe all) native win32 widgets (edit, button etc.) always get focused automatically if they are clicked on with the mouse and they are enabled - you cannot have a clickable TButton that doesn't receive focus when clicked on but receives focus with TAB key. With a custom non-native button it is perfectly possible. Ondrej From donald at ziesig.org Mon May 22 18:35:53 2017 From: donald at ziesig.org (Donald Ziesig) Date: Mon, 22 May 2017 12:35:53 -0400 Subject: [Lazarus] Building a project with generics in libraries Laz1.9, FPC 3.0.2. Message-ID: <82c513fb-1a17-3902-f414-15b22f28cbdf@ziesig.org> Hi All! I have a rather large project that I have been refactoring from an earlier version that works. It is implemented in Laz 1.6.2. The new version takes considerable advantage of generics (which I learned first from Ada in the 1970s, then from C++ in the 1980s). The resulting code is much smaller and cleaner than the old code. During the development process I noticed some strangeness while debugging. Frequently I will step through code and the debugger behaves as if recent changes have not been made (even though the source shows the changes). This has cost me days of debugging before the problem /miraculously /seems to be cured. In other words I could not figure out why all of my earlier edits seemed to take effect without my doing anything explicitly to fix the problem. (One other side effect is that gdb will occasionally crash when I let the mouse hover over certain identifiers after a breakpoint). I have finally discovered the apparent cause and a magic (but annoying) workaround. The steps in the cause: A) a1) Edit a library routine that contains generic code. a2) Run with or without Debug. (The IDE recompiles the library first). The code executes as if the edits never were made. or B) b1) Edit a library routine that contains generic code. b2) Compile the library using the Library Inspector. b3) Run with or without Debug. The code executes as if the edits never were made. The magic workaround is very simple: C) c1) Edit a library routine that contains generic code. c2) Compile the library using the Library Inspector. *c3) Build the program using "Run | Cleanup and build..." or sometimes just "Run | Build"* (I haven't found a pattern to decide which needs to be used so I currently use the Cleanup and build option). c4) Run with or without Debug. The edited code executes as written. Note that the workaround is only necessary if the library's generic code is edited. If the generic code is in the main code tree, the normal process of edit, run, debug, ... builds and runs correctly. I think the problem is that the modules in the main source tree that instantiate the generics are not being updated unless the project is re-built explicitly (why? I don't know). I will try to submit a bug report with a sample project after my current refactoring job is done (tight schedule, needs to be installed by the end of June). Don Ziesig -------------- next part -------------- An HTML attachment was scrubbed... URL: From pascaldragon at googlemail.com Mon May 22 18:55:14 2017 From: pascaldragon at googlemail.com (Sven Barth) Date: Mon, 22 May 2017 18:55:14 +0200 Subject: [Lazarus] Building a project with generics in libraries Laz1.9, FPC 3.0.2. In-Reply-To: <82c513fb-1a17-3902-f414-15b22f28cbdf@ziesig.org> References: <82c513fb-1a17-3902-f414-15b22f28cbdf@ziesig.org> Message-ID: Am 22.05.2017 18:36 schrieb "Donald Ziesig via Lazarus" < lazarus at lists.lazarus-ide.org>: > I will try to submit a bug report with a sample project after my current refactoring job is done (tight schedule, needs to be installed by the end of June). A bug report with a small, self contained example would indeed be nice as generic problems are sometimes a PITA to pinpoint otherwise. If you can manage you could also try with 3.1.1 if that changes anything. Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From kapibara.pas at aol.com Mon May 22 23:39:45 2017 From: kapibara.pas at aol.com (kapibara) Date: Mon, 22 May 2017 23:39:45 +0200 Subject: [Lazarus] Order of events: TEdit / TListBox Message-ID: <25879185-3cb0-0194-125c-007af86c92f8@aol.com> Is this a bug? Simple demo: TEdit and TListBox are on a form. The TEdit is used to rename selected string in the ListBox. The code for renaming is in the Exit event of the TEdit. When an item in the ListBox is selected, the Edit.Exit should fire and copy the Edit.Text to the current item in the ListBox. The OnSelectionChange then copies the name of the selected ListBox item to the TEdit. This only works if selecting the already selected item in the ListBox. If instead another Item is selected, the Edit.Text is overwritten before it is copied to the old ListBox item: the ListBox.OnSelectionChange fires before Edit.Exit. ListBox.OnSelectionChange fires *before* both ListBox.Click and Edit.Exit. I would expect Click to fire before SelectionChange? And Edit.Exit before ListBox.Click, which it does, but only if OnSelectionChange doesn't fire at all. Clicking an item in the ListBox that is already selected results in the same event order as in Delphi: Edit.Exit -> ListBox.Click. Lazarus trunk, GTK2 Linux There is an attached project. -------------- next part -------------- A non-text attachment was scrubbed... Name: OrderOfEvents.zip Type: application/zip Size: 2458 bytes Desc: not available URL: From kapibara.pas at aol.com Mon May 22 23:44:11 2017 From: kapibara.pas at aol.com (kapibara) Date: Mon, 22 May 2017 23:44:11 +0200 Subject: [Lazarus] Order of events: TEdit / TListBox In-Reply-To: <25879185-3cb0-0194-125c-007af86c92f8@aol.com> References: <25879185-3cb0-0194-125c-007af86c92f8@aol.com> Message-ID: Showing events. -------------- next part -------------- A non-text attachment was scrubbed... Name: EventOrder.png Type: image/png Size: 18252 bytes Desc: not available URL: From kapibara.pas at aol.com Tue May 23 04:15:22 2017 From: kapibara.pas at aol.com (kapibara) Date: Tue, 23 May 2017 04:15:22 +0200 Subject: [Lazarus] Order of events: TEdit / TListBox In-Reply-To: <25879185-3cb0-0194-125c-007af86c92f8@aol.com> References: <25879185-3cb0-0194-125c-007af86c92f8@aol.com> Message-ID: <38d532f0-40d0-6563-839e-43e46efa1c62@aol.com> Some more findings. Under Windows, the Edit.Exit event fires before both SelectionChange and OnClick no matter what item you select. Plus under Windows, SelectionChange fires even though an item might already be selected which it doesn't under Linux GTK2. Under both environments, the Click event fires after SelectionChange.. -------------- next part -------------- A non-text attachment was scrubbed... Name: event_orders_win.png Type: image/png Size: 10967 bytes Desc: not available URL: From zeljko at holobit.net Tue May 23 09:18:33 2017 From: zeljko at holobit.net (zeljko) Date: Tue, 23 May 2017 09:18:33 +0200 Subject: [Lazarus] Order of events: TEdit / TListBox In-Reply-To: <38d532f0-40d0-6563-839e-43e46efa1c62@aol.com> References: <25879185-3cb0-0194-125c-007af86c92f8@aol.com> <38d532f0-40d0-6563-839e-43e46efa1c62@aol.com> Message-ID: <875e2b9f-a066-20c5-0e15-b47911134ef8@holobit.net> On 05/23/2017 04:15 AM, kapibara via Lazarus wrote: > Some more findings. Under Windows, the Edit.Exit event fires before both > SelectionChange and OnClick no matter what item you select. It's normal. If you click onto listbox (OnMouseDown of listbox triggers), TEdit looses focus and triggers OnExit() > Plus under Windows, SelectionChange fires even though an item might > already be selected which it doesn't under Linux GTK2. Under both > environments, the Click event fires after SelectionChange.. OnClick() is passed after OnMouseDown() + OnMouseUp(), so it's normal. When you press one item with mouse selection changes (click isn't triggered yet), releasing mouse triggers MouseUp and Click(). zeljko From russeld.lists at gmail.com Tue May 23 12:35:36 2017 From: russeld.lists at gmail.com (Russ) Date: Tue, 23 May 2017 12:35:36 +0200 Subject: [Lazarus] Show value hints while debugging fills screen - patch Message-ID: <6b2e4b90-a087-ef65-5374-91831048470a@gmail.com> I find debugging value hints (TurboPowerIProDsgn installed, "Show value hints while debugging") useful but annoying when the hint becomes so big it covers the variable being checked or even fills the screen; on single monitor systems the only way to close the hint is to scroll down to the variable link. Especially annoying when the mouse-over was inadvertent. The following code illustrates the problem: program HugeHintProblem; var HugeHintVar: array[1..100, 1..100] of byte; i, j: Integer; begin for i := 1 to 100 do for j := 1 to 100 do HugeHintVar[i,j] := random(255); { Break on the next statement and mouse-over HugeHintVar - The hint will fill the screen (this may take some time).} HugeHintVar[1, 1] := 56; end. The following patch seems to fix the problem, limiting the hint span from the left side of the variable and one line below to the bottom right corner of the editor in undocked mode, and to the bottom right corner of the IDE in docked mode. Index: components/ideintf/idehelpintf.pas =================================================================== --- components/ideintf/idehelpintf.pas (revision 55056) +++ components/ideintf/idehelpintf.pas (working copy) @@ -383,6 +383,8 @@ end; procedure DoHtml; + var + MaxWidth, MaxHeight: Integer; begin if HintFont<>nil then HintRenderWindow.Font := HintFont; @@ -397,10 +399,16 @@ ms.Free; end; HtmlHelpProvider.ControlIntf.GetPreferredControlSize(NewWidth,NewHeight); + MaxWidth := Screen.ActiveForm.Left + Screen.ActiveForm.Width - ScreenPos.x; + MaxHeight := Screen.ActiveForm.Top + Screen.ActiveForm.Height - ScreenPos.y; if NewWidth <= 0 then - NewWidth := 500; + NewWidth := 500 + else if NewWidth > MaxWidth then + NewWidth := MaxWidth; if NewHeight <= 0 then - NewHeight := 200; + NewHeight := 200 + else if NewHeight > MaxHeight then + NewHeight := MaxHeight; HintRenderWindow.HintRectAdjust := Rect(0, 0, NewWidth, NewHeight); if MouseOffset then HintRenderWindow.OffsetHintRect(ScreenPos) I have tested this with windows XP, 7 and 8.1, Lazarus V1.64, V1.65 and trunk, and with two monitors in various configurations I tried to register an account on the bug tracker twice, but the link in the confirmation email leads to an APPLICATION ERROR #1902 in Mantis, complaining about an invalid confirmation URL Regards Russell --- This email has been checked for viruses by AVG. http://www.avg.com From kapibara.pas at aol.com Tue May 23 15:27:00 2017 From: kapibara.pas at aol.com (kapibara) Date: Tue, 23 May 2017 15:27:00 +0200 Subject: [Lazarus] Order of events: TEdit / TListBox In-Reply-To: <875e2b9f-a066-20c5-0e15-b47911134ef8@holobit.net> References: <25879185-3cb0-0194-125c-007af86c92f8@aol.com> <38d532f0-40d0-6563-839e-43e46efa1c62@aol.com> <875e2b9f-a066-20c5-0e15-b47911134ef8@holobit.net> Message-ID: On 05/23/2017 09:18 AM, zeljko wrote: > It's normal. If you click onto listbox (OnMouseDown of listbox > triggers), TEdit looses focus and triggers OnExit() > Thanks for the reply. Yes, on Windows, Lazarus and Delphi 7 behave the same. Except that Delphi 7 doesn't have the ListBox.SelectionChange event: Lazarus Win platform: Edit.Exit always fires before ListBox.OnClick (and OnSelectionChange), no matter if the ListBox item is selected or not. Good. Though I would not expect SelectionChange to fired since there is no change in selection? Problem is with Lazarus Linux GTK2. Events behave the *opposite* to Windows Lazarus and Delphi 7: 1) SelectionChange does not fire when clicking an already selected item. I might be wrong, but thats good I think and the windows implementation bad? 2) Edit.Exit fires BEFORE ListBox.OnClick if selecting and already selected ListBox item. Good. 3) Edit.Exit fires AFTER ListBox.SelectionChange and ListBox.OnClick if selecting a different ListBox item than the currently selected one. Bad. So the behaviour is inconsistent between platforms, and also inconsistent within the same control (TListBox) depending on what item is selected. From zeljko at holobit.net Tue May 23 15:53:56 2017 From: zeljko at holobit.net (zeljko) Date: Tue, 23 May 2017 15:53:56 +0200 Subject: [Lazarus] Order of events: TEdit / TListBox In-Reply-To: References: <25879185-3cb0-0194-125c-007af86c92f8@aol.com> <38d532f0-40d0-6563-839e-43e46efa1c62@aol.com> <875e2b9f-a066-20c5-0e15-b47911134ef8@holobit.net> Message-ID: <869cacf7-a568-9a66-ccc9-f008418db5f4@holobit.net> On 05/23/2017 03:27 PM, kapibara via Lazarus wrote: > On 05/23/2017 09:18 AM, zeljko wrote: >> It's normal. If you click onto listbox (OnMouseDown of listbox >> triggers), TEdit looses focus and triggers OnExit() >> > > Thanks for the reply. > > Yes, on Windows, Lazarus and Delphi 7 behave the same. Except that > Delphi 7 doesn't have the ListBox.SelectionChange event: > > Lazarus Win platform: Edit.Exit always fires before ListBox.OnClick (and > OnSelectionChange), no matter if the ListBox item is selected or not. > Good. Though I would not expect SelectionChange to fired since there is > no change in selection? > > Problem is with Lazarus Linux GTK2. Events behave the *opposite* to > Windows Lazarus and Delphi 7: > > 1) SelectionChange does not fire when clicking an already selected item. > I might be wrong, but thats good I think and the windows implementation > bad? > 2) Edit.Exit fires BEFORE ListBox.OnClick if selecting and already > selected ListBox item. Good. > 3) Edit.Exit fires AFTER ListBox.SelectionChange and ListBox.OnClick if > selecting a different ListBox item than the currently selected one. Bad. > > So the behaviour is inconsistent between platforms, and also > inconsistent within the same control (TListBox) depending on what item > is selected. Please open an issue about it and I'll take a look on it. zeljko From mailinglists at geldenhuys.co.uk Tue May 23 16:05:00 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Tue, 23 May 2017 15:05:00 +0100 Subject: [Lazarus] Order of events: TEdit / TListBox In-Reply-To: References: <25879185-3cb0-0194-125c-007af86c92f8@aol.com> <38d532f0-40d0-6563-839e-43e46efa1c62@aol.com> <875e2b9f-a066-20c5-0e15-b47911134ef8@holobit.net> Message-ID: <94fb34ca-88f2-0cb7-5c7b-1cce3dcf4b2c@geldenhuys.co.uk> On 2017-05-23 14:27, kapibara via Lazarus wrote: > So the behaviour is inconsistent between platforms, and also > inconsistent within the same control (TListBox) depending on what item > is selected. I believe I have reported that back in 2006 already. If not the same component, then one of the list components, but I think it was TListBox too. I'm afraid LCL is full of inconsistencies like that - between platforms and between widgetsets. If memory serves me correctly, I was told it wouldn't be fixed, because such behaviour is dependent on the underlying GUI toolkit, so developers just have to figure out a work-around in their applications. Our code became an IFDEF mess, and shortly afterwards fpGUI was born. Regards, Graeme From kapibara.pas at aol.com Tue May 23 16:48:57 2017 From: kapibara.pas at aol.com (kapibara) Date: Tue, 23 May 2017 16:48:57 +0200 Subject: [Lazarus] Order of events: TEdit / TListBox In-Reply-To: <869cacf7-a568-9a66-ccc9-f008418db5f4@holobit.net> References: <25879185-3cb0-0194-125c-007af86c92f8@aol.com> <38d532f0-40d0-6563-839e-43e46efa1c62@aol.com> <875e2b9f-a066-20c5-0e15-b47911134ef8@holobit.net> <869cacf7-a568-9a66-ccc9-f008418db5f4@holobit.net> Message-ID: <5cdedf85-ff84-75f4-f697-6735f3a43186@aol.com> Thanks, https://bugs.freepascal.org/view.php?id=31900 > > Please open an issue about it and I'll take a look on it. > > zeljko From coppolastudio at gmail.com Tue May 23 19:10:01 2017 From: coppolastudio at gmail.com (Salvatore Coppola) Date: Tue, 23 May 2017 19:10:01 +0200 Subject: [Lazarus] Lazarus The Complete Guide Message-ID: Hi to all the authors, is in program a new edition of the guide? -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaa5500 at ya.ru Tue May 23 19:38:42 2017 From: aaa5500 at ya.ru (Alexey) Date: Tue, 23 May 2017 20:38:42 +0300 Subject: [Lazarus] Use rare Win32 API in LCLIntf.SetForegroundWindow Message-ID: <3bf6e786-bce3-a2cf-2392-ab45df45f04e@ya.ru> What do you think about using this rare API [beginning from WinXP] in LCLIntf fnction? It will make LCL function work more stable: window will always go to foreground. I used it in CudaText. It works. https://github.com/Alexey-T/CudaText/blob/master/app/fix_focus_window.pas -- Regards, Alexey From lazarus at kluug.net Tue May 23 19:43:48 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Tue, 23 May 2017 19:43:48 +0200 Subject: [Lazarus] Use rare Win32 API in LCLIntf.SetForegroundWindow In-Reply-To: <3bf6e786-bce3-a2cf-2392-ab45df45f04e@ya.ru> References: <3bf6e786-bce3-a2cf-2392-ab45df45f04e@ya.ru> Message-ID: On 23.05.2017 19:38, Alexey via Lazarus wrote: > What do you think about using this rare API [beginning from WinXP] in > LCLIntf fnction? It will make LCL function work more stable: window > will always go to foreground. I used it in CudaText. It works. > > https://github.com/Alexey-T/CudaText/blob/master/app/fix_focus_window.pas What are the equivalents for Qt, Qt5, Gtk2, Carbon, Cocoa? Ondrej From mailinglists at geldenhuys.co.uk Tue May 23 19:50:42 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Tue, 23 May 2017 18:50:42 +0100 Subject: [Lazarus] Use rare Win32 API in LCLIntf.SetForegroundWindow In-Reply-To: References: <3bf6e786-bce3-a2cf-2392-ab45df45f04e@ya.ru> Message-ID: On 2017-05-23 18:43, Ondrej Pokorny via Lazarus wrote: > What are the equivalents for Qt, Qt5, Gtk2, Carbon, Cocoa? For anything running under X11 I have never had a problem with XRaiseWindow(xapplication.display, FWinHandle); So Qt and GTK could you that, if they aren't already. 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 aaa5500 at ya.ru Tue May 23 20:01:50 2017 From: aaa5500 at ya.ru (Alexey) Date: Tue, 23 May 2017 21:01:50 +0300 Subject: [Lazarus] Use rare Win32 API in LCLIntf.SetForegroundWindow In-Reply-To: References: <3bf6e786-bce3-a2cf-2392-ab45df45f04e@ya.ru> Message-ID: On 23.05.2017 20:43, Ondrej Pokorny via Lazarus wrote: > What are the equivalents for Qt, Qt5, Gtk2, Carbon, Cocoa? I meaned - to use in _inside_ LCLIntf.SetForegrondWindow, not making new LCL func. -- Regards, Alexey From michael at freepascal.org Tue May 23 20:43:11 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Tue, 23 May 2017 20:43:11 +0200 (CEST) Subject: [Lazarus] Lazarus The Complete Guide In-Reply-To: References: Message-ID: On Tue, 23 May 2017, Salvatore Coppola via Lazarus wrote: > Hi to all the authors, > is in program a new edition of the guide? > Yes, but no date is set. Michael. From Sascha.Hestermann at gmx.de Wed May 24 07:26:56 2017 From: Sascha.Hestermann at gmx.de (John Landmesser) Date: Wed, 24 May 2017 06:26:56 +0100 Subject: [Lazarus] =?utf-8?q?something_new?= Message-ID: <1789949602.20170524082656@gmx.de> Hey! I've got something new and surprising for you, just take a look at it http://see.netnexis.com John Landmesser From: Lazarus [mailto:Lazarus at lists.lazarus.freepascal.org] Sent: Wednesday, May 24, 2017 1:26 AM To: Sascha.Hestermann at gmx.de Subject: Holy shit that was fast I know you said going back to Kuwait is almost impossible now, but if you still have any connections there you should try to get any old job there. Contact former co-workers from there and let them know of your situation. You said you worked with the royal family so I'm guess that counts for something. It would be easier to get your kids from Egypt to Kuwait than Egypt to US. Once you get some money saved up you can try moving back again. That robe and scarf look cool on you habib! Sent from Mail for Windows 10 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 7B1A297F1024A4A9978ADEDD6FE0D268.jpg Type: image/jpeg Size: 19595 bytes Desc: not available URL: From Sascha.Hestermann at gmx.de Wed May 24 07:27:37 2017 From: Sascha.Hestermann at gmx.de (Gabor Boros) Date: Wed, 24 May 2017 07:27:37 +0200 Subject: [Lazarus] =?utf-8?q?=E2=98=AFRe=3A_very_interesting_stuff?= Message-ID: <1305036968.20170524082737@gmx.de> Hey, I've found that interesting stuff and I just wanted to show it to you. Just take a look http://ahead.lucespictures.com Be well, Gabor Boros From noreply at z505.com Wed May 24 20:43:10 2017 From: noreply at z505.com (noreply at z505.com) Date: Wed, 24 May 2017 13:43:10 -0500 Subject: [Lazarus] CodeTools On Event insert? detect Message-ID: I am looking for a way to detect when someone has added an event in the ide, for example button1click.. When someone double clicks a button in lazarus it generates code in the IDE for the event handler procedure.. I want to intercept/detect this, and add SomeCode(); between the begin/end of the event, i.e. on button 1 click. Does codetools provide some way to do it? It has a way to search the source code for a procedure and enter code, but how do you detect when an event is added to the source code? From dezlov at gmail.com Wed May 24 23:25:35 2017 From: dezlov at gmail.com (Denis Kozlov) Date: Wed, 24 May 2017 22:25:35 +0100 Subject: [Lazarus] Use rare Win32 API in LCLIntf.SetForegroundWindow In-Reply-To: <3bf6e786-bce3-a2cf-2392-ab45df45f04e@ya.ru> References: <3bf6e786-bce3-a2cf-2392-ab45df45f04e@ya.ru> Message-ID: <8250ff57-0aab-33ef-c49b-90501b6766aa@gmail.com> I would advise strongly against the use of SwitchToThisWindow API function in Lazarus. Mainly because it states in the docs: /This function is not intended for general use. It may be altered or unavailable in subsequent versions of Windows./ Read more in Raymond Chen's blog - The life story of the SwitchToThisWindow function: https://blogs.msdn.microsoft.com/oldnewthing/20111107-00/?p=9183 Denis On 23/05/2017 18:38, Alexey via Lazarus wrote: > What do you think about using this rare API [beginning from WinXP] in > LCLIntf fnction? It will make LCL function work more stable: window > will always go to foreground. I used it in CudaText. It works. > > https://github.com/Alexey-T/CudaText/blob/master/app/fix_focus_window.pas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Special at Joepgen.com Thu May 25 18:46:43 2017 From: Special at Joepgen.com (Joe) Date: Thu, 25 May 2017 18:46:43 +0200 Subject: [Lazarus] Lazarus 1.8 RC1 under Raspbian Jessie Message-ID: I am trying to test Lazarus 1.8 RC1 (and following versions) under Raspbian Jessie with PIXEL. But unfortunately I could not find any instructions or scripts helping to install *this* RC. Any hint? Regards -Joe From noreply at z505.com Fri May 26 08:21:59 2017 From: noreply at z505.com (noreply at z505.com) Date: Fri, 26 May 2017 01:21:59 -0500 Subject: [Lazarus] Codetools OnBeforeCompile/After events Message-ID: Does something like OnBeforeCompile/OnAfterCompile exist in codetools? If not, would it be acceptable as a new code tool, or any criticisms if it is a bad idea? (I can work on a unit that does it, or would it be better to add it to one of the existing codetools units?) AFAIR delphi had something like it, but its been a while since I worked with delphi ide tools. From lazarus at kluug.net Fri May 26 08:24:04 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Fri, 26 May 2017 08:24:04 +0200 Subject: [Lazarus] Codetools OnBeforeCompile/After events In-Reply-To: References: Message-ID: <6d8afba5-8164-6ed5-87b0-2177f94fafb1@kluug.net> On 26.05.2017 8:21, Lars via Lazarus wrote: > Does something like OnBeforeCompile/OnAfterCompile exist in codetools? Yes, they exists. "OnAfterCompile": LazarusIDE.AddHandlerOnProjectBuildingFinished(@MyEvent); LazarusIDE.AddHandlerOnLazarusBuildingFinished(@MyEvent); Ondrej From noreply at z505.com Fri May 26 08:40:27 2017 From: noreply at z505.com (noreply at z505.com) Date: Fri, 26 May 2017 01:40:27 -0500 Subject: [Lazarus] Codetools OnBeforeCompile/After events In-Reply-To: <6d8afba5-8164-6ed5-87b0-2177f94fafb1@kluug.net> References: <6d8afba5-8164-6ed5-87b0-2177f94fafb1@kluug.net> Message-ID: <8df36e5622a919423b933c1dd567871d@z505.com> On 2017-05-26 01:24, Ondrej Pokorny via Lazarus wrote: > On 26.05.2017 8:21, Lars via Lazarus wrote: >> Does something like OnBeforeCompile/OnAfterCompile exist in codetools? > > Yes, they exists. "OnAfterCompile": > > LazarusIDE.AddHandlerOnProjectBuildingFinished(@MyEvent); > LazarusIDE.AddHandlerOnLazarusBuildingFinished(@MyEvent); > > Ondrej > -- Ahh, maybe I am looking at codetools when I should be looking at lazideintf.pp instead. As that's where those are located.. For some reason I thought it would be part of code tools for writing plugins to the ide. Thanks. From mailinglists at geldenhuys.co.uk Fri May 26 10:21:32 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 26 May 2017 09:21:32 +0100 Subject: [Lazarus] The "Publish Package" functionality is horribly broken. Message-ID: <228998ae-3a6f-ac0b-fec7-b206c1a0e7d7@geldenhuys.co.uk> Hi, I noticed this menu option in the fpgui_toolkit.lpk package. So I selected it and made sure the “include” filter selects all files, and nothing is “excluded”. This clicked okay. After that I had a look in the destination directory, and there was only 9 file. Yet the fpgui_toolkit.lpk package actually has 117 files. See the screenshot showing the result (blue window) vs the actual package files. So again, what is the function of “publish package”? It it is meant to copy all units from a package to a destination directory (*), it fails miserably at that. I'm using Lazarus 1.9.0 r54792 FPC 2.6.4 x86_64-freebsd-gtk2 * - Seems that is supposed to be its function, based on the wiki help page. But clearly it doesn't do a good job. [http://wiki.lazarus.freepascal.org/IDE_Window:_Package_Editor#More] 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: shot.png Type: image/png Size: 37110 bytes Desc: not available URL: From nc-gaertnma at netcologne.de Fri May 26 11:12:48 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Fri, 26 May 2017 11:12:48 +0200 Subject: [Lazarus] Codetools OnBeforeCompile/After events In-Reply-To: <8df36e5622a919423b933c1dd567871d@z505.com> References: <6d8afba5-8164-6ed5-87b0-2177f94fafb1@kluug.net> <8df36e5622a919423b933c1dd567871d@z505.com> Message-ID: <20170526111248.1b214170@limapholos.matflo.wg> On Fri, 26 May 2017 01:40:27 -0500 Lars via Lazarus wrote: > On 2017-05-26 01:24, Ondrej Pokorny via Lazarus wrote: > > On 26.05.2017 8:21, Lars via Lazarus wrote: > >> Does something like OnBeforeCompile/OnAfterCompile exist in codetools? > > > > Yes, they exists. "OnAfterCompile": > > > > LazarusIDE.AddHandlerOnProjectBuildingFinished(@MyEvent); > > LazarusIDE.AddHandlerOnLazarusBuildingFinished(@MyEvent); > > > > Ondrej > > -- > > Ahh, maybe I am looking at codetools when I should be looking at > lazideintf.pp instead. > As that's where those are located.. This may help: http://wiki.freepascal.org/Extending_the_IDE > For some reason I thought it would be part of code tools for writing > plugins to the ide. Codetools is standalone package and the IDE uses it a lot. Mattias From nc-gaertnma at netcologne.de Fri May 26 11:44:12 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Fri, 26 May 2017 11:44:12 +0200 Subject: [Lazarus] CodeTools On Event insert? detect In-Reply-To: References: Message-ID: <20170526114412.2d4ec1f6@limapholos.matflo.wg> On Wed, 24 May 2017 13:43:10 -0500 Lars via Lazarus wrote: >[...] > I want to intercept/detect this, and add > > SomeCode(); > > between the begin/end of the event, i.e. on button 1 click. > > Does codetools provide some way to do it? Donald Ziesig added templates to alter the inserted code snippets. Please update svn, compile the IDE with -dEnableCodeCompleteTemplates and restart it. Read the header notes in lazarus/components/codetools/codecompletiontemplater.pas Default templates are defined in components/codetools/codecompletiontemplates.xml You can choose your own template file in Tools / Options / Codetools / Code creation / Template file. Mattias From nc-gaertnma at netcologne.de Fri May 26 12:02:13 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Fri, 26 May 2017 12:02:13 +0200 Subject: [Lazarus] Show value hints while debugging fills screen - patch In-Reply-To: <6b2e4b90-a087-ef65-5374-91831048470a@gmail.com> References: <6b2e4b90-a087-ef65-5374-91831048470a@gmail.com> Message-ID: <20170526120213.10291ad2@limapholos.matflo.wg> On Tue, 23 May 2017 12:35:36 +0200 Russ via Lazarus wrote: > I find debugging value hints (TurboPowerIProDsgn installed, "Show value > hints while debugging") useful but annoying when the hint becomes so big > it covers the variable being checked or even fills the screen; on single > monitor systems the only way to close the hint is to scroll down to the > variable link. Especially annoying when the mouse-over was inadvertent. > > The following code illustrates the problem: > > program HugeHintProblem; > var > HugeHintVar: array[1..100, 1..100] of byte; > i, j: Integer; > begin > for i := 1 to 100 do > for j := 1 to 100 do > HugeHintVar[i,j] := random(255); > { Break on the next statement and mouse-over HugeHintVar - The hint > will fill the screen (this may take some time).} > HugeHintVar[1, 1] := 56; > end. > > > The following patch seems to fix the problem, limiting the hint span > from the left side of the variable and one line below to the bottom > right corner of the editor in undocked mode, and to the bottom right > corner of the IDE in docked mode. > > > Index: components/ideintf/idehelpintf.pas > =================================================================== > --- components/ideintf/idehelpintf.pas (revision 55056) > +++ components/ideintf/idehelpintf.pas (working copy) > @@ -383,6 +383,8 @@ > end; > > procedure DoHtml; > + var > + MaxWidth, MaxHeight: Integer; > begin > if HintFont<>nil then > HintRenderWindow.Font := HintFont; > @@ -397,10 +399,16 @@ > ms.Free; > end; > HtmlHelpProvider.ControlIntf.GetPreferredControlSize(NewWidth,NewHeight); > + MaxWidth := Screen.ActiveForm.Left + Screen.ActiveForm.Width - > ScreenPos.x; > + MaxHeight := Screen.ActiveForm.Top + Screen.ActiveForm.Height - > ScreenPos.y; > if NewWidth <= 0 then > - NewWidth := 500; > + NewWidth := 500 > + else if NewWidth > MaxWidth then > + NewWidth := MaxWidth; > if NewHeight <= 0 then > - NewHeight := 200; > + NewHeight := 200 > + else if NewHeight > MaxHeight then > + NewHeight := MaxHeight; > HintRenderWindow.HintRectAdjust := Rect(0, 0, NewWidth, NewHeight); > if MouseOffset then > HintRenderWindow.OffsetHintRect(ScreenPos) > > > I have tested this with windows XP, 7 and 8.1, Lazarus V1.64, V1.65 and > trunk, and with two monitors in various configurations Thanks, applied. > I tried to register an account on the bug tracker twice, but the link in > the confirmation email leads to an APPLICATION ERROR #1902 in Mantis, > complaining about an invalid confirmation URL Marc fixed one problem. Does it now work for you? Mattias From mailinglists at geldenhuys.co.uk Fri May 26 12:47:35 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 26 May 2017 11:47:35 +0100 Subject: [Lazarus] CodeTools knowledge about a project - find a class Message-ID: <39f9aa45-5339-6cec-8f2f-701e90dc9c9e@geldenhuys.co.uk> Hi, Does CodeTools only know about the unit or units that are currently open? Or does in know about all files in a project - and maybe even associated packages? The problem =========== I want to implement a Lazarus IDE feature "open type" - that's if it doesn't already exist (please let me know). Imagine, you need to have a look at the "TFoo" class. But, where is the "TFoo" class? Is it in the "Boo" project or maybe in the Boo_tools.lpk package? Or somewhere else (in a project search path)? I would like to be able to simply trigger the "Open Type" shortcut, which shows me a dialog where I can type "Foo", and a listbox below that will list all possible class matches with the name "Foo" (similar to what the Procedure List dialog currently does. I can then simply press Enter to select the first found option, or press the up/down arrows to select another match and then press Enter, and it will take me to the correct unit and class definition. Ctrl+LClick can already to this - somewhat. But for Ctrl+LClick to work, you need the correct unit in the uses clause. My problem is, what if you don't know the unit name either, or the unit name isn't in the uses list (yet - or might not even be needed at all, you simply wanted to double check something in the "TFoo" class). 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 nc-gaertnma at netcologne.de Fri May 26 13:01:51 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Fri, 26 May 2017 13:01:51 +0200 Subject: [Lazarus] CodeTools knowledge about a project - find a class In-Reply-To: <39f9aa45-5339-6cec-8f2f-701e90dc9c9e@geldenhuys.co.uk> References: <39f9aa45-5339-6cec-8f2f-701e90dc9c9e@geldenhuys.co.uk> Message-ID: <20170526130151.0efe17f0@limapholos.matflo.wg> On Fri, 26 May 2017 11:47:35 +0100 Graeme Geldenhuys via Lazarus wrote: > Hi, > > Does CodeTools only know about the unit or units that are currently > open? Or does in know about all files in a project - and maybe even > associated packages? Codetools only knows about the defines for each directory. But any IDE addon can access source editor and codetools. > The problem > =========== > I want to implement a Lazarus IDE feature "open type" - that's if it > doesn't already exist (please let me know). Imagine, you need to have a > look at the "TFoo" class. But, where is the "TFoo" class? Is it in the > "Boo" project or maybe in the Boo_tools.lpk package? Or somewhere else > (in a project search path)? > > I would like to be able to simply trigger the "Open Type" shortcut, > which shows me a dialog where I can type "Foo", and a listbox below that > will list all possible class matches with the name "Foo" (similar to > what the Procedure List dialog currently does. I can then simply press > Enter to select the first found option, or press the up/down arrows to > select another match and then press Enter, and it will take me to the > correct unit and class definition. Sounds like cody's dictionary: http://wiki.lazarus.freepascal.org/Cody#Unit_.2F_Identifier_Dictionary > Ctrl+LClick can already to this - somewhat. But for Ctrl+LClick to work, > you need the correct unit in the uses clause. My problem is, what if you > don't know the unit name either, or the unit name isn't in the uses list > (yet - or might not even be needed at all, you simply wanted to double > check something in the "TFoo" class). Mattias From bo.berglund at gmail.com Fri May 26 13:02:12 2017 From: bo.berglund at gmail.com (Bo Berglund) Date: Fri, 26 May 2017 13:02:12 +0200 Subject: [Lazarus] Lazarus 1.8 RC1 under Raspbian Jessie References: Message-ID: On Thu, 25 May 2017 18:46:43 +0200, Joe via Lazarus wrote: >I am trying to test Lazarus 1.8 RC1 (and following versions) under >Raspbian Jessie with PIXEL. >But unfortunately I could not find any instructions or scripts helping >to install *this* RC. >Any hint? You could try my script for installation of FPC + Lazarus on an RPi3. http://blog.boberglund.com/install_lazfpc_local_pi.sh In order to get the version you need just edit the script before running it and replace the versions at the top of the file with the one you want. It will install into the pi user space rather than make a global installation using sudo. I have not tested with the more recent Lazarus 1.8, but it worked fine with 1.6RCx and 1.6 release. -- Bo Berglund Developer in Sweden From lazarus at kluug.net Fri May 26 13:06:40 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Fri, 26 May 2017 13:06:40 +0200 Subject: [Lazarus] CodeTools knowledge about a project - find a class In-Reply-To: <39f9aa45-5339-6cec-8f2f-701e90dc9c9e@geldenhuys.co.uk> References: <39f9aa45-5339-6cec-8f2f-701e90dc9c9e@geldenhuys.co.uk> Message-ID: On 26.05.2017 12:47, Graeme Geldenhuys via Lazarus wrote: > I want to implement a Lazarus IDE feature "open type" - that's if it > doesn't already exist (please let me know). Imagine, you need to have > a look at the "TFoo" class. But, where is the "TFoo" class? Is it in > the "Boo" project or maybe in the Boo_tools.lpk package? Or somewhere > else (in a project search path)? > > I would like to be able to simply trigger the "Open Type" shortcut, > which shows me a dialog where I can type "Foo", and a listbox below > that will list all possible class matches with the name "Foo" (similar > to what the Procedure List dialog currently does. I can then simply > press Enter to select the first found option, or press the up/down > arrows to select another match and then press Enter, and it will take > me to the correct unit and class definition. Please share this feature with us when you implemented it! I miss it as well (I do a simple Search in Files now). Ondrej From mailinglists at geldenhuys.co.uk Fri May 26 13:10:17 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 26 May 2017 12:10:17 +0100 Subject: [Lazarus] CodeTools knowledge about a project - find a class In-Reply-To: <20170526130151.0efe17f0@limapholos.matflo.wg> References: <39f9aa45-5339-6cec-8f2f-701e90dc9c9e@geldenhuys.co.uk> <20170526130151.0efe17f0@limapholos.matflo.wg> Message-ID: On 2017-05-26 12:01, Mattias Gaertner via Lazarus wrote: > Sounds like cody's dictionary: > http://wiki.lazarus.freepascal.org/Cody#Unit_.2F_Identifier_Dictionary Fantastic! From the wiki description, this sounds exactly like what I was going to try and implement. Open Source developers are amazing. :) Thanks for pointing me to this. I'll give it a try immediately. 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 May 26 13:11:48 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 26 May 2017 12:11:48 +0100 Subject: [Lazarus] CodeTools knowledge about a project - find a class In-Reply-To: References: <39f9aa45-5339-6cec-8f2f-701e90dc9c9e@geldenhuys.co.uk> Message-ID: <4233cdf0-4435-a0e6-ba0f-5cb02ade1964@geldenhuys.co.uk> On 2017-05-26 12:06, Ondrej Pokorny via Lazarus wrote: > Please share this feature with us when you implemented it! I miss it as > well (I do a simple Search in Files now). It seems it already exists (as Mattias pointed out) - we just didn’t know about it. :) All that remains is to assign a shortcut to it, if a default one doesn't exist. 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 nc-gaertnma at netcologne.de Fri May 26 13:42:09 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Fri, 26 May 2017 13:42:09 +0200 Subject: [Lazarus] The "Publish Package" functionality is horribly broken. In-Reply-To: <228998ae-3a6f-ac0b-fec7-b206c1a0e7d7@geldenhuys.co.uk> References: <228998ae-3a6f-ac0b-fec7-b206c1a0e7d7@geldenhuys.co.uk> Message-ID: <20170526134209.4ef3ace0@limapholos.matflo.wg> On Fri, 26 May 2017 09:21:32 +0100 Graeme Geldenhuys via Lazarus wrote: > Hi, > > I noticed this menu option in the fpgui_toolkit.lpk package. So I > selected it and made sure the “include” filter selects all files, and > nothing is “excluded”. This clicked okay. After that I had a look in the > destination directory, and there was only 9 file. Yet the > fpgui_toolkit.lpk package actually has 117 files. See the screenshot > showing the result (blue window) vs the actual package files. > > So again, what is the function of “publish package”? It it is meant to > copy all units from a package to a destination directory (*), it fails > miserably at that. It copies the package directory with some options. The fpgui_toolkit directory only contains the 9 files. The other files are in parent or sibling directories. It now checks if some unit/inc path are outside and disables the "publish" menu item. > I'm using Lazarus 1.9.0 r54792 FPC 2.6.4 x86_64-freebsd-gtk2 > > > * - Seems that is supposed to be its function, based on the wiki help > page. But clearly it doesn't do a good job. > [http://wiki.lazarus.freepascal.org/IDE_Window:_Package_Editor#More] I added a note of this limitation. Mattias From mailinglists at geldenhuys.co.uk Fri May 26 14:09:34 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 26 May 2017 13:09:34 +0100 Subject: [Lazarus] The "Publish Package" functionality is horribly broken. In-Reply-To: <20170526134209.4ef3ace0@limapholos.matflo.wg> References: <228998ae-3a6f-ac0b-fec7-b206c1a0e7d7@geldenhuys.co.uk> <20170526134209.4ef3ace0@limapholos.matflo.wg> Message-ID: <36fb2785-82dc-8a03-8ca2-77547b002d96@geldenhuys.co.uk> Thanks for looking at this. On 2017-05-26 12:42, Mattias Gaertner via Lazarus wrote: > It copies the package directory with some options. > The fpgui_toolkit directory only contains the 9 files. The other files > are in parent or sibling directories. But those are still part of the package. At you saying that when using "lazarus packages" you must (or should) always limit yourself to only one directory? Than seems a bit limiting. I've also seen many projects where the project file and packages files are in the root directory of a project, and all source code are in sub directories. So all those are "wrong" too? > It now checks if some unit/inc path are outside and disables the > "publish" menu item. Fine with me, but it still seems like a useless feature then. Not actually being able to publish what is inside the package. If it is making releases that one is after, it seems a much better solution is still (if you use git): $ git archive --prefix=prj-1.4.0/ -o prj-1.4.0.tar.gz v1.4.0 or $ git archive --output /full/path/to/zipfile.zip master where "prj" is the name of the project. The last parameter is the commit, tag or branch you want to export. I believe SubVersion's equivalent would be 'svn export ...' command. 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 nc-gaertnma at netcologne.de Fri May 26 15:11:12 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Fri, 26 May 2017 15:11:12 +0200 Subject: [Lazarus] The "Publish Package" functionality is horribly broken. In-Reply-To: <36fb2785-82dc-8a03-8ca2-77547b002d96@geldenhuys.co.uk> References: <228998ae-3a6f-ac0b-fec7-b206c1a0e7d7@geldenhuys.co.uk> <20170526134209.4ef3ace0@limapholos.matflo.wg> <36fb2785-82dc-8a03-8ca2-77547b002d96@geldenhuys.co.uk> Message-ID: <20170526151112.499ff94d@limapholos.matflo.wg> On Fri, 26 May 2017 13:09:34 +0100 Graeme Geldenhuys via Lazarus wrote: >[...] > On 2017-05-26 12:42, Mattias Gaertner via Lazarus wrote: > > It copies the package directory with some options. > > The fpgui_toolkit directory only contains the 9 files. The other files > > are in parent or sibling directories. > > But those are still part of the package. At you saying that when using > "lazarus packages" you must (or should) always limit yourself to only > one directory? Than seems a bit limiting. No. Only the "publish package" function is limited. > I've also seen many projects where the project file and packages files > are in the root directory of a project, and all source code are in sub > directories. So all those are "wrong" too? > > > > It now checks if some unit/inc path are outside and disables the > > "publish" menu item. > > Fine with me, but it still seems like a useless feature then. It is useless for the fpgui package. That's why it is now disabled. > Not actually being able to publish what is inside the package. What do you mean with "inside"? It lists some units, but not all. Some directories are shared by other packages. I see no straightforward rule to publish only the package fpgui_toolkit. > If it is making releases that one is after, it seems a much better > solution is still (if you use git): > > $ git archive --prefix=prj-1.4.0/ -o prj-1.4.0.tar.gz v1.4.0 Huh? That is the whole fpgui, instead of just the fpgui_toolkit package. > or > > $ git archive --output /full/path/to/zipfile.zip master > > > where "prj" is the name of the project. The last parameter is the > commit, tag or branch you want to export. > > I believe SubVersion's equivalent would be 'svn export ...' command. Mattias From markMLl.lazarus at telemetry.co.uk Fri May 26 15:29:50 2017 From: markMLl.lazarus at telemetry.co.uk (Mark Morgan Lloyd) Date: Fri, 26 May 2017 13:29:50 +0000 Subject: [Lazarus] Lazarus 1.8 RC1 under Raspbian Jessie In-Reply-To: References: Message-ID: On 26/05/17 11:20, Bo Berglund via Lazarus wrote: > On Thu, 25 May 2017 18:46:43 +0200, Joe via Lazarus wrote: >> I am trying to test Lazarus 1.8 RC1 (and following versions) under >Raspbian Jessie with PIXEL.>But unfortunately I could not find any instructions or scripts helping >to install *this* RC.>Any hint? > You could try my script for installation of FPC + Lazarus on an RPi3.http://blog.boberglund.com/install_lazfpc_local_pi.sh > In order to get the version you need just edit the script beforerunning it and replace the versions at the top of the file with theone you want.It will install into the pi user space rather than make a globalinstallation using sudo. > I have not tested with the more recent Lazarus 1.8, but it worked finewith 1.6RCx and 1.6 release. Just to check the "standard way of doing it" in case there's any surprises, with FPC 3.0.2 installed: svn co http://svn.freepascal.org/svn/lazarus/tags/lazarus_1_8_0_RC1 cd lazarus_1_8_0_RC1 make That worked as expected. make clean bigide That also worked, except that there was a message about EditorMacroScript at startup. A purist woult probably object that the binary hadn't been added to the desktop environment's menu. That's an up-to-date "full" Raspbian (i.e. not "lite"). -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] From mailinglists at geldenhuys.co.uk Fri May 26 15:42:06 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 26 May 2017 14:42:06 +0100 Subject: [Lazarus] The "Publish Package" functionality is horribly broken. In-Reply-To: <20170526151112.499ff94d@limapholos.matflo.wg> References: <228998ae-3a6f-ac0b-fec7-b206c1a0e7d7@geldenhuys.co.uk> <20170526134209.4ef3ace0@limapholos.matflo.wg> <36fb2785-82dc-8a03-8ca2-77547b002d96@geldenhuys.co.uk> <20170526151112.499ff94d@limapholos.matflo.wg> Message-ID: On 2017-05-26 14:11, Mattias Gaertner via Lazarus wrote: >> Not actually being able to publish what is inside the package. > What do you mean with "inside"? > It lists some units, but not all. Some directories are shared by other > packages. > I see no straightforward rule to publish only the package fpgui_toolkit. > By "inside" I mean the files that are included in the original *.lpk package (what the Packages dialog shows). See the 114 files shown in the screenshot in the first message of this thread. That is the fpgui_toolkit.lpk Package Dialog - not simply a directory listing. 1) Also note that the published package unit "fpgui_toolkit.pas" (which states "Do not edit!") lists all the units of the fpgui_toolkit.lpk package, but they didn't exist in the published directory. 2) The published fpgui_toolkit.lpk also contains SearchPath entries. They were not modified from the original. Neither were the items in the Files tag. So yeah, good you disabled that published option then, because the results were totally broken. ;-) What could possibly work (but is more effort to implement) is to publish a package to a single directory (even if the original had multiple paths), but then the SearchPath and Files sections in the published .lpk file needs to be modified. So if somebody else opens that published package, all units are still found and is actually compilable. Just my 2c worth. But to be honest, I can't actually see a use for the "published package" functionality in the real world, so this could be chalked up as "no further action needed". 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 badsectoracula at gmail.com Fri May 26 16:49:35 2017 From: badsectoracula at gmail.com (Kostas Michalopoulos) Date: Fri, 26 May 2017 17:49:35 +0300 Subject: [Lazarus] CodeTools knowledge about a project - find a class In-Reply-To: <4233cdf0-4435-a0e6-ba0f-5cb02ade1964@geldenhuys.co.uk> References: <39f9aa45-5339-6cec-8f2f-701e90dc9c9e@geldenhuys.co.uk> <4233cdf0-4435-a0e6-ba0f-5cb02ade1964@geldenhuys.co.uk> Message-ID: This looks like a nice feature, but it only seems to know stuff you have already open or opened in the current session. It doesn't know all identifiers and whatever might be available from the currently loaded project and packages. For example if you have a unit Foo (either in the project or in one of the packages) but you don't have it opened at any time in the current session, it wont be able to show you anything that Foo exports. If you open Foo then it will, even if you close it after, but if you restart Lazarus it will have forgotten everything. Also i'd prefer if the Jump to button was default. It is trivial to change this via code (i just set the button's Default property to true) but i'd be nice if it was configurable in options. Finally while it does seem to remember unit names, this is as a byproduct of units being symbols and when you jump to a unit it puts the cursor to the top of the file. It'd be nice if it had a special case for units that only switched/opened the unit file without moving the cursor so you can quickly jump between files with the same shortcut. TBH i think such a "quick jump" would be a good thing to have in the base IDE out of the box. Popular modern IDEs provide this functionality these days and it is even included in some editors like Sublime. I think the necessary low level functionality is almost there and it is mainly a matter of tying everything together. On Fri, May 26, 2017 at 2:11 PM, Graeme Geldenhuys via Lazarus < lazarus at lists.lazarus-ide.org> wrote: > On 2017-05-26 12:06, Ondrej Pokorny via Lazarus wrote: > >> Please share this feature with us when you implemented it! I miss it as >> well (I do a simple Search in Files now). >> > > It seems it already exists (as Mattias pointed out) - we just didn’t know > about it. :) All that remains is to assign a shortcut to it, if a default > one doesn't exist. > > 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 > -- > _______________________________________________ > 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 bo.berglund at gmail.com Fri May 26 17:01:40 2017 From: bo.berglund at gmail.com (Bo Berglund) Date: Fri, 26 May 2017 17:01:40 +0200 Subject: [Lazarus] Lazarus 1.8 RC1 under Raspbian Jessie References: Message-ID: On Fri, 26 May 2017 13:29:50 +0000, Mark Morgan Lloyd via Lazarus wrote: > >Just to check the "standard way of doing it" in case there's any >surprises, with FPC 3.0.2 installed: > >svn co http://svn.freepascal.org/svn/lazarus/tags/lazarus_1_8_0_RC1 >cd lazarus_1_8_0_RC1 >make > >That worked as expected. > >make clean bigide > >That also worked, except that there was a message about >EditorMacroScript at startup. A purist woult probably object that the >binary hadn't been added to the desktop environment's menu. > >That's an up-to-date "full" Raspbian (i.e. not "lite"). I made the script in order to install "everything" on a bare bones RPi with Raspbian from the install image. So it therefore also installs FPC, then Lazarus. And it uses a start compiler I made myself since I could not find any 3.0.0 FPC for ARMHF on RPi at the time. It is downloaded as part of running the script. -- Bo Berglund Developer in Sweden From nc-gaertnma at netcologne.de Fri May 26 17:16:32 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Fri, 26 May 2017 17:16:32 +0200 Subject: [Lazarus] CodeTools knowledge about a project - find a class In-Reply-To: References: <39f9aa45-5339-6cec-8f2f-701e90dc9c9e@geldenhuys.co.uk> <4233cdf0-4435-a0e6-ba0f-5cb02ade1964@geldenhuys.co.uk> Message-ID: <20170526171632.0ffb298d@limapholos.matflo.wg> On Fri, 26 May 2017 17:49:35 +0300 Kostas Michalopoulos via Lazarus wrote: > This looks like a nice feature, but it only seems to know stuff you have > already open or opened in the current session. It doesn't know all > identifiers and whatever might be available from the currently loaded > project and packages. For example if you have a unit Foo (either in the > project or in one of the packages) but you don't have it opened at any time > in the current session, it wont be able to show you anything that Foo > exports. If you open Foo then it will, even if you close it after, but if > you restart Lazarus it will have forgotten everything. No. It stores all learned identifiers in a file: http://wiki.lazarus.freepascal.org/Cody#Unit_.2F_Identifier_Dictionary For example on this machine the dictionary knows over a million identifiers. It needs some clean up dialog. ;) > Also i'd prefer if the Jump to button was default. It is trivial to change > this via code (i just set the button's Default property to true) but i'd be > nice if it was configurable in options. Feel free to submit a patch. > Finally while it does seem to remember unit names, this is as a byproduct > of units being symbols and when you jump to a unit it puts the cursor to > the top of the file. It'd be nice if it had a special case for units that > only switched/opened the unit file without moving the cursor so you can > quickly jump between files with the same shortcut. Feel free to add an option for that too. > TBH i think such a "quick jump" would be a good thing to have in the base > IDE out of the box. Popular modern IDEs provide this functionality these > days and it is even included in some editors like Sublime. I think the > necessary low level functionality is almost there and it is mainly a matter > of tying everything together. It needs some work to make it "newbie" safe. Mattias > > > On Fri, May 26, 2017 at 2:11 PM, Graeme Geldenhuys via Lazarus < > lazarus at lists.lazarus-ide.org> wrote: > > > On 2017-05-26 12:06, Ondrej Pokorny via Lazarus wrote: > > > >> Please share this feature with us when you implemented it! I miss it as > >> well (I do a simple Search in Files now). > >> > > > > It seems it already exists (as Mattias pointed out) - we just didn’t know > > about it. :) All that remains is to assign a shortcut to it, if a default > > one doesn't exist. > > > > 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 > > -- > > _______________________________________________ > > Lazarus mailing list > > Lazarus at lists.lazarus-ide.org > > http://lists.lazarus-ide.org/listinfo/lazarus > > From badsectoracula at gmail.com Fri May 26 17:24:12 2017 From: badsectoracula at gmail.com (Kostas Michalopoulos) Date: Fri, 26 May 2017 18:24:12 +0300 Subject: [Lazarus] CodeTools knowledge about a project - find a class In-Reply-To: <20170526171632.0ffb298d@limapholos.matflo.wg> References: <39f9aa45-5339-6cec-8f2f-701e90dc9c9e@geldenhuys.co.uk> <4233cdf0-4435-a0e6-ba0f-5cb02ade1964@geldenhuys.co.uk> <20170526171632.0ffb298d@limapholos.matflo.wg> Message-ID: > No. It stores all learned identifiers in a file: > But then why does it behave as i mentioned? When i restart Lazarus it has forgotten everything. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nc-gaertnma at netcologne.de Fri May 26 17:38:05 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Fri, 26 May 2017 17:38:05 +0200 Subject: [Lazarus] CodeTools knowledge about a project - find a class In-Reply-To: References: <39f9aa45-5339-6cec-8f2f-701e90dc9c9e@geldenhuys.co.uk> <4233cdf0-4435-a0e6-ba0f-5cb02ade1964@geldenhuys.co.uk> <20170526171632.0ffb298d@limapholos.matflo.wg> Message-ID: <20170526173805.4d89c0db@limapholos.matflo.wg> On Fri, 26 May 2017 18:24:12 +0300 Kostas Michalopoulos via Lazarus wrote: > > No. It stores all learned identifiers in a file: > > > > But then why does it behave as i mentioned? When i restart Lazarus it has > forgotten everything. What platform? What happens when you click on Tools / Options / Codetools / IDE Integration / Save dictionary now? Move the mouse over the button and wait for the hint to find out where it stores the file. Mattias From markMLl.lazarus at telemetry.co.uk Fri May 26 17:52:06 2017 From: markMLl.lazarus at telemetry.co.uk (Mark Morgan Lloyd) Date: Fri, 26 May 2017 15:52:06 +0000 Subject: [Lazarus] Lazarus 1.8 RC1 under Raspbian Jessie In-Reply-To: References: Message-ID: On 26/05/17 15:02, Bo Berglund via Lazarus wrote: > On Fri, 26 May 2017 13:29:50 +0000, Mark Morgan Lloyd via Lazarus wrote: >>> Just to check the "standard way of doing it" in case there's any >surprises, with FPC 3.0.2 installed:>>svn co http://svn.freepascal.org/svn/lazarus/tags/lazarus_1_8_0_RC1>cd lazarus_1_8_0_RC1>make>>That worked as expected.>>make clean bigide>>That also worked, except that there was a message about >EditorMacroScript at startup. A purist woult probably object that the >binary hadn't been added to the desktop environment's menu.>>That's an up-to-date "full" Raspbian (i.e. not "lite"). > I made the script in order to install "everything" on a bare bones RPiwith Raspbian from the install image. So it therefore also installsFPC, then Lazarus. And it uses a start compiler I made myself since Icould not find any 3.0.0 FPC for ARMHF on RPi at the time.It is downloaded as part of running the script. My apologies, but since you hadn't tested it for the current RC I assumed you'd abandoned it. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] From badsectoracula at gmail.com Fri May 26 18:29:00 2017 From: badsectoracula at gmail.com (Kostas Michalopoulos) Date: Fri, 26 May 2017 19:29:00 +0300 Subject: [Lazarus] CodeTools knowledge about a project - find a class In-Reply-To: <20170526173805.4d89c0db@limapholos.matflo.wg> References: <39f9aa45-5339-6cec-8f2f-701e90dc9c9e@geldenhuys.co.uk> <4233cdf0-4435-a0e6-ba0f-5cb02ade1964@geldenhuys.co.uk> <20170526171632.0ffb298d@limapholos.matflo.wg> <20170526173805.4d89c0db@limapholos.matflo.wg> Message-ID: Actually it works fine, after peppering the code with writelns to see the flow, i figured out what was the issue: there is a 10 minute interval (by default) between saves and the dictionary is only saved at the interval. I expected it to be saved when exiting the IDE regardless of when the last save was. I added a Save; call right at the beginning of the OnIDEClose callback, like this procedure TCodyUnitDictionary.OnIDEClose(Sender: TObject); begin Save; // Save the dictionary before closing the IDE fClosing:=true; FreeAndNil(fTimer); end; And it seems to behave as i expect it now. This way it wont lose any data when i restart the IDE (which i do often when working with custom controls). TBH i'm not sure the approach of only scanning what you have loaded is enough since it still wont show anything from a unit i haven't already loaded before. For example if i show the dialog looking for TGraphic it will only show up after i have already used it at least once. So if i have an empty database i get this: 1. Open the identifier db dialog (i have set it up as Alt+`) 2. Start typing TGraph 3. Nothing shows up 4. Press Ctrl+Space in a form code (e.g. Unit1 in the default empty project) 5. Start typing TGraph so that it shows in the completion dialog 6. Press esc to cancel the completion dialog 7. Open the identifier db dialog again 8. Start typing TGraph 9. Now TGraphic (and other stuff) show up I think there needs to be a way for the dialog to also know whatever is or can be known with the currently loaded packages and units, not just whatever you have encountered so far. That information seems to already be available in the IDE in other places. On Fri, May 26, 2017 at 6:38 PM, Mattias Gaertner via Lazarus < lazarus at lists.lazarus-ide.org> wrote: > On Fri, 26 May 2017 18:24:12 +0300 > Kostas Michalopoulos via Lazarus wrote: > > > > No. It stores all learned identifiers in a file: > > > > > > > But then why does it behave as i mentioned? When i restart Lazarus it has > > forgotten everything. > > What platform? > > What happens when you click on Tools / Options / Codetools / IDE > Integration / Save dictionary now? > > Move the mouse over the button and wait for the hint to find out where > it stores the file. > > 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 nc-gaertnma at netcologne.de Fri May 26 22:03:28 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Fri, 26 May 2017 22:03:28 +0200 Subject: [Lazarus] CodeTools knowledge about a project - find a class In-Reply-To: References: <39f9aa45-5339-6cec-8f2f-701e90dc9c9e@geldenhuys.co.uk> <4233cdf0-4435-a0e6-ba0f-5cb02ade1964@geldenhuys.co.uk> <20170526171632.0ffb298d@limapholos.matflo.wg> <20170526173805.4d89c0db@limapholos.matflo.wg> Message-ID: <20170526220328.24803a2d@limapholos.matflo.wg> On Fri, 26 May 2017 19:29:00 +0300 Kostas Michalopoulos via Lazarus wrote: > Actually it works fine, after peppering the code with writelns to see the > flow, i figured out what was the issue: there is a 10 minute interval (by > default) between saves and the dictionary is only saved at the interval. I > expected it to be saved when exiting the IDE regardless of when the last > save was. Saving takes some time when the file is big. I prefer a fast closing IDE. Maybe some option can be added. > I added a Save; call right at the beginning of the OnIDEClose callback, > like this > > procedure TCodyUnitDictionary.OnIDEClose(Sender: TObject); > begin > Save; // Save the dictionary before closing the IDE > fClosing:=true; > FreeAndNil(fTimer); > end; > > And it seems to behave as i expect it now. This way it wont lose any data > when i restart the IDE (which i do often when working with custom controls). Why that? Simply start a second instance for testing. > TBH i'm not sure the approach of only scanning what you have loaded is > enough since it still wont show anything from a unit i haven't already > loaded before. Yes, the empty database on first use is currently the show stopper. It would be great, if it somehow (TM) knows at least the FPC and Lazarus sources after install. >[...] > I think there needs to be a way for the dialog to also know whatever is or > can be known with the currently loaded packages and units, not just > whatever you have encountered so far. That information seems to already be > available in the IDE in other places. The IDE parses the sources on demand when information is needed. It is not available per se. Since parsing a project can take some seconds even on fast machines, this is not done automatically. Maybe the dictionary can start parsing the project on idle when it is shown to update its database. Mattias From bo.berglund at gmail.com Fri May 26 23:09:23 2017 From: bo.berglund at gmail.com (Bo Berglund) Date: Fri, 26 May 2017 23:09:23 +0200 Subject: [Lazarus] Lazarus 1.8 RC1 under Raspbian Jessie References: Message-ID: <046hic1vs65694o2l3mijug9l1ml6mv1pm@4ax.com> On Fri, 26 May 2017 15:52:06 +0000, Mark Morgan Lloyd via Lazarus wrote: >My apologies, but since you hadn't tested it for the current RC I >assumed you'd abandoned it. No apology needed! It's just that I have 6 RPi:s running at home for different purposes and those I use for FPC programming are working well as it is, so I have not even looked for new releases of Lazarus recently. The script was done for this: 1) To simplify the initial installation on a brand new RPi 2) To make sure the install is done to the pi environment rather than global with sudo. -- Bo Berglund Developer in Sweden From bo.berglund at gmail.com Fri May 26 23:14:34 2017 From: bo.berglund at gmail.com (Bo Berglund) Date: Fri, 26 May 2017 23:14:34 +0200 Subject: [Lazarus] A simple way to stop the never ending story of long executable? References: Message-ID: On Sat, 20 May 2017 12:24:01 +0200, Giuliano Colla via Lazarus wrote: >...would stop the complaints about "long executable". How about strip -s as a post-compile step before shipping? -- Bo Berglund Developer in Sweden From noreply at z505.com Sat May 27 02:52:44 2017 From: noreply at z505.com (noreply at z505.com) Date: Fri, 26 May 2017 19:52:44 -0500 Subject: [Lazarus] CodeTools On Event insert? detect In-Reply-To: <20170526114412.2d4ec1f6@limapholos.matflo.wg> References: <20170526114412.2d4ec1f6@limapholos.matflo.wg> Message-ID: <7e124b226c711c63707e59cb8197a714@z505.com> On 2017-05-26 04:44, Mattias Gaertner via Lazarus wrote: > On Wed, 24 May 2017 13:43:10 -0500 > Lars via Lazarus wrote: > >> [...] >> I want to intercept/detect this, and add >> >> SomeCode(); >> >> between the begin/end of the event, i.e. on button 1 click. >> >> Does codetools provide some way to do it? > > Donald Ziesig added templates to alter the inserted code snippets. > Please update svn, compile the IDE with > -dEnableCodeCompleteTemplates and restart it. > > Read the header notes in > lazarus/components/codetools/codecompletiontemplater.pas > > Default templates are defined in > components/codetools/codecompletiontemplates.xml > > You can choose your own template file in Tools / Options / > Codetools / Code creation / Template file. > Thanks, I will try. Is it a special Define because it is a new untested feature waiting for approval? If so I could be a tester From noreply at z505.com Sat May 27 03:13:51 2017 From: noreply at z505.com (noreply at z505.com) Date: Fri, 26 May 2017 20:13:51 -0500 Subject: [Lazarus] CodeTools On Event insert? detect In-Reply-To: <20170526114412.2d4ec1f6@limapholos.matflo.wg> References: <20170526114412.2d4ec1f6@limapholos.matflo.wg> Message-ID: >> [...] >> I want to intercept [...] and add >> >> SomeCode(); >> >> between the begin/end of the event, i.e. on button 1 click. >> >> Does codetools provide some way to do it? Found this discussions about it too: http://lists.lazarus.freepascal.org/pipermail/lazarus/2014-March/086457.html http://free-pascal-lazarus.989080.n3.nabble.com/Lazarus-RFC-Code-tools-Feature-td4036425.html That's interesting that Michael V. C. wanted logging at begin/end of code snippets in procedures, because that's exactly what powtils had to do but it looks kind of ugly at the source level to have IFDEF DEBUG at the end and begin of each procedure, but that's how I did it.. But, this requirement that I need has nothing to do with that, it's for something else.. but still interesting! From nc-gaertnma at netcologne.de Sat May 27 09:36:11 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Sat, 27 May 2017 09:36:11 +0200 Subject: [Lazarus] CodeTools On Event insert? detect In-Reply-To: <7e124b226c711c63707e59cb8197a714@z505.com> References: <20170526114412.2d4ec1f6@limapholos.matflo.wg> <7e124b226c711c63707e59cb8197a714@z505.com> Message-ID: <20170527093611.33ea9195@limapholos.matflo.wg> On Fri, 26 May 2017 19:52:44 -0500 Lars via Lazarus wrote: >[...] > > Please update svn, compile the IDE with > > -dEnableCodeCompleteTemplates and restart it. >[...] > Thanks, I will try. Is it a special Define because it is a new untested > feature waiting for approval? Yes, and it is waiting for a discussion about the template file. Attributes, format, flexibility. > If so I could be a tester Yes, please. Mattias From markMLl.lazarus at telemetry.co.uk Sat May 27 10:44:56 2017 From: markMLl.lazarus at telemetry.co.uk (Mark Morgan Lloyd) Date: Sat, 27 May 2017 08:44:56 +0000 Subject: [Lazarus] Lazarus 1.8 RC1 under Raspbian Jessie In-Reply-To: <046hic1vs65694o2l3mijug9l1ml6mv1pm@4ax.com> References: <046hic1vs65694o2l3mijug9l1ml6mv1pm@4ax.com> Message-ID: On 26/05/17 21:20, Bo Berglund via Lazarus wrote: > On Fri, 26 May 2017 15:52:06 +0000, Mark Morgan Lloyd via Lazarus wrote: >> My apologies, but since you hadn't tested it for the current RC I >assumed you'd abandoned it. > No apology needed! > It's just that I have 6 RPi:s running at home for different purposesand those I use for FPC programming are working well as it is, so Ihave not even looked for new releases of Lazarus recently. > The script was done for this:1) To simplify the initial installation on a brand new RPi2) To make sure the install is done to the pi environment rather thanglobal with sudo. Noted. But I'd got one next to me earmarked for development onto which I could easily checkout the RC (using the original published URL) and where I could check the build using the basic commands that the developers expected and which are probably buried somewhere in the Wiki :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] From friess at gmx.at Sat May 27 11:19:30 2017 From: friess at gmx.at (=?UTF-8?Q?Andreas_Frie=c3=9f?=) Date: Sat, 27 May 2017 11:19:30 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <2b6fb59c-42e0-79f0-4c01-faeff6cd3c59@freenet.de> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <71bc1b7f-adcc-8abb-5cf9-27745bcedb04@gmx.at> <2b6fb59c-42e0-79f0-4c01-faeff6cd3c59@freenet.de> Message-ID: <2bab6184-470d-412d-049d-23e68b701029@gmx.at> Am 19.05.2017 um 01:30 schrieb Werner Pamler via Lazarus: > Am 18.05.2017 um 00:41 schrieb Werner Pamler via Lazarus: >> Am 17.05.2017 um 23:08 schrieb Andreas Frieß via Lazarus: >>> I see with the last patches something goes wrong after r54880 with >>> frames and grid (specially TsWorkSheetGrid). >>> >>> Lazarus claims, the is no valid parent and didnot load and crash. It >>> is only happen if you use frames ? The trouble is, i can only >>> shutdown Lazarus with the Processmanger. >>> >>> Win10/64 with Lazarus 32/svn 1.9RC1 >> >> This is confusing: Are you using Laz trunk (v1.9) or 1.8RC1? I don't >> see an issue with WorksheetGrid on frames with Laz trunk. Can you >> post a demo? > > Andreas, could you try r5868 of fpspreadsheet? I fixed a "Window has > no parent" error with frames which had crept in, again... > Werner thank you, i will make a try and i will look for the changes, because i found other (older) components they have some trouble with frames (DirectShow) too. Next week i can spend some time to check this with a fresh installation to avoid side effects. Andreas From Special at Joepgen.com Sat May 27 11:20:17 2017 From: Special at Joepgen.com (Joe) Date: Sat, 27 May 2017 11:20:17 +0200 Subject: [Lazarus] Lazarus 1.8 RC1 under Raspbian Jessie In-Reply-To: References: Message-ID: <7ac6e745-c06c-9e33-a5eb-1b7b0adb8a12@Joepgen.com> Am 26.05.2017 um 13:02 schrieb Bo Berglund via Lazarus: > You could try my script for installation of FPC + Lazarus on an RPi3. > http://blog.boberglund.com/install_lazfpc_local_pi.sh > > In order to get the version you need just edit the script before > running it and replace the versions at the top of the file with the > one you want. Bo, unfortunately, this failed with error message something could not be found. Seems, I did not edit the script the right way. What lines are to be edited and exactly how for Lazarus 1.8.0 RC1? Thanx -- Joe From Special at Joepgen.com Sat May 27 11:25:56 2017 From: Special at Joepgen.com (Joe) Date: Sat, 27 May 2017 11:25:56 +0200 Subject: [Lazarus] Lazarus 1.8 RC1 under Raspbian Jessie In-Reply-To: References: Message-ID: <506e7e1b-d75b-37c3-69aa-169683a22702@Joepgen.com> Am 26.05.2017 um 15:29 schrieb Mark Morgan Lloyd via Lazarus: > Just to check the "standard way of doing it" in case there's any > surprises, with FPC 3.0.2 installed: > > svn co http://svn.freepascal.org/svn/lazarus/tags/lazarus_1_8_0_RC1 > cd lazarus_1_8_0_RC1 > make > > That worked as expected. > > make clean bigide Mark, I installed FPC 3.0.2 and then followed your proposal. But the compilation of Lazarus 1.8.0 RC1 was aborted with an error message saying FPC 3.0.0 was needed. How to fix? Regards -- Joe From nc-gaertnma at netcologne.de Sat May 27 11:38:09 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Sat, 27 May 2017 11:38:09 +0200 Subject: [Lazarus] Lazarus 1.8 RC1 under Raspbian Jessie In-Reply-To: <506e7e1b-d75b-37c3-69aa-169683a22702@Joepgen.com> References: <506e7e1b-d75b-37c3-69aa-169683a22702@Joepgen.com> Message-ID: <20170527113809.76ecfd16@limapholos.matflo.wg> On Sat, 27 May 2017 11:25:56 +0200 Joe via Lazarus wrote: > Am 26.05.2017 um 15:29 schrieb Mark Morgan Lloyd via Lazarus: > > Just to check the "standard way of doing it" in case there's any > > surprises, with FPC 3.0.2 installed: > > > > svn co http://svn.freepascal.org/svn/lazarus/tags/lazarus_1_8_0_RC1 > > cd lazarus_1_8_0_RC1 > > make > > > > That worked as expected. > > > > make clean bigide > > Mark, > I installed FPC 3.0.2 and then followed your proposal. But the > compilation of Lazarus 1.8.0 RC1 was aborted with an error message > saying FPC 3.0.0 was needed. What is the exact error message? Mattias From markMLl.lazarus at telemetry.co.uk Sat May 27 12:21:28 2017 From: markMLl.lazarus at telemetry.co.uk (Mark Morgan Lloyd) Date: Sat, 27 May 2017 10:21:28 +0000 Subject: [Lazarus] Lazarus 1.8 RC1 under Raspbian Jessie In-Reply-To: <506e7e1b-d75b-37c3-69aa-169683a22702@Joepgen.com> References: <506e7e1b-d75b-37c3-69aa-169683a22702@Joepgen.com> Message-ID: On 27/05/17 09:40, Joe via Lazarus wrote: > Am 26.05.2017 um 15:29 schrieb Mark Morgan Lloyd via Lazarus:> Just to > check the "standard way of doing it" in case there's any > surprises, > with FPC 3.0.2 installed:>> svn co > http://svn.freepascal.org/svn/lazarus/tags/lazarus_1_8_0_RC1> cd > lazarus_1_8_0_RC1> make>> That worked as expected.>> make clean bigide > Mark,I installed FPC 3.0.2 and then followed your proposal. But the > compilation of Lazarus 1.8.0 RC1 was aborted with an error message > saying FPC 3.0.0 was needed.How to fix? Make sure that the ppcarm command points to the 3.0.2 binary. Here's what I've got in my /usr/local/bin: lrwxrwxrwx 1 root staff 12 Mar 25 14:14 ppcarm -> ppcarm-3.0.2 lrwxrwxrwx 1 root staff 31 Mar 25 14:13 ppcarm-3.0.2 -> /usr/local/lib/fpc/3.0.2/ppcarm The fpc -v command should give you version info: $ fpc -v Free Pascal Compiler version 3.0.2 [2017/03/02] for arm Copyright (c) 1993-2017 by Florian Klaempfl and others Fatal: No source file name in command line Fatal: Compilation aborted Error: /usr/local/bin/ppcarm returned an error exitcode -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] From luca at wetron.es Sat May 27 15:16:50 2017 From: luca at wetron.es (Luca Olivetti) Date: Sat, 27 May 2017 15:16:50 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <2b6fb59c-42e0-79f0-4c01-faeff6cd3c59@freenet.de> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <71bc1b7f-adcc-8abb-5cf9-27745bcedb04@gmx.at> <2b6fb59c-42e0-79f0-4c01-faeff6cd3c59@freenet.de> Message-ID: El 19/05/17 a les 01:30, Werner Pamler via Lazarus ha escrit: > Andreas, could you try r5868 of fpspreadsheet? I fixed a "Window has no > parent" error with frames which had crept in, again... I just discovered that with this revision OnSelectCell doesn't fire anymore. Not a biggie, I'm using OnClick instead, but it caught me by surprise. Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From werner.pamler at freenet.de Sat May 27 18:44:35 2017 From: werner.pamler at freenet.de (Werner Pamler) Date: Sat, 27 May 2017 18:44:35 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: References: <20170517143928.1d2588e4@limapholos.matflo.wg> <71bc1b7f-adcc-8abb-5cf9-27745bcedb04@gmx.at> <2b6fb59c-42e0-79f0-4c01-faeff6cd3c59@freenet.de> Message-ID: Am 27.05.2017 um 15:16 schrieb Luca Olivetti via Lazarus: > El 19/05/17 a les 01:30, Werner Pamler via Lazarus ha escrit: > >> Andreas, could you try r5868 of fpspreadsheet? I fixed a "Window has >> no parent" error with frames which had crept in, again... > > I just discovered that with this revision OnSelectCell doesn't fire > anymore. Not a biggie, I'm using OnClick instead, but it caught me by > surprise. Thanks for reporting. Should be fixed in r5905. From russeld.lists at gmail.com Sun May 28 16:52:49 2017 From: russeld.lists at gmail.com (Russ) Date: Sun, 28 May 2017 16:52:49 +0200 Subject: [Lazarus] Show value hints while debugging fills screen - patch (Lazarus Digest, Vol 112, Issue 78) In-Reply-To: <20170526120213.10291ad2@limapholos.matflo.wg> References: <20170526120213.10291ad2@limapholos.matflo.wg> Message-ID: <416c620d-b93d-0e98-29e7-86d9deeda1bc@gmail.com> On 2017/05/26 12:02, Mattias Gaertner wrote: > >> I tried to register an account on the bug tracker twice, but the link in >> the confirmation email leads to an APPLICATION ERROR #1902 in Mantis, >> complaining about an invalid confirmation URL > Marc fixed one problem. Does it now work for you? > > Mattias No, unfortunately not, same error. --- This email has been checked for viruses by AVG. http://www.avg.com From werner.pamler at freenet.de Sun May 28 17:57:04 2017 From: werner.pamler at freenet.de (Werner Pamler) Date: Sun, 28 May 2017 17:57:04 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <20170517143928.1d2588e4@limapholos.matflo.wg> References: <20170517143928.1d2588e4@limapholos.matflo.wg> Message-ID: Forum user "handoko" reports some issues with RC1 in http://forum.lazarus.freepascal.org/index.php/topic,37022.msg247603.html#msg247603 (and http://forum.lazarus.freepascal.org/index.php/topic,36907.msg247608.html#msg247608), among them the "double-keyboard" error under Ubuntu again. Maybe someone more knowledgeable than me can have a look at this. From bo.berglund at gmail.com Sun May 28 22:40:30 2017 From: bo.berglund at gmail.com (Bo Berglund) Date: Sun, 28 May 2017 22:40:30 +0200 Subject: [Lazarus] Lazarus 1.8 RC1 under Raspbian Jessie References: <7ac6e745-c06c-9e33-a5eb-1b7b0adb8a12@Joepgen.com> Message-ID: On Sat, 27 May 2017 11:20:17 +0200, Joe via Lazarus wrote: >Am 26.05.2017 um 13:02 schrieb Bo Berglund via Lazarus: >> You could try my script for installation of FPC + Lazarus on an RPi3. >> http://blog.boberglund.com/install_lazfpc_local_pi.sh >> >> In order to get the version you need just edit the script before >> running it and replace the versions at the top of the file with the >> one you want. >Bo, >unfortunately, this failed with error message something could not be >found. Seems, I did not edit the script the right way. >What lines are to be edited and exactly how for Lazarus 1.8.0 RC1? I have not used the scripts in a while, the last time was when I installed on a Raspbian Pixel RPi in January-February, and at that time the script worked for me. One note though: The script is for installing on a bare bones RPi Raspbian and it deals with both the FPC seed and release versions and then Lazarus. So if you are only interested in Lazarus 1.8RCx but have no need to get a new FPC then this is probably not for you. I might set up a new Pi soon for use at my vacation home over the summer and when I do I will check the script again... -- Bo Berglund Developer in Sweden From larrydalton71 at gmail.com Sun May 28 23:11:16 2017 From: larrydalton71 at gmail.com (Larry Dalton) Date: Sun, 28 May 2017 16:11:16 -0500 Subject: [Lazarus] Key scan codes Message-ID: <6AEBEA16-C444-487C-AC2C-C5BE6B56A8E3@gmail.com> I need a function or procedure that will return the scan code for a keypress on both Linux systems and Windows, ie when the 'L' key is pressed it would return '$4C'. Sent from my iPhone From giuliano.colla at fastwebnet.it Mon May 29 11:38:48 2017 From: giuliano.colla at fastwebnet.it (Giuliano Colla) Date: Mon, 29 May 2017 11:38:48 +0200 Subject: [Lazarus] A simple way to stop the never ending story of long executable? In-Reply-To: References: Message-ID: <707573a8-392d-f62c-4de0-ae8c865cb1d7@fastwebnet.it> Il 26/05/2017 23:14, Bo Berglund via Lazarus ha scritto: > On Sat, 20 May 2017 12:24:01 +0200, Giuliano Colla via Lazarus > wrote: > >> ...would stop the complaints about "long executable". > How about strip -s as a post-compile step before shipping? > > That way you erase the debug symbols. If later a user complains about a bug, or about a supposed bug, you're forced to recompile everything, and if something has changed in between, you can't tell what's the cause of the trouble. If you keep the debug symbols in a separate file, you have the best of both worlds. You may choose whether to ship debug symbols or not, you may debug again exactly the same binary you shipped, you may ship later the debug symbols if you need to have someone debug on the field, etc. etc. It's just a compiler flag you never need to change. Then it's up to you to decide what to ship and what to keep. Giuliano From Special at Joepgen.com Mon May 29 11:50:36 2017 From: Special at Joepgen.com (Joe) Date: Mon, 29 May 2017 11:50:36 +0200 Subject: [Lazarus] Lazarus 1.8 RC1 under Raspbian Jessie In-Reply-To: References: <7ac6e745-c06c-9e33-a5eb-1b7b0adb8a12@Joepgen.com> Message-ID: Am 28.05.2017 um 22:40 schrieb Bo Berglund via Lazarus: > I might set up a new Pi soon for use at my vacation home over the > summer and when I do I will check the script again... I'm sure, this will be another very useful contribution from the famous 'Developer in Sweden'. Are you using the Pi Zero W? From shokwave at gmx.net Mon May 29 14:17:04 2017 From: shokwave at gmx.net (shoKwave) Date: Mon, 29 May 2017 14:17:04 +0200 Subject: [Lazarus] Key scan codes In-Reply-To: <6AEBEA16-C444-487C-AC2C-C5BE6B56A8E3@gmail.com> References: <6AEBEA16-C444-487C-AC2C-C5BE6B56A8E3@gmail.com> Message-ID: <1048c7ef-3afd-305d-ba30-7628a041dc37@gmx.net> Something like: procedure TForm1.FormKeyPress(Sender: TObject; var Key: char); begin Label1.Caption := '$' + IntToHex(Ord(Key), 2); end; Am 28.05.2017 um 23:11 schrieb Larry Dalton via Lazarus: > I need a function or procedure that will return the scan code for a keypress on both Linux systems and Windows, ie when the 'L' key is pressed it would return '$4C'. > > Sent from my iPhone From larrydalton71 at gmail.com Mon May 29 15:44:35 2017 From: larrydalton71 at gmail.com (Larry Dalton) Date: Mon, 29 May 2017 08:44:35 -0500 Subject: [Lazarus] Key scan codes In-Reply-To: <1048c7ef-3afd-305d-ba30-7628a041dc37@gmx.net> References: <6AEBEA16-C444-487C-AC2C-C5BE6B56A8E3@gmail.com> <1048c7ef-3afd-305d-ba30-7628a041dc37@gmx.net> Message-ID: <3D66603D-386A-4240-8BC0-9819B3EABF20@gmail.com> Yes. That is what I wanted. Thanks! Sent from my iPhone > On May 29, 2017, at 07:17, shoKwave via Lazarus wrote: > > Something like: > > procedure TForm1.FormKeyPress(Sender: TObject; var Key: char); > begin > Label1.Caption := '$' + IntToHex(Ord(Key), 2); > end; > > >> Am 28.05.2017 um 23:11 schrieb Larry Dalton via Lazarus: >> I need a function or procedure that will return the scan code for a keypress on both Linux systems and Windows, ie when the 'L' key is pressed it would return '$4C'. >> >> Sent from my iPhone > > -- > _______________________________________________ > Lazarus mailing list > Lazarus at lists.lazarus-ide.org > http://lists.lazarus-ide.org/listinfo/lazarus From bo.berglund at gmail.com Tue May 30 00:36:46 2017 From: bo.berglund at gmail.com (Bo Berglund) Date: Tue, 30 May 2017 00:36:46 +0200 Subject: [Lazarus] Lazarus 1.8 RC1 under Raspbian Jessie References: <7ac6e745-c06c-9e33-a5eb-1b7b0adb8a12@Joepgen.com> Message-ID: <4p7pictlb5ir45qhdc5akf833vq13o8ta7@4ax.com> On Sat, 27 May 2017 11:20:17 +0200, Joe via Lazarus wrote: >Am 26.05.2017 um 13:02 schrieb Bo Berglund via Lazarus: >> You could try my script for installation of FPC + Lazarus on an RPi3. >> http://blog.boberglund.com/install_lazfpc_local_pi.sh >> >> In order to get the version you need just edit the script before >> running it and replace the versions at the top of the file with the >> one you want. >Bo, >unfortunately, this failed with error message something could not be >found. Seems, I did not edit the script the right way. >What lines are to be edited and exactly how for Lazarus 1.8.0 RC1? >Thanx -- Joe Hi again! I have now returned home and been able to check the script. I used a brand new Jessie PIXEL image and did this before starting the script: - Created dir /home/pi/bin where the fpc binary will reside - Logged off and back on again to put this dir into the PATH Turns out that the fpc sourceinstall command on line #150 fails because there is no current path to the seed compiler ppcarm.... So I have added option FPC= on that line and with that done the script runs OK to the end and Lazarus is available on the main Jessie menu below "Programming". The corrected script is found here: http://blog.boberglund.com/install_lazfpc_local_pi.sh Regarding configuration, these lines need to be handled by editing the versions mainly (lines #32 and #43-46): LAZDESK=/home/pi/.local/share/applications/lazarus_1.6.2.desktop FPCTAG=release_3_0_0 FPCVER=3.0.0 LAZTAG=lazarus_1_6_2 LAZVER=1.6.2 In your case change them to this: LAZDESK=/home/pi/.local/share/applications/lazarus_1.8.RC1.desktop FPCTAG=release_3_0_2 FPCVER=3.0.2 LAZTAG=lazarus_1_8_0_RC1 LAZVER=1.8.RC1 HTH -- Bo Berglund Developer in Sweden From noreply at z505.com Tue May 30 03:50:37 2017 From: noreply at z505.com (noreply at z505.com) Date: Mon, 29 May 2017 20:50:37 -0500 Subject: [Lazarus] CodeTools On Event insert? detect In-Reply-To: <20170527093611.33ea9195@limapholos.matflo.wg> References: <20170526114412.2d4ec1f6@limapholos.matflo.wg> <7e124b226c711c63707e59cb8197a714@z505.com> <20170527093611.33ea9195@limapholos.matflo.wg> Message-ID: Mattias, I'm still having issues figuring out exactly what Donald Z.'s code does and how to use it, but is there even a way to "hook" the ide event insertion currently? i.e. if you throw a Button on a form and double click it, I want to hook into that, and insert code immediately after the event has been inserted into the ide text edit window.. If this feature is currently not implemented I can work on a patch today that does it, however I don't want to work on a patch if this feature already exists and I just can't find it. Something like: OnAfterEventInsert codetools/lazintf trigger - User adds button 1 to form - user double clicks button 1 - code is inserted inbetween begin/end automatically I think the templates may help this but is there really a hook like this in code tools where you can hook into the events inserted into the IDE when a user double clicks a button/widget or double clicks the event in the object inspector? From bo.berglund at gmail.com Tue May 30 07:42:30 2017 From: bo.berglund at gmail.com (Bo Berglund) Date: Tue, 30 May 2017 07:42:30 +0200 Subject: [Lazarus] Lazarus 1.8 RC1 under Raspbian Jessie References: <7ac6e745-c06c-9e33-a5eb-1b7b0adb8a12@Joepgen.com> Message-ID: <3e1qic9j8ktv4hrvacnbfhqpn2lbkofj1u@4ax.com> On Mon, 29 May 2017 11:50:36 +0200, Joe via Lazarus wrote: >I'm sure, this will be another very useful contribution from the famous >'Developer in Sweden'. Are you using the Pi Zero W? No, I am buying the RPi3 now but have a number of earlier generation Pi running their tasks also. I want the most performance I can get out of them. -- Bo Berglund Developer in Sweden From tc at epidata.info Tue May 30 08:36:50 2017 From: tc at epidata.info (Torsten Bonde Christiansen) Date: Tue, 30 May 2017 08:36:50 +0200 Subject: [Lazarus] Measuring text width in a TEdit Message-ID: Hi List. I want to know the placement of the caret (in pixels, not character count) in a TEdit. However i am struggeling to fint a method that will allow me to do so. If i try to calculate it using the assigned font, I have the problem that TEdit.Font.GetTextWidth always returns the default size (16), since the Font doesn't have a canvas assigned to it. The TEdit itself does not really have any methods for calculation the caret position in pixels either. All suggestions are welcome. :) Kind regards, Torsten Bonde Christiansen. From Special at Joepgen.com Tue May 30 10:48:22 2017 From: Special at Joepgen.com (Joe) Date: Tue, 30 May 2017 10:48:22 +0200 Subject: [Lazarus] Lazarus 1.8 RC1 under Raspbian Jessie In-Reply-To: <4p7pictlb5ir45qhdc5akf833vq13o8ta7@4ax.com> References: <7ac6e745-c06c-9e33-a5eb-1b7b0adb8a12@Joepgen.com> <4p7pictlb5ir45qhdc5akf833vq13o8ta7@4ax.com> Message-ID: Am 30.05.2017 um 00:36 schrieb Bo Berglund via Lazarus: > On Sat, 27 May 2017 11:20:17 +0200, Joe via Lazarus > wrote: > >> Am 26.05.2017 um 13:02 schrieb Bo Berglund via Lazarus: >>> You could try my script for installation of FPC + Lazarus on an RPi3. >>> http://blog.boberglund.com/install_lazfpc_local_pi.sh >>> >>> In order to get the version you need just edit the script before >>> running it and replace the versions at the top of the file with the >>> one you want. >> Bo, >> unfortunately, this failed with error message something could not be >> found. Seems, I did not edit the script the right way. >> What lines are to be edited and exactly how for Lazarus 1.8.0 RC1? >> Thanx -- Joe > Hi again! > I have now returned home and been able to check the script. > I used a brand new Jessie PIXEL image and did this before starting the > script: > - Created dir /home/pi/bin where the fpc binary will reside > - Logged off and back on again to put this dir into the PATH > > Turns out that the fpc sourceinstall command on line #150 fails > because there is no current path to the seed compiler ppcarm.... > So I have added option FPC= on that line and with that > done the script runs OK to the end and Lazarus is available on the > main Jessie menu below "Programming". > > The corrected script is found here: > http://blog.boberglund.com/install_lazfpc_local_pi.sh > > Regarding configuration, these lines need to be handled by editing the > versions mainly (lines #32 and #43-46): > > LAZDESK=/home/pi/.local/share/applications/lazarus_1.6.2.desktop > FPCTAG=release_3_0_0 > FPCVER=3.0.0 > LAZTAG=lazarus_1_6_2 > LAZVER=1.6.2 > > In your case change them to this: > > LAZDESK=/home/pi/.local/share/applications/lazarus_1.8.RC1.desktop > FPCTAG=release_3_0_2 > FPCVER=3.0.2 > LAZTAG=lazarus_1_8_0_RC1 > LAZVER=1.8.RC1 > > HTH > > . . Bo, helps a lot. Very kind. Have a nice day. Cordialmente -- Joe From vojtech.cihak at atlas.cz Tue May 30 14:02:28 2017 From: vojtech.cihak at atlas.cz (=?utf-8?q?Vojt=C4=9Bch_=C4=8Cih=C3=A1k?=) Date: Tue, 30 May 2017 14:02:28 +0200 Subject: [Lazarus] =?utf-8?q?Measuring_text_width_in_a_TEdit?= In-Reply-To: 00000000765300022a60011b4ff4 References: 00000000765300022a60011b4ff4 Message-ID: <20170530140228.6FF7C722@atlas.cz> Hi,   maybe you can create some temporary canvas, assign TEdit.Font to TCanvas.Font, do the measurement and free that canvas.   V. ______________________________________________________________ > Od: Torsten Bonde Christiansen via Lazarus > Komu: Lazarus mailing list > Datum: 30.05.2017 08:36 > Předmět: [Lazarus] Measuring text width in a TEdit > Hi List. I want to know the placement of the caret (in pixels, not character count) in a TEdit. However i am struggeling to fint a method that will allow me to do so. If i try to calculate it using the assigned font, I have the problem that TEdit.Font.GetTextWidth always returns the default size (16), since the Font doesn't have a canvas assigned to it. The TEdit itself does not really have any methods for calculation the caret position in pixels either. All suggestions are welcome. :) Kind regards, Torsten Bonde Christiansen. -- _______________________________________________ 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 May 30 14:12:21 2017 From: lazarus at mfriebe.de (Martin Frb) Date: Tue, 30 May 2017 13:12:21 +0100 Subject: [Lazarus] Measuring text width in a TEdit In-Reply-To: References: Message-ID: <9ee5ea29-af7f-693b-0a4e-ffa4d2db7d28@mfriebe.de> On 30/05/2017 07:36, Torsten Bonde Christiansen via Lazarus wrote: > Hi List. > > I want to know the placement of the caret (in pixels, not character > count) in a TEdit. However i am struggeling to fint a method that will > allow me to do so. > > If i try to calculate it using the assigned font, I have the problem > that TEdit.Font.GetTextWidth always returns the default size (16), > since the Font doesn't have a canvas assigned to it. If you are on windows (and win only), you may be able to use GetCaretPos https://msdn.microsoft.com/en-us/library/windows/desktop/ms648402(v=vs.85).aspx (That is, if the edit is focused, and has the caret) On Windows there is only one caret per App, so if the TEdit has it, then GetCaretPos should get the pos for that Edit. Of course win only, and the Edit needs the focus. (And not tested at all) From aaa5500 at ya.ru Tue May 30 15:10:13 2017 From: aaa5500 at ya.ru (Alexey) Date: Tue, 30 May 2017 16:10:13 +0300 Subject: [Lazarus] TFont.Assign not complete Message-ID: <51dd0c96-1f67-882c-0b92-f1562d630be0@ya.ru> Not sure it is ok, why not to a) copy Size, b) copy PixelsPerInch. why such strange logic. if TFont(Source).PixelsPerInch <> FPixelsPerInch then // use size to convert source height pixels to current resolution Size := TFont(Source).Size else // use height which users could have changed directly Height := TFont(Source).Height; Also good to copy PixelsPerInch to do good copy -- Regards, Alexey From vojtech.cihak at atlas.cz Tue May 30 15:47:46 2017 From: vojtech.cihak at atlas.cz (=?utf-8?q?Vojt=C4=9Bch_=C4=8Cih=C3=A1k?=) Date: Tue, 30 May 2017 15:47:46 +0200 Subject: [Lazarus] =?utf-8?q?TFont=2EAssign_not_complete?= In-Reply-To: 00000000765c00023c74011b502c References: 00000000765c00023c74011b502c Message-ID: <20170530154746.B038C7E2@atlas.cz> Hi,   IMO it should be OK. PixelsPerInchs has probably meaning when you have two displays with different DPI. Therefore copying the value PixelsPerInchs is wrong because method Assign() cannot know where the font will be displayed (on the same display or the second display with different DPI).   V.   ______________________________________________________________ > Od: Alexey via Lazarus > Komu: Lazarus mailing list > Datum: 30.05.2017 15:10 > Předmět: [Lazarus] TFont.Assign not complete > Not sure it is ok, why not to a) copy Size, b) copy PixelsPerInch. why such strange logic.           if TFont(Source).PixelsPerInch <> FPixelsPerInch then             // use size to convert source height pixels to current resolution             Size := TFont(Source).Size           else             // use height which users could have changed directly             Height := TFont(Source).Height; Also good to copy PixelsPerInch to do good copy -- Regards, Alexey -- _______________________________________________ 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 zeljko at holobit.net Tue May 30 16:04:23 2017 From: zeljko at holobit.net (zeljko) Date: Tue, 30 May 2017 16:04:23 +0200 Subject: [Lazarus] Measuring text width in a TEdit In-Reply-To: References: Message-ID: <9a5100d6-99f3-2dc8-6a99-43124b1d26b6@holobit.net> On 30.05.2017 08:36, Torsten Bonde Christiansen via Lazarus wrote: > Hi List. > > I want to know the placement of the caret (in pixels, not character > count) in a TEdit. However i am struggeling to fint a method that will > allow me to do so. > > If i try to calculate it using the assigned font, I have the problem > that TEdit.Font.GetTextWidth always returns the default size (16), since > the Font doesn't have a canvas assigned to it. > > The TEdit itself does not really have any methods for calculation the > caret position in pixels either. > > All suggestions are welcome. :) I'm using TBitmap which assigns TEdit.Font for such cases.Measurement is correct. zeljko From Sascha.Hestermann at gmx.de Tue May 30 19:40:15 2017 From: Sascha.Hestermann at gmx.de (John Landmesser) Date: Tue, 30 May 2017 17:40:15 +0000 Subject: [Lazarus] =?utf-8?q?=E2=98=80I=27m_so_excited_about_the_latest_ne?= =?utf-8?q?ws?= Message-ID: <1273581424.20170530194015@gmx.de> Greetings! Have you heard the latest news? I'm so excited about it, please read it here http://hope.ifyouchangenothingnothingwillchange.org In haste, John Landmesser Sent from Mail for Windows 10 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1701378ADC6F3470D6065675FA403A31.jpg Type: image/jpeg Size: 10055 bytes Desc: not available URL: From Sascha.Hestermann at gmx.de Tue May 30 19:40:25 2017 From: Sascha.Hestermann at gmx.de (Gabor Boros) Date: Tue, 30 May 2017 20:40:25 +0300 Subject: [Lazarus] =?utf-8?q?my_journey_was_amazing?= Message-ID: <1816274472.20170530194025@gmx.de> Hi friend! I'd like to tell you about my last journey, it was full of adventures, please read more here http://word.ravendiva.com See you soon, Gabor Boros From: Lazarus mailing list [mailto:lazarus at lists.lazarus.freepascal.org] Sent: Tuesday, May 30, 2017 12:40 PM To: Sascha.Hestermann at gmx.de Subject: What the fuck.... Well do you go to /r/coffee and tell them that? There's nothing inherently wrong with addiction as long as it doesn't have a huge negative impact. If someone can't quit smoking cold turkey, this is the way to go. I'd go as far as to say that the vast majority of smokers have tried to quit multiple times and failed. Shit's hard. Why anyone would be against something that reduces the harm to themselves and others generated by smoking is beyond me. Sent from Mail for Windows 10 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 23B46AFFAB322E6FBF5968733A5C598B.jpg Type: image/jpeg Size: 13926 bytes Desc: not available URL: From parkingspace26 at yahoo.com Tue May 30 20:50:36 2017 From: parkingspace26 at yahoo.com (Bob B.) Date: Tue, 30 May 2017 18:50:36 +0000 (UTC) Subject: [Lazarus] Default - minor Delphi incompatability References: <2115445347.3484359.1496170236308.ref@mail.yahoo.com> Message-ID: <2115445347.3484359.1496170236308@mail.yahoo.com> If you set a control's Default property to True, it still isn't unless you also set the TabStop property to true. I use Laz version 1.2.6 for Windowds. Bob B. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lazarus at kluug.net Tue May 30 16:43:49 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Tue, 30 May 2017 16:43:49 +0200 Subject: [Lazarus] TFont.Assign not complete In-Reply-To: <51dd0c96-1f67-882c-0b92-f1562d630be0@ya.ru> References: <51dd0c96-1f67-882c-0b92-f1562d630be0@ya.ru> Message-ID: <16d894da-9214-2e50-b3a0-4e11e30a1cc7@kluug.net> On 30.05.2017 15:10, Alexey via Lazarus wrote: > Also good to copy PixelsPerInch to do good copy PixelsPerInch must not be assigned. Ondrej From Special at Joepgen.com Wed May 31 13:57:37 2017 From: Special at Joepgen.com (Joe) Date: Wed, 31 May 2017 13:57:37 +0200 Subject: [Lazarus] Lazarus 1.8 RC1 under Raspbian Jessie In-Reply-To: <4p7pictlb5ir45qhdc5akf833vq13o8ta7@4ax.com> References: <7ac6e745-c06c-9e33-a5eb-1b7b0adb8a12@Joepgen.com> <4p7pictlb5ir45qhdc5akf833vq13o8ta7@4ax.com> Message-ID: Am 30.05.2017 um 00:36 schrieb Bo Berglund via Lazarus: > The corrected script is found here: > http://blog.boberglund.com/install_lazfpc_local_pi.sh . . On a Raspberry Pi Zero W, the script failes with this error: (9009) Assembling buildprojectdlg buildprojectdlg.pas(603) Error: (9008) Can't call the assembler, error -1 switching to external assembling buildprojectdlg.pas603) Fatal: (10026) There were 2 errors compiling module, stopping I had selected the option 'for all Pis'. Could it be a swap file size problem? On the Pi Zero W, the default size is 100 MB. Joe From markMLl.lazarus at telemetry.co.uk Wed May 31 14:04:03 2017 From: markMLl.lazarus at telemetry.co.uk (Mark Morgan Lloyd) Date: Wed, 31 May 2017 12:04:03 +0000 Subject: [Lazarus] Lazarus 1.8 RC1 under Raspbian Jessie In-Reply-To: References: <7ac6e745-c06c-9e33-a5eb-1b7b0adb8a12@Joepgen.com> <4p7pictlb5ir45qhdc5akf833vq13o8ta7@4ax.com> Message-ID: On 31/05/17 12:00, Joe via Lazarus wrote: > Am 30.05.2017 um 00:36 schrieb Bo Berglund via Lazarus:> The corrected > script is found here:> > http://blog.boberglund.com/install_lazfpc_local_pi.sh..On a Raspberry Pi > Zero W, the script failes with this error: > (9009) Assembling buildprojectdlgbuildprojectdlg.pas(603) Error: (9008) > Can't call the assembler, error -1 switching to external > assemblingbuildprojectdlg.pas603) Fatal: (10026) There were 2 errors > compiling module, stopping > I had selected the option 'for all Pis'.Could it be a swap file size > problem? On the Pi Zero W, the default size is 100 MB. Yes, assume you need at least 512Mb. Put a temporary swap partition onto an external USB stick or whatever. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] From Special at Joepgen.com Wed May 31 14:50:44 2017 From: Special at Joepgen.com (Joe) Date: Wed, 31 May 2017 14:50:44 +0200 Subject: [Lazarus] Lazarus 1.8 RC1 under Raspbian Jessie In-Reply-To: References: <7ac6e745-c06c-9e33-a5eb-1b7b0adb8a12@Joepgen.com> <4p7pictlb5ir45qhdc5akf833vq13o8ta7@4ax.com> Message-ID: Am 31.05.2017 um 14:04 schrieb Mark Morgan Lloyd via Lazarus: >> I had selected the option 'for all Pis'.Could it be a swap file size >> problem? On the Pi Zero W, the default size is 100 MB. > > Yes, assume you need at least 512Mb. Put a temporary swap partition > onto an external USB stick or whatever. > > -- . . I'll give it 1024 MBytes and a try. Thanx -- Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From Special at Joepgen.com Wed May 31 20:22:35 2017 From: Special at Joepgen.com (Joe) Date: Wed, 31 May 2017 20:22:35 +0200 Subject: [Lazarus] Lazarus 1.8 RC1 under Raspbian Jessie In-Reply-To: References: <7ac6e745-c06c-9e33-a5eb-1b7b0adb8a12@Joepgen.com> <4p7pictlb5ir45qhdc5akf833vq13o8ta7@4ax.com> Message-ID: <81fa4001-f152-0831-d827-d602dc71f8c6@Joepgen.com> Am 30.05.2017 um 10:48 schrieb Joe via Lazarus: > Am 30.05.2017 um 00:36 schrieb Bo Berglund via Lazarus: >> On Sat, 27 May 2017 11:20:17 +0200, Joe via Lazarus >> wrote: >> >>> Am 26.05.2017 um 13:02 schrieb Bo Berglund via Lazarus: >>>> You could try my script for installation of FPC + Lazarus on an RPi3. >>>> http://blog.boberglund.com/install_lazfpc_local_pi.sh >>>> >>>> In order to get the version you need just edit the script before >>>> running it and replace the versions at the top of the file with the >>>> one you want. >>> Bo, >>> unfortunately, this failed with error message something could not be >>> found. Seems, I did not edit the script the right way. >>> What lines are to be edited and exactly how for Lazarus 1.8.0 RC1? >>> Thanx -- Joe >> Hi again! >> I have now returned home and been able to check the script. >> I used a brand new Jessie PIXEL image and did this before starting the >> script: >> - Created dir /home/pi/bin where the fpc binary will reside >> - Logged off and back on again to put this dir into the PATH >> >> Turns out that the fpc sourceinstall command on line #150 fails >> because there is no current path to the seed compiler ppcarm.... >> So I have added option FPC= on that line and with that >> done the script runs OK to the end and Lazarus is available on the >> main Jessie menu below "Programming". >> >> The corrected script is found here: >> http://blog.boberglund.com/install_lazfpc_local_pi.sh >> >> Regarding configuration, these lines need to be handled by editing the >> versions mainly (lines #32 and #43-46): >> >> LAZDESK=/home/pi/.local/share/applications/lazarus_1.6.2.desktop >> FPCTAG=release_3_0_0 >> FPCVER=3.0.0 >> LAZTAG=lazarus_1_6_2 >> LAZVER=1.6.2 >> >> In your case change them to this: >> >> LAZDESK=/home/pi/.local/share/applications/lazarus_1.8.RC1.desktop >> FPCTAG=release_3_0_2 >> FPCVER=3.0.2 >> LAZTAG=lazarus_1_8_0_RC1 >> LAZVER=1.8.RC1 >> >> HTH >> >> > . > . > Bo, helps a lot. Very kind. Have a nice day. > Cordialmente -- Joe . . I stored this script as install_lazfpc_local_pi-0.sh and the modified version for Lazarus 1.8.RC1 as install_lazfpc_local_pi-1.sh. See http:/transfer.joepgen.com/diffresult.txt Then, on a Pi Zero W, I prepared a brand new Jessie PIXEL image on a 32 GB card and - Set Locale Settings to Germany and WiFi settings - Created dir /home/pi/bin - Logged off and back on again to put this dir into the PATH - Enlarged the swap file size from 100 MB to 1024 MB, stopped and restarted swapfile - started the script - the question 'Which model of RPi do you want to build for' I answered with 'ARMv6' 62 minutes later the compilation was aborted due to access violations. See http://transfer.joepgen.com/ErrorMessages SWeems .. Joe From Special at Joepgen.com Wed May 31 20:29:07 2017 From: Special at Joepgen.com (Joe) Date: Wed, 31 May 2017 20:29:07 +0200 Subject: [Lazarus] Fwd: Re: Lazarus 1.8 RC1 under Raspbian Jessie In-Reply-To: <81fa4001-f152-0831-d827-d602dc71f8c6@Joepgen.com> References: <81fa4001-f152-0831-d827-d602dc71f8c6@Joepgen.com> Message-ID: -------- Weitergeleitete Nachricht -------- Betreff: Re: [Lazarus] Lazarus 1.8 RC1 under Raspbian Jessie Datum: Wed, 31 May 2017 20:22:35 +0200 Von: Joe An: lazarus at lists.lazarus-ide.org Am 30.05.2017 um 10:48 schrieb Joe via Lazarus: > Am 30.05.2017 um 00:36 schrieb Bo Berglund via Lazarus: >> On Sat, 27 May 2017 11:20:17 +0200, Joe via Lazarus >> wrote: >> >>> Am 26.05.2017 um 13:02 schrieb Bo Berglund via Lazarus: >>>> You could try my script for installation of FPC + Lazarus on an RPi3. >>>> http://blog.boberglund.com/install_lazfpc_local_pi.sh >>>> >>>> In order to get the version you need just edit the script before >>>> running it and replace the versions at the top of the file with the >>>> one you want. >>> Bo, >>> unfortunately, this failed with error message something could not be >>> found. Seems, I did not edit the script the right way. >>> What lines are to be edited and exactly how for Lazarus 1.8.0 RC1? >>> Thanx -- Joe >> Hi again! >> I have now returned home and been able to check the script. >> I used a brand new Jessie PIXEL image and did this before starting the >> script: >> - Created dir /home/pi/bin where the fpc binary will reside >> - Logged off and back on again to put this dir into the PATH >> >> Turns out that the fpc sourceinstall command on line #150 fails >> because there is no current path to the seed compiler ppcarm.... >> So I have added option FPC= on that line and with that >> done the script runs OK to the end and Lazarus is available on the >> main Jessie menu below "Programming". >> >> The corrected script is found here: >> http://blog.boberglund.com/install_lazfpc_local_pi.sh >> >> Regarding configuration, these lines need to be handled by editing the >> versions mainly (lines #32 and #43-46): >> >> LAZDESK=/home/pi/.local/share/applications/lazarus_1.6.2.desktop >> FPCTAG=release_3_0_0 >> FPCVER=3.0.0 >> LAZTAG=lazarus_1_6_2 >> LAZVER=1.6.2 >> >> In your case change them to this: >> >> LAZDESK=/home/pi/.local/share/applications/lazarus_1.8.RC1.desktop >> FPCTAG=release_3_0_2 >> FPCVER=3.0.2 >> LAZTAG=lazarus_1_8_0_RC1 >> LAZVER=1.8.RC1 >> >> HTH >> >> > . > . > Bo, helps a lot. Very kind. Have a nice day. > Cordialmente -- Joe . . I stored this script as install_lazfpc_local_pi-0.sh and the modified version for Lazarus 1.8.RC1 as install_lazfpc_local_pi-1.sh. See http:/transfer.joepgen.com/diffresult.txt Then, on a Pi Zero W, I prepared a brand new Jessie PIXEL image on a 32 GB card and - Set Locale Settings to Germany and WiFi settings - Created dir /home/pi/bin - Logged off and back on again to put this dir into the PATH - Enlarged the swap file size from 100 MB to 1024 MB, stopped and restarted swapfile - started the script - the question 'Which model of RPi do you want to build for' I answered with 'ARMv6' 62 minutes later the compilation was aborted due to access violations. See http://transfer.joepgen.com/ErrorMessages SWeems .. Joe . . Sorry, the file name extent was missing. Please use http://transfer.joepgen.com/ErrorMessages.png -------------- next part -------------- An HTML attachment was scrubbed... URL: From Special at Joepgen.com Wed May 31 20:50:27 2017 From: Special at Joepgen.com (Joe) Date: Wed, 31 May 2017 20:50:27 +0200 Subject: [Lazarus] Lazarus 1.8 RC1 under Raspbian Jessie In-Reply-To: <20170527113809.76ecfd16@limapholos.matflo.wg> References: <506e7e1b-d75b-37c3-69aa-169683a22702@Joepgen.com> <20170527113809.76ecfd16@limapholos.matflo.wg> Message-ID: <87ce2b06-ebd6-2bc4-9c11-d315298b83d3@Joepgen.com> Am 27.05.2017 um 11:38 schrieb Mattias Gaertner via Lazarus: > On Sat, 27 May 2017 11:25:56 +0200 > Joe via Lazarus wrote: > >> Am 26.05.2017 um 15:29 schrieb Mark Morgan Lloyd via Lazarus: >>> Just to check the "standard way of doing it" in case there's any >>> surprises, with FPC 3.0.2 installed: >>> >>> svn co http://svn.freepascal.org/svn/lazarus/tags/lazarus_1_8_0_RC1 >>> cd lazarus_1_8_0_RC1 >>> make >>> >>> That worked as expected. >>> >>> make clean bigide >> Mark, >> I installed FPC 3.0.2 and then followed your proposal. But the >> compilation of Lazarus 1.8.0 RC1 was aborted with an error message >> saying FPC 3.0.0 was needed. > What is the exact error message? > > Mattias . . Another attempt lead to this result: http://transfer.joepgen.com/ErrorMessage.png Pi Zero W, Bo's script, swap file enlarged from 100 to 1024 MBytes. From Special at Joepgen.com Wed May 31 20:54:16 2017 From: Special at Joepgen.com (Joe) Date: Wed, 31 May 2017 20:54:16 +0200 Subject: [Lazarus] Lazarus 1.8 RC1 under Raspbian Jessie In-Reply-To: <20170527113809.76ecfd16@limapholos.matflo.wg> References: <506e7e1b-d75b-37c3-69aa-169683a22702@Joepgen.com> <20170527113809.76ecfd16@limapholos.matflo.wg> Message-ID: <891c0691-c6d5-99d3-4f87-db46893a4820@Joepgen.com> Am 27.05.2017 um 11:38 schrieb Mattias Gaertner via Lazarus: > On Sat, 27 May 2017 11:25:56 +0200 > Joe via Lazarus wrote: > >> Am 26.05.2017 um 15:29 schrieb Mark Morgan Lloyd via Lazarus: >>> Just to check the "standard way of doing it" in case there's any >>> surprises, with FPC 3.0.2 installed: >>> >>> svn co http://svn.freepascal.org/svn/lazarus/tags/lazarus_1_8_0_RC1 >>> cd lazarus_1_8_0_RC1 >>> make >>> >>> That worked as expected. >>> >>> make clean bigide >> Mark, >> I installed FPC 3.0.2 and then followed your proposal. But the >> compilation of Lazarus 1.8.0 RC1 was aborted with an error message >> saying FPC 3.0.0 was needed. > What is the exact error message? > > Mattias . Sorry, must be ErrorMessages.png, not ErrorMessage.png Another attempt lead to this result: http://transfer.joepgen.com/ErrorMessages.png Pi Zero W, Bo's script, swap file enlarged from 100 to 1024 MBytes. -- Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From friess at gmx.at Wed May 31 20:57:21 2017 From: friess at gmx.at (Andreas) Date: Wed, 31 May 2017 20:57:21 +0200 Subject: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 In-Reply-To: <2bab6184-470d-412d-049d-23e68b701029@gmx.at> References: <20170517143928.1d2588e4@limapholos.matflo.wg> <71bc1b7f-adcc-8abb-5cf9-27745bcedb04@gmx.at> <2b6fb59c-42e0-79f0-4c01-faeff6cd3c59@freenet.de> <2bab6184-470d-412d-049d-23e68b701029@gmx.at> Message-ID: <0M2nfO-1e5UsI1sf8-00sfq8@mail.gmx.com> Lazarus 1.8.0RC1 r55107 FPC 3.1.1 i386-win32-win32/win64 with fpspreadsheet r5910 its ok. THX 4 your help and your time Gesendet von Mail für Windows 10 Von: Andreas Frieß via Lazarus Gesendet: Samstag, 27. Mai 2017 11:29 An: lazarus at lists.lazarus-ide.org Betreff: Re: [Lazarus] Lazarus Release Candidate 1 of 1.8.0 Am 19.05.2017 um 01:30 schrieb Werner Pamler via Lazarus: > Am 18.05.2017 um 00:41 schrieb Werner Pamler via Lazarus: >> Am 17.05.2017 um 23:08 schrieb Andreas Frieß via Lazarus: >>> I see with the last patches something goes wrong after r54880 with >>> frames and grid (specially TsWorkSheetGrid). >>> >>> Lazarus claims, the is no valid parent and didnot load and crash. It >>> is only happen if you use frames ? The trouble is, i can only >>> shutdown Lazarus with the Processmanger. >>> >>> Win10/64 with Lazarus 32/svn 1.9RC1 >> >> This is confusing: Are you using Laz trunk (v1.9) or 1.8RC1? I don't >> see an issue with WorksheetGrid on frames with Laz trunk. Can you >> post a demo? > > Andreas, could you try r5868 of fpspreadsheet? I fixed a "Window has > no parent" error with frames which had crept in, again... > Werner thank you, i will make a try and i will look for the changes, because i found other (older) components they have some trouble with frames (DirectShow) too. Next week i can spend some time to check this with a fresh installation to avoid side effects. Andreas -- _______________________________________________ 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 Special at Joepgen.com Wed May 31 21:03:49 2017 From: Special at Joepgen.com (Joe) Date: Wed, 31 May 2017 21:03:49 +0200 Subject: [Lazarus] Lazarus 1.8 RC1 under Raspbian Jessie In-Reply-To: <20170527113809.76ecfd16@limapholos.matflo.wg> References: <506e7e1b-d75b-37c3-69aa-169683a22702@Joepgen.com> <20170527113809.76ecfd16@limapholos.matflo.wg> Message-ID: Am 27.05.2017 um 11:38 schrieb Mattias Gaertner via Lazarus: > On Sat, 27 May 2017 11:25:56 +0200 > Joe via Lazarus wrote: > >> Am 26.05.2017 um 15:29 schrieb Mark Morgan Lloyd via Lazarus: >>> Just to check the "standard way of doing it" in case there's any >>> surprises, with FPC 3.0.2 installed: >>> >>> svn co http://svn.freepascal.org/svn/lazarus/tags/lazarus_1_8_0_RC1 >>> cd lazarus_1_8_0_RC1 >>> make >>> >>> That worked as expected. >>> >>> make clean bigide >> Mark, >> I installed FPC 3.0.2 and then followed your proposal. But the >> compilation of Lazarus 1.8.0 RC1 was aborted with an error message >> saying FPC 3.0.0 was needed. > What is the exact error message? > > Mattias . Somethin is wrong with this link. Trying again: Please use http://transfer.joepgen.com/ErrorMessages.png