From leledumbo_cool at yahoo.co.id Mon Mar 1 04:55:42 2021 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Sun, 28 Feb 2021 20:55:42 -0700 (MST) Subject: [Lazarus] Does fsStayOnTop not work for forms on Linux? In-Reply-To: References: Message-ID: <1614570942225-0.post@n3.nabble.com> > Is this property just a Windows feature? Certainly no, as it works on my Manjaro KDE, both fsStayOnTop and fsSystemStayOnTop. > Is this a problem with Ubuntu Mate 20.04? Could be, I don't use Mate and not all DEs are created equal (KDE also has its own quirks regarding stay on top, but LCL implementation works). -- Sent from: http://free-pascal-lazarus.989080.n3.nabble.com/ From joshyfun at gmail.com Mon Mar 1 20:16:08 2021 From: joshyfun at gmail.com (=?UTF-8?Q?Jos=c3=a9_Mejuto?=) Date: Mon, 1 Mar 2021 20:16:08 +0100 Subject: [Lazarus] unit Masks vs. unit FPMasks In-Reply-To: References: <7cd77c4a-0682-5039-a191-2b5d5ee5adfd@gmail.com> <33060b0c-e880-eaf1-01c5-d59624484b56@gmail.com> <76bbc05e-ebc8-d297-8a27-67600bcf608e@gmail.com> Message-ID: El 25/02/2021 a las 15:21, Juha Manninen via lazarus escribió: Hello, > Ok, true. > Escaping special characters would be very handy. A pity. I've uploaded last TMask* code to my github, this way its easier to track changes. https://github.com/JoshyFun/pascal_tmask Have a nice day!. -- From luca at wetron.es Tue Mar 2 11:27:46 2021 From: luca at wetron.es (Luca Olivetti) Date: Tue, 2 Mar 2021 11:27:46 +0100 Subject: [Lazarus] Lazarus Release 2.0.12 In-Reply-To: <20210224120959.258c79ac@limapholos.matflo.wg> References: <20210224120959.258c79ac@limapholos.matflo.wg> Message-ID: El 24/2/21 a les 12:09, Mattias Gaertner via lazarus ha escrit: > The Lazarus team is glad to announce the release of Lazarus 2.0.12. I just checked the help -> about lazarus and in the Contributors and Acknowledgements tabs all the names with special characters are messed up in win32, they're ok in linux. I self compile lazarus from the corresponding svn tag (now lazarus_2_0_12) with fpc 3.2.0. Just FYI, I didn't notice any problem with utf-8 characters in my projects (well, apart from having to specify the encoding with inifiles and the fact that TMemInifile doesn't have a create method that allows to specify the encoding). Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From luca at wetron.es Tue Mar 2 12:13:33 2021 From: luca at wetron.es (Luca Olivetti) Date: Tue, 2 Mar 2021 12:13:33 +0100 Subject: [Lazarus] Lazarus Release 2.0.12 In-Reply-To: References: <20210224120959.258c79ac@limapholos.matflo.wg> Message-ID: <22ff0746-e796-724e-b44e-24247884dd59@wetron.es> El 2/3/21 a les 11:27, Luca Olivetti via lazarus ha escrit: > and the fact that TMemInifile doesn't have a create method that allows > to specify the encoding). This is worse than I initially thought: the only way to specify an encoding is to use a stream and a TIniFile (with a TMemIniFile is impossible). The problem is, the TIniFile doesn't free the stream when it is destroyed. I couldn't find a way to specify an encoding after the fact (there's a protected method SetEncoding but at that point it's too late since the values have already been loaded in memory). The best I could come up to, to emulate a TMemInifile and specify the encoding, is to subclass TiniFile TMyIniFile = class(TIniFile) public constructor Create(const fname:string); destructor Destroy;override; end; constructor TMyIniFile.Create(const fname: string); begin inherited Create(TFileStream.Create(fname, fmOpenReadWrite), Encoding.UTF8); CacheUpdates:=true; end; destructor TMyIniFile.Destroy; begin inherited Destroy; Stream.Free; end; and hoping that in a newer release fpc still doesn't free the stream or uses FreeAndNil so the Stream.Free doesn't bomb out. Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From luca at wetron.es Tue Mar 2 13:13:49 2021 From: luca at wetron.es (Luca Olivetti) Date: Tue, 2 Mar 2021 13:13:49 +0100 Subject: [Lazarus] Lazarus Release 2.0.12 In-Reply-To: <22ff0746-e796-724e-b44e-24247884dd59@wetron.es> References: <20210224120959.258c79ac@limapholos.matflo.wg> <22ff0746-e796-724e-b44e-24247884dd59@wetron.es> Message-ID: <18a49d4c-97ee-5e36-f577-b7f88d7ef3a8@wetron.es> El 2/3/21 a les 12:13, Luca Olivetti via lazarus ha escrit: > El 2/3/21 a les 11:27, Luca Olivetti via lazarus ha escrit: > >> and the fact that TMemInifile doesn't have a create method that allows >> to specify the encoding). > > This is worse than I initially thought: > > the only way to specify an encoding is to use a stream and a TIniFile > (with a TMemIniFile is impossible). The problem is, the TIniFile doesn't > free the stream when it is destroyed. > I couldn't find a way to specify an encoding after the fact (there's a > protected method SetEncoding but at that point it's too late since the > values have already been loaded in memory). > The best I could come up to, to emulate a TMemInifile and specify the > encoding, is to subclass TiniFile BTW, by looking at https://wiki.freepascal.org/Unicode_Support_in_Lazarus#RTL_with_default_codepage_UTF-8 none of this should be necessary, yet it is. A bug somewhere or the wiki page is not correct? Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From bartjunk64 at gmail.com Tue Mar 2 15:22:07 2021 From: bartjunk64 at gmail.com (Bart) Date: Tue, 2 Mar 2021 15:22:07 +0100 Subject: [Lazarus] unit Masks vs. unit FPMasks In-Reply-To: References: <7cd77c4a-0682-5039-a191-2b5d5ee5adfd@gmail.com> <33060b0c-e880-eaf1-01c5-d59624484b56@gmail.com> <76bbc05e-ebc8-d297-8a27-67600bcf608e@gmail.com> Message-ID: On Mon, Mar 1, 2021 at 8:16 PM José Mejuto via lazarus wrote: > I've uploaded last TMask* code to my github, this way its easier to > track changes. > > https://github.com/JoshyFun/pascal_tmask First we will fork Lazarus 2.2 Then work in mask unit can proceed. I wonder if we could have both implementations sied by side for a while (so masks = old one, the new one whould have an appropriate new neame like lazmasks or similar). The component should still be called TMask and TMaskList and the function MatchesMask(list) should remain. This way backwards compatibility is preserved. And we buy ourselves time. Later on we can then deprecate the old masks unit (in 2.4) and only use the new one (remove the old one in 2.6). The advantage of this is that the new implementation is not hindered by the old implementation. So, no need to implement TMask.MatchesWindowsMask in the new implementation. I did not study th enew implementation in depth, but things like escaping sound OK, if configurable. Case sensitivity must be configurable, and in contrast to TMask we might choose to implement is as CaseSensitive/CaseInsensitive/OSDefault. Doing it in such a way would also make adapting the TShell* controls easier, we can simply publish a property that controls the options for the mask. -- Bart From joshyfun at gmail.com Tue Mar 2 19:18:40 2021 From: joshyfun at gmail.com (=?UTF-8?Q?Jos=c3=a9_Mejuto?=) Date: Tue, 2 Mar 2021 19:18:40 +0100 Subject: [Lazarus] unit Masks vs. unit FPMasks In-Reply-To: References: <7cd77c4a-0682-5039-a191-2b5d5ee5adfd@gmail.com> <33060b0c-e880-eaf1-01c5-d59624484b56@gmail.com> <76bbc05e-ebc8-d297-8a27-67600bcf608e@gmail.com> Message-ID: <00d767f8-2e81-2c38-a697-acce2a72f31f@gmail.com> El 02/03/2021 a las 15:22, Bart via lazarus escribió: Hello, > First we will fork Lazarus 2.2 > Then work in mask unit can proceed. > The advantage of this is that the new implementation is not hindered > by the old implementation. > So, no need to implement TMask.MatchesWindowsMask in the new implementation. It's implemented as a new class, descendant from TMask*. Of course it needs some unit testing. > I did not study th enew implementation in depth, but things like > escaping sound OK, if configurable. It is, character and use it or not. > Case sensitivity must be configurable, and in contrast to TMask we > might choose to implement is as > CaseSensitive/CaseInsensitive/OSDefault. Currently not OSDefault as for files it should be filesystem default which is unknown (filesystem decides on each call) and for regular strings I do not know which could be "OSDefault" :-? > Doing it in such a way would also make adapting the TShell* controls > easier, we can simply publish a property that controls the options for > the mask. No problem, you can use the code or move it to the trash bin :-) -- From luca at wetron.es Wed Mar 3 09:42:53 2021 From: luca at wetron.es (Luca Olivetti) Date: Wed, 3 Mar 2021 09:42:53 +0100 Subject: [Lazarus] Lazarus Release 2.0.12 In-Reply-To: <18a49d4c-97ee-5e36-f577-b7f88d7ef3a8@wetron.es> References: <20210224120959.258c79ac@limapholos.matflo.wg> <22ff0746-e796-724e-b44e-24247884dd59@wetron.es> <18a49d4c-97ee-5e36-f577-b7f88d7ef3a8@wetron.es> Message-ID: <4b7d4d17-7af8-db8b-890b-b58c729fb87a@wetron.es> El 2/3/21 a les 13:13, Luca Olivetti via lazarus ha escrit: > El 2/3/21 a les 12:13, Luca Olivetti via lazarus ha escrit: >> El 2/3/21 a les 11:27, Luca Olivetti via lazarus ha escrit: >> >>> and the fact that TMemInifile doesn't have a create method that >>> allows to specify the encoding). > >> This is worse than I initially thought: >> >> the only way to specify an encoding is to use a stream and a TIniFile >> (with a TMemIniFile is impossible). The problem is, the TIniFile >> doesn't free the stream when it is destroyed. >> I couldn't find a way to specify an encoding after the fact (there's a >> protected method SetEncoding but at that point it's too late since the >> values have already been loaded in memory). >> The best I could come up to, to emulate a TMemInifile and specify the >> encoding, is to subclass TiniFile > > BTW, by looking at > > https://wiki.freepascal.org/Unicode_Support_in_Lazarus#RTL_with_default_codepage_UTF-8 > > > > none of this should be necessary, yet it is. A bug somewhere or the wiki > page is not correct? It turns out that my lazarus under windows was configured to use FPC 3.2.0 *BETA*, not the released version. With 3.2.0 proper everything seems to be fine. Sorry for the noise. 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 Mar 3 11:07:47 2021 From: luca at wetron.es (Luca Olivetti) Date: Wed, 3 Mar 2021 11:07:47 +0100 Subject: [Lazarus] Lazarus Release 2.0.12 In-Reply-To: <4b7d4d17-7af8-db8b-890b-b58c729fb87a@wetron.es> References: <20210224120959.258c79ac@limapholos.matflo.wg> <22ff0746-e796-724e-b44e-24247884dd59@wetron.es> <18a49d4c-97ee-5e36-f577-b7f88d7ef3a8@wetron.es> <4b7d4d17-7af8-db8b-890b-b58c729fb87a@wetron.es> Message-ID: El 3/3/21 a les 9:42, Luca Olivetti via lazarus ha escrit: > With 3.2.0 proper everything seems to be fine. Well, not really. I forgot about this: https://bugs.freepascal.org/view.php?id=37370 Could somebody look into it? Even with my fix I'm having other problems with sdfdataset that I'm currently investigating. After all, there was a reason why I was still using an older version of fpc ;-) Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From marco at marcozehe.de Fri Mar 5 11:07:45 2021 From: marco at marcozehe.de (Marco Zehe) Date: Fri, 5 Mar 2021 11:07:45 +0100 (CET) Subject: [Lazarus] LCL and Lazarus Accessibility - restarting the discussion Message-ID: <338087875.51341.1614938865972@office.mailbox.org> Hello there! My name is Marco, I am new to this list and new to Free Pascal and Lazarus. I have previously been involved with Delphi. I am, among other things, responsible for the accessibility implementation in TVirtualStringTree, which I made in 2007. I am interested in restarting an effort to make the LCL components and Lazarus itself more accessible to screen reader users. There are a lot of things that work, but unfortunately a lot that don't yet, and some assumptions about current implementations/values aren't up to what accessibility actually requires. An example: The way AccessibleDescription is mapped on different platforms, is creative, but not always correct. :-) I wanted to get started with this issue: https://bugs.freepascal.org/view.php?id=24135, TBitBtn not exposing its text as the Accessible Name. This is the primary information NVDA and other screen readers on Windows use to speak what a button does. In LCL, there is currently no equivalent, AccDescription and AccValue are being used interchangeably for some of the derived classes, but that is actually not so correct. For most standard controls, the Caption property maps, which is correct. For TBitBtn, the attempt to set the window text failed because of text duplication. Question: Have you tried to set the text as the window title in the parameters in TWin32WSBitBtn.CreateHandle instead? I am blind myself, so cannot say if that would have any negative visual side effects, or if this is even supported. If this does not work, which would be surprising since in Delphi, TBitBtn's caption does get exposed to screen readers by default, the only other option we have is to create a dynamic Accessibility Annotation through OLE COM. A simple example is here on the Microsoft Docs page: https://docs.microsoft.com/en-us/windows/win32/winauto/using-direct-annotation. Only in our case, we would set the AccName property to the caption upon creation, or the text each time TWin32WSBitBtn.SetText is called. The way you draw the text is not being picked up by screen readers or the Microsoft accessibility proxy that gets created automatically. But with the above method, we could override this in a simple enough fashion without having to implement the whole IAccessible interface, or - God forbid - UI Automation, Microsoft's newer and much more complicated accessibility APIs. Second: I then looked at this other issue about role inconsistencies: https://bugs.freepascal.org/view.php?id=26910. I currently do not yet understand how the LCLAccessibilityRoles are mapped to Win32 equivalents in the first place. I see some mappings for COCOA, QT4 and QT5, and others, but not Win32. For Win32, I see only empty class procedure definitions for the various properties, so I must assume all others are so far derived from the CreateWindow calls with the proper class names. What I do not see, as stated in that original report, is that everything is an ANIMATION role. So something must have changed already but not documented in that issue. In any case, the above example by Microsoft provides a method to annotate custom drawn components to become accessible, too. There should be a default mapping for roles in place for Win32, the caption should be mapped to the name in most cases, and a hint, if present, or a tooltip, to AccDescription. For edits, as discussed somewhere on a forum, which have an associated TLabel or TStaticText, the AccName would have to be that TLabel's or TStaticText's caption. The association would have to be through TLabel's or TStaticText's FocusControl property, don't know if TEdit and similar support a reverse lookup yet, e. g. if they're being focus-controlled by some other component. But that would be the way forward. For some components like list views or tree views, some of the more advanced mappings described here might have to take place: https://docs.microsoft.com/en-us/windows/win32/winauto/value-map-annotation. In any case, this requires the use of COM. Don't know if that is standard in the LCL yet. The trigger is usually that an accessibility client sends a WM_GETOBJECT message to a control to get its accessible information. Some, like TBitBtn, already expose an accessible object, some, like the AutoComplete list in the Components List of the Lazarus IDE, do not. They appear as a generic window with plain text. I would love to work on this, but would definitely need some guidance. For one: How are roles mapped on Win32, if at all yet? And second: Is there any sample code yet that I could use to get up and running with COM quickly in the LCL? Thank you for reading, and sorry for the long read! Marco From david at scootersoftware.com Fri Mar 5 17:26:12 2021 From: david at scootersoftware.com (David Jenkins) Date: Fri, 5 Mar 2021 10:26:12 -0600 Subject: [Lazarus] LCL and Lazarus Accessibility - restarting the discussion In-Reply-To: <338087875.51341.1614938865972@office.mailbox.org> References: <338087875.51341.1614938865972@office.mailbox.org> Message-ID: Marco (and others) I have been working on implementing Accessibility for Cocoa and Qt5. Mostly I have been working in the lcl/interfaces/cocoa and lcl/interfaces/qt5 directories creating the widget level plumbing needed to interface with TLazAccessibleObject. However, I have made a few fixes and changes to TLazAccessibleObject as well. I have fixed access to the child tree so that it is actually dataobject sorted so that the search functions work. And I have added a accessibilityName field to work with accessibilityDescription, accessibilityRole, and accessibilityValue. In Cocoa this matches the accessibile Title and in qt it matches accessibile Name. Both Qt and Cocoa have an accessibleDescription field but it does not map well to the laz accessibleDescription which is being used the same way the Qt and Cocoa use the Name/Title field. My Cocoa implementation is well developed and gives us access to all parts of our app that isn't custom (though I am able to add our custom objects as well - just haven't got all of them yet). The Qt5 implementation is fairly basic yet. It does all native controls and also a base implemenation of TCustomTreeView. I intend to clean up what I currently have and submit as a patch within the next weeks. David Jenkins From marco at marcozehe.de Fri Mar 5 17:44:38 2021 From: marco at marcozehe.de (Marco Zehe) Date: Fri, 5 Mar 2021 17:44:38 +0100 Subject: [Lazarus] LCL and Lazarus Accessibility - restarting the discussion In-Reply-To: References: <338087875.51341.1614938865972@office.mailbox.org> Message-ID: <51C84B86-08E7-4F7C-928B-55AC763E9BDE@marcozehe.de> Hi David! Wow, that sounds exciting! Look forward to your patch. I did some digging, and found that on Windows, TTreeView does not create any handles at all yet. It would require at least some basics there, or even accessibility properties, but I am still hoping we can avoid what I had to do for TVirtualStringTree in 2007, implementing literally two IAccessible interfaces, one for tree, one for the focused tree item. That all was managed by a singleton class instance, and juggled quite a bit. Pretty unreliable, so I hope we can make it better in TTreeView for the LCL. Right now, however, I don’t even know where to start yet to implement this. There is a unit in the Win32 folder, but nothing in there besides the comments. And from what it sounds like, it makes sense to wait for your patch so I, or we, can then build on that and make the Windows implementations better. Marco From david at scootersoftware.com Fri Mar 5 18:04:37 2021 From: david at scootersoftware.com (David Jenkins) Date: Fri, 5 Mar 2021 11:04:37 -0600 Subject: [Lazarus] LCL and Lazarus Accessibility - restarting the discussion In-Reply-To: <51C84B86-08E7-4F7C-928B-55AC763E9BDE@marcozehe.de> References: <338087875.51341.1614938865972@office.mailbox.org> <51C84B86-08E7-4F7C-928B-55AC763E9BDE@marcozehe.de> Message-ID: On 3/5/21 10:44 AM, Marco Zehe via lazarus wrote: > Hi David! > > Wow, that sounds exciting! Look forward to your patch. > > I did some digging, and found that on Windows, TTreeView does not create any handles at all yet. It would require at least some basics there, or even accessibility properties, but I am still hoping we can avoid what I had to do for TVirtualStringTree in 2007, implementing literally two IAccessible interfaces, one for tree, one for the focused tree item. That all was managed by a singleton class instance, and juggled quite a bit. Pretty unreliable, so I hope we can make it better in TTreeView for the LCL. > > Right now, however, I don’t even know where to start yet to implement this. There is a unit in the Win32 folder, but nothing in there besides the comments. And from what it sounds like, it makes sense to wait for your patch so I, or we, can then build on that and make the Windows implementations better. > > Marco > For any tree type objects that I have dealt with (both LCL and custom) I have created Ax objects for the tree and Ax objects for the items as well. And in cocoa I had to create an additional layer: Tree/Row/Item in Row. A couple of deficiencies that I have run across with the LCL accessibility layer are 1) No notification capability both Cocoa and Qt include functionality to send notifications to Ax Clients to let them know of changes to the UI 2) TLazAccessibleObject handle creation doesn't sync well with TLazAccessibleObject.Ownercontrol handle creation. Both Cocoa and Qt include accessibilty support in their base widgets that can be leveraged as TlazAccessibileObject handles. But TLazAccessibleObject will request a handle before the associated TWinControl has handleallocated and doesn't know to retry for a handle after the TWinControl get's its handle. It would be good to include a path where TLazAccessibleObject handle is requested after the TWinControl.Handle is created. I will note that reading the comments surrounding the TLazAccessibleObject code in Controls and control.inc are important. I made a couple of bad assumptions about how the code worked before I read all the comments. The first was that TLazAccessibleObject.Children objects are not meant for TControl or TWinControl objects. They are only for visual items that don't have a TControl or TWinControl object. E.g. row items in a tree view. And the difference in getting children by either using the iterator or doing First / Next. The iterator returns the objects in the child tree only. First / Next will get the objects from the child tree but also any TControls that are in the ownercontrol.Controls() array. The latter allows code to find ALL the children - visual only and TControl objects. From david at scootersoftware.com Mon Mar 8 21:33:35 2021 From: david at scootersoftware.com (David Jenkins) Date: Mon, 8 Mar 2021 14:33:35 -0600 Subject: [Lazarus] LCL and Lazarus Accessibility - restarting the discussion In-Reply-To: <51C84B86-08E7-4F7C-928B-55AC763E9BDE@marcozehe.de> References: <338087875.51341.1614938865972@office.mailbox.org> <51C84B86-08E7-4F7C-928B-55AC763E9BDE@marcozehe.de> Message-ID: <6a5160ef-da07-0812-084c-a5679f5eecca@scootersoftware.com> My accessiblity work for Cocoa/Qt5 has been submitted as a patch in bugtracker 38603 On 3/5/21 10:44 AM, Marco Zehe via lazarus wrote: > Hi David! > > Wow, that sounds exciting! Look forward to your patch. > > I did some digging, and found that on Windows, TTreeView does not create any handles at all yet. It would require at least some basics there, or even accessibility properties, but I am still hoping we can avoid what I had to do for TVirtualStringTree in 2007, implementing literally two IAccessible interfaces, one for tree, one for the focused tree item. That all was managed by a singleton class instance, and juggled quite a bit. Pretty unreliable, so I hope we can make it better in TTreeView for the LCL. > > Right now, however, I don’t even know where to start yet to implement this. There is a unit in the Win32 folder, but nothing in there besides the comments. And from what it sounds like, it makes sense to wait for your patch so I, or we, can then build on that and make the Windows implementations better. > > Marco > From mail at michael-ring.org Wed Mar 10 14:17:28 2021 From: mail at michael-ring.org (Michael Ring) Date: Wed, 10 Mar 2021 14:17:28 +0100 Subject: [Lazarus] Codetools and casing of unit files on Darwin Message-ID: <6681a375-87b9-aa01-1878-f20e474f50e7@michael-ring.org> I am having an issue with casing of included units and codetools, I searched through Mantis but did not find anything matching although I think this issue is too obvious for nobody besides me seeing it: I am on Lazarus Trunk (from yesterday or the day before), on a x86_64 Mac with Big Sur installed. I have a unit in uses: uses  UThisHasCamelCaseEverywhere; and the unit filename matches the written unit name. Codetools works fine... Then I change to: uses  uthishascamelcaseeverywhere; now codetools complains that unit cannot be found when I try to get context help via ctrl-Space. However, the code still compiles fine because default Darwin Filesystem (and/or) fpc does not care for upper/lower case in filenames on Darwin.... The main reason why this behaviour is quite annoying is that traditionally(??) filenames for embedded Units are lowercase and their definition in cpuinfo.pas is uppercase: from cpuinfo.pas: (controllertypestr:'STM32F100X4'; controllerunitstr:'STM32F10X_LD'; ls ~/devel/fpc/rtl/embedded/arm allwinner_a20.pp    cortexm3.pp        cortexm7.pp lpc11xx.pp        lpc21x4.pp        mk22f51212.pp raspi2.pp        stm32f10x_cl.pp        stm32f10x_md.pp stm32f411xe.pp        stm32f745.pp at91sam7x256.pp        cortexm3_start.inc    lm3fury.pp lpc122x.pp        lpc8xx.pp        mk64f12.pp        sam3x8e.pp     stm32f10x_conn.pp    stm32f10x_xl.pp        stm32f429.pp     stm32f746.pp cortexm0.pp        cortexm4.pp        lm3tempest.pp lpc13xx.pp        mk20d5.pp        nrf51.pp        sc32442b.pp     stm32f10x_hd.pp        stm32f401xx.pp        stm32f429xx.pp     stm32f756.pp cortexm0_start.inc    cortexm4f_start.inc    lm4f120.pp lpc1768.pp        mk20d7.pp        nrf52.pp        stm32f0xx.pp     stm32f10x_ld.pp        stm32f407xx.pp        stm32f446xx.pp     xmc4500.pp Did I overlook some FAQ or should I open an issue on Mantis? Michael From dhkblaszyk at gmail.com Wed Mar 10 16:48:48 2021 From: dhkblaszyk at gmail.com (Darius Blaszyk) Date: Wed, 10 Mar 2021 16:48:48 +0100 Subject: [Lazarus] Compile issue with Lazarus / FPC 3.2.0 64bit Message-ID: Hi all, I am trying to compile Lazarus (the GitHub mirror SVN rev51500) on windows 64bit with the following compiler Free Pascal Compiler version 3.2.0 [2020/07/07] for x86_64 I get the following error: make all D:\lazarus\components\lazutils\utf8process.pp(357,69) Error: (3285) Expected another 2 array elements utf8process.pp(664) Fatal: (10026) There were 1 errors compiling module, stopping Fatal: (1018) Compilation aborted I did expect that Lazarus would be out of the box compiling on FPC 3.2.0. Do I need to set some defines from the command line on 64bit? TIA! Rgds, Darius -------------- next part -------------- An HTML attachment was scrubbed... URL: From lazarus at mfriebe.de Wed Mar 10 17:19:17 2021 From: lazarus at mfriebe.de (Martin Frb) Date: Wed, 10 Mar 2021 17:19:17 +0100 Subject: [Lazarus] Compile issue with Lazarus / FPC 3.2.0 64bit In-Reply-To: References: Message-ID: <7e0b028a-55f1-624d-97f6-faa829e93c49@mfriebe.de> On 10/03/2021 16:48, Darius Blaszyk via lazarus wrote: > Hi all, > > I am trying to compile Lazarus (the GitHub mirror SVN rev51500) on > windows 64bit with the following compiler > Which mirror? 51500 is from 2016. > utf8process.pp(664) Fatal: (10026) There were 1 errors compiling > module, stopping Not looked at it, but it may be some   array [some_enum_defined_in_fpc] of .... If that enum has changed in fpc, then the old code no longer compiles. From dhkblaszyk at gmail.com Wed Mar 10 21:08:00 2021 From: dhkblaszyk at gmail.com (Darius Blaszyk) Date: Wed, 10 Mar 2021 21:08:00 +0100 Subject: [Lazarus] Compile issue with Lazarus / FPC 3.2.0 64bit In-Reply-To: <7e0b028a-55f1-624d-97f6-faa829e93c49@mfriebe.de> References: <7e0b028a-55f1-624d-97f6-faa829e93c49@mfriebe.de> Message-ID: duh... Indeed, the repository I have been using ( https://github.com/graemeg/lazarus) seems to be running behind for quite some years. I will use the official SVN repository instead. Thanks! Darius On Wed, Mar 10, 2021 at 5:19 PM Martin Frb via lazarus < lazarus at lists.lazarus-ide.org> wrote: > On 10/03/2021 16:48, Darius Blaszyk via lazarus wrote: > > Hi all, > > > > I am trying to compile Lazarus (the GitHub mirror SVN rev51500) on > > windows 64bit with the following compiler > > > > Which mirror? > 51500 is from 2016. > > > utf8process.pp(664) Fatal: (10026) There were 1 errors compiling > > module, stopping > > Not looked at it, but it may be some > array [some_enum_defined_in_fpc] of .... > > If that enum has changed in fpc, then the old code no longer compiles. > > -- > _______________________________________________ > lazarus mailing list > lazarus at lists.lazarus-ide.org > https://lists.lazarus-ide.org/listinfo/lazarus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lazarus at mfriebe.de Wed Mar 10 21:20:44 2021 From: lazarus at mfriebe.de (Martin Frb) Date: Wed, 10 Mar 2021 21:20:44 +0100 Subject: [Lazarus] Compile issue with Lazarus / FPC 3.2.0 64bit In-Reply-To: References: <7e0b028a-55f1-624d-97f6-faa829e93c49@mfriebe.de> Message-ID: On 10/03/2021 21:08, Darius Blaszyk wrote: > duh... Indeed, the repository I have been using > (https://github.com/graemeg/lazarus > ) seems to be running behind for > quite some years.  I will use the official SVN repository instead. > Just looked. The "upstream" branch seems to be up to date. There also is a 2nd mirror, but it is separately translated from svn, so it has different commit hashes. https://github.com/User4martin/lazarus/ From dhkblaszyk at gmail.com Thu Mar 11 14:29:57 2021 From: dhkblaszyk at gmail.com (Darius Blaszyk) Date: Thu, 11 Mar 2021 14:29:57 +0100 Subject: [Lazarus] Compile issue with Lazarus / FPC 3.2.0 64bit In-Reply-To: References: <7e0b028a-55f1-624d-97f6-faa829e93c49@mfriebe.de> Message-ID: It has just yesterday updated so it seems. Thanks for the support! Rgds, Darius On Wed, Mar 10, 2021 at 9:20 PM Martin Frb wrote: > On 10/03/2021 21:08, Darius Blaszyk wrote: > > duh... Indeed, the repository I have been using > > (https://github.com/graemeg/lazarus > > ) seems to be running behind for > > quite some years. I will use the official SVN repository instead. > > > > Just looked. The "upstream" branch seems to be up to date. > > There also is a 2nd mirror, but it is separately translated from svn, so > it has different commit hashes. > https://github.com/User4martin/lazarus/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bo.berglund at gmail.com Fri Mar 12 15:25:42 2021 From: bo.berglund at gmail.com (Bo Berglund) Date: Fri, 12 Mar 2021 15:25:42 +0100 Subject: [Lazarus] Lazarus loses environment, why does this happen? Message-ID: Lazarus 2.0.8 on Raspberry Pi 4 with FPC 3.0.4 I have discussed this topic here before but I would like to know what is causing the problem... It happened again today; when I started Lazarus I just got the main bar plus the code editor, all other windows were not there. Since I have been hit by this before I keep a backup of the pcp dir files in a tar archive so I could extract the environmentoptions.xml file from 2020-12-23 (with Lazarus closed of course) and replace the now bogus environmentoptions.xml in the pcp dir and all was OK again. Last time it happened I checked the environmentoptions.xml before fixing it and it was all blank, just a series of #0 chars. So what I am wondering now is what would cause Lazarus to write such a file anytime? It seems like normally Lazarus should just read the file unless a change is done in some options and then the write would be done at that specific time. But it seems like this file is not handled this way at all... Any ideas? -- Bo Berglund Developer in Sweden From nc-gaertnma at netcologne.de Fri Mar 12 15:34:00 2021 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Fri, 12 Mar 2021 15:34:00 +0100 Subject: [Lazarus] Lazarus loses environment, why does this happen? In-Reply-To: References: Message-ID: <20210312153400.2e187fa8@limapholos.matflo.wg> On Fri, 12 Mar 2021 15:25:42 +0100 Bo Berglund via lazarus wrote: > Lazarus 2.0.8 on Raspberry Pi 4 with FPC 3.0.4 > > I have discussed this topic here before but I would like to know what > is causing the problem... > It happened again today; when I started Lazarus I just got the main > bar plus the code editor, all other windows were not there. > > Since I have been hit by this before I keep a backup of the pcp dir > files in a tar archive so I could extract the environmentoptions.xml > file from 2020-12-23 (with Lazarus closed of course) and replace the > now bogus environmentoptions.xml in the pcp dir and all was OK again. > > Last time it happened I checked the environmentoptions.xml before > fixing it and it was all blank, just a series of #0 chars. I never saw that. Sounds like a buffer overflow, invalid pointer thing. You could compile the ide with -gh (heaptrc). > So what I am wondering now is what would cause Lazarus to write such > a file anytime? > It seems like normally Lazarus should just read the file unless a > change is done in some options and then the write would be done at > that specific time. It stores some desktop settings too. Mattias From nc-gaertnma at netcologne.de Fri Mar 12 15:35:55 2021 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Fri, 12 Mar 2021 15:35:55 +0100 Subject: [Lazarus] Codetools and casing of unit files on Darwin In-Reply-To: <6681a375-87b9-aa01-1878-f20e474f50e7@michael-ring.org> References: <6681a375-87b9-aa01-1878-f20e474f50e7@michael-ring.org> Message-ID: <20210312153555.78379632@limapholos.matflo.wg> On Wed, 10 Mar 2021 14:17:28 +0100 Michael Ring via lazarus wrote: > I am having an issue with casing of included units and codetools, I > searched through Mantis but did not find anything matching although I > think this issue is too obvious for nobody besides me seeing it: > > I am on Lazarus Trunk (from yesterday or the day before), on a x86_64 > Mac with Big Sur installed. > > > I have a unit in uses: > > > uses > >  UThisHasCamelCaseEverywhere; > > > and the unit filename matches the written unit name. > > > Codetools works fine... > > > Then I change to: > > uses > >  uthishascamelcaseeverywhere; > > > now codetools complains that unit cannot be found when I try to get > context help via ctrl-Space. > > > However, the code still compiles fine because default Darwin > Filesystem (and/or) fpc does not care for upper/lower case in > filenames on Darwin.... Please create a bug report. Mattias > > > The main reason why this behaviour is quite annoying is that > traditionally(??) filenames for embedded Units are lowercase and > their definition in cpuinfo.pas is uppercase: > > from cpuinfo.pas: > > (controllertypestr:'STM32F100X4'; controllerunitstr:'STM32F10X_LD'; > > > ls ~/devel/fpc/rtl/embedded/arm > allwinner_a20.pp    cortexm3.pp        cortexm7.pp lpc11xx.pp        > lpc21x4.pp        mk22f51212.pp raspi2.pp        stm32f10x_cl.pp > stm32f10x_md.pp stm32f411xe.pp        stm32f745.pp > at91sam7x256.pp        cortexm3_start.inc    lm3fury.pp lpc122x.pp    >     lpc8xx.pp        mk64f12.pp        sam3x8e.pp     > stm32f10x_conn.pp    stm32f10x_xl.pp        stm32f429.pp > stm32f746.pp cortexm0.pp        cortexm4.pp        lm3tempest.pp > lpc13xx.pp mk20d5.pp        nrf51.pp        sc32442b.pp > stm32f10x_hd.pp stm32f401xx.pp        stm32f429xx.pp     stm32f756.pp > cortexm0_start.inc    cortexm4f_start.inc    lm4f120.pp lpc1768.pp    >     mk20d7.pp        nrf52.pp        stm32f0xx.pp     > stm32f10x_ld.pp        stm32f407xx.pp        stm32f446xx.pp > xmc4500.pp > > > Did I overlook some FAQ or should I open an issue on Mantis? > > > Michael > > From fpc at pascalprogramming.org Fri Mar 12 16:39:08 2021 From: fpc at pascalprogramming.org (Marco van de Voort) Date: Fri, 12 Mar 2021 16:39:08 +0100 Subject: [Lazarus] Lazarus loses environment, why does this happen? In-Reply-To: <20210312153400.2e187fa8@limapholos.matflo.wg> References: <20210312153400.2e187fa8@limapholos.matflo.wg> Message-ID: <99a8dd2d-d3db-46a2-20b0-e81ae1c98d64@pascalprogramming.org> Op 2021-03-12 om 15:34 schreef Mattias Gaertner via lazarus: > blank, just a series of #0 chars. > I never saw that. Sounds like a buffer overflow, invalid pointer thing. I have an application in Delphi for which I use ported 2006 era Lazarus txmlconfig units. I still use them, since I implemented some quirk workarounds for the malformed xmls supplied by a customer. Over the years, I have seen this (zeroing in save) behaviour a few times, and it seems related to crashes during shutdown. From lazarus at mfriebe.de Sat Mar 13 21:55:34 2021 From: lazarus at mfriebe.de (Martin Frb) Date: Sat, 13 Mar 2021 21:55:34 +0100 Subject: [Lazarus] -dWINDOWS_LIGATURE [[Re: Font ligatures support]] In-Reply-To: References: <54009597.989770.1601610886473.ref@mail.yahoo.com> <54009597.989770.1601610886473@mail.yahoo.com> <466cbb2e-fadd-def8-205f-1e4feeed64f0@mfriebe.de> <2185897a-99fe-cf68-0dfa-3fa2bcf583f1@googlemail.com> <3bc622bc-89fc-6314-facb-3accc5739b53@ya.ru> <125995113.1541726.1601799288108@mail.yahoo.com> Message-ID: <48123b79-66ee-b4c2-5ae0-b4b8a50841db@mfriebe.de> On 04/10/2020 18:05, Martin Frb via lazarus wrote: > On 04/10/2020 10:14, Mr Bee wrote: >> If it does work, would you please submit it as a patch for the next >> release? At least, add a note that the font ligatures feature only >> supports monospaced fonts and only works on Windows. It's better than >> nothing. >> > revision 63951 > > Windows only, compile with -dWINDOWS_LIGATURE > Tested with Cascadia. Just as an update this breaks other scripts     dbg.Arguments := 'a b c ä ö 😁 X あｓｆ'; Using Deja vue mono, normally all chars are shown (maybe with windows build in font substitution). With the patch, the smiley and Japanese (including the 2 full-widths chars) are no longer shown. -------------- next part -------------- An HTML attachment was scrubbed... URL: From octopushole at gmail.com Mon Mar 15 19:01:10 2021 From: octopushole at gmail.com (duilio foschi) Date: Mon, 15 Mar 2021 19:01:10 +0100 Subject: [Lazarus] editor bug? In-Reply-To: References: Message-ID: Hi Martin, somebody fixed the bug. You will find a zip file at this link: https://mega.nz/file/T85iARDY#kK9i6JbM-aDJfRafL5PMN2MenSfxJoK4Yg9tnVwGsTo The zip file contains: 1. the corrected synedit.pp for Lazarus stable v. 2.0.12 2. the corrected synedit.pp for Lazarus trunk v. 2.1.0 3. the diff file for #1 4. the diff file for #2 I am not accustomed to version control software. Please feel free to use the attached fix in the way you like Thank you Duilio . On Sat, Feb 20, 2021 at 2:51 PM Martin Frb via lazarus < lazarus at lists.lazarus-ide.org> wrote: > On 20/02/2021 10:58, duilio foschi via lazarus wrote: > > I am using Lazarus v. 2.0.6 r. 62129 on windows 7/64 bits. > > > > I found an unexpected behaviours of the editor > > > > 1. I want to delete the text ":string" from the encircled column-sized > > frame > > you see here: > > > > https://i.ibb.co/V9ZPzSf/1.jpg > > > > The frame was selected using shift+alt+arrows keys. > > > > 2. when I click the ReplaceAll button also the text from the encircled > > button > > here > > > > https://i.ibb.co/dpFsjNq/2.jpg > > > > is deleted, what is unexpected. > > > > Isnt this a bug? > > > Yes it is. > > This is not currently implemented, so the Search/Replace should not > allow "in selection" > > You can report it (the unimplemented fearture) as a bug. But it will be > rather some time until that might get implemented (unless someone > contributes). > > ---------------- > There are some other options to archive what you need. > > Multi caret mode: (you can in Keymap config a key to have all carets > kept, when moving them in any direction) > https://wiki.lazarus.freepascal.org/New_IDE_features_since#Multi_Caret > > Maybe > https://wiki.lazarus.freepascal.org/New_IDE_features_since#Syncron-Edit > > And Editor Macros > record actions for one line, end with positioning one line down => then > play macro repeatedly. > -- > _______________________________________________ > lazarus mailing list > lazarus at lists.lazarus-ide.org > https://lists.lazarus-ide.org/listinfo/lazarus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lazarus at mfriebe.de Mon Mar 15 20:07:02 2021 From: lazarus at mfriebe.de (Martin Frb) Date: Mon, 15 Mar 2021 20:07:02 +0100 Subject: [Lazarus] editor bug? In-Reply-To: References: Message-ID: On 15/03/2021 19:01, duilio foschi via lazarus wrote: > Hi Martin, > > somebody fixed the bug. > > You will find a zip file at this link: > https://mega.nz/file/T85iARDY#kK9i6JbM-aDJfRafL5PMN2MenSfxJoK4Yg9tnVwGsTo > > > The zip file contains: > Thanks, I will have a look, asap. From octopushole at gmail.com Tue Mar 16 19:03:03 2021 From: octopushole at gmail.com (duilio foschi) Date: Tue, 16 Mar 2021 19:03:03 +0100 Subject: [Lazarus] I say a little prayer (for the Lazarus editor) In-Reply-To: References: <1ab8b340-6c65-7af4-d3a0-244e827e34d1@gmail.com> <7baf3e58-a5fb-951a-4e99-3a699ec39197@mfriebe.de> Message-ID: Hi Martin somebody fixed this point, too. See https://mega.nz/file/SkwVwIaS#qC1UeaSGy2kLwEQTSl57CPIYJZY34LYdMQQh7zb9ruY I am sending the unit synedit.pp fixed for both the stable and the trunk version. I can finally work in column mode as I was accustomed to do in Delphi :) HTH Duilio On Sun, Feb 21, 2021 at 5:22 PM Martin Frb via lazarus < lazarus at lists.lazarus-ide.org> wrote: > On 21/02/2021 16:53, Juha Manninen via lazarus wrote: > > On Sun, Feb 21, 2021 at 1:30 PM Martin Frb via lazarus < > lazarus at lists.lazarus-ide.org> wrote: > >> And one more thing, if you plan to submit a patch, please add an option >> to SynEdit.Options2 >> Many people are used to the current behaviour, I do not plan to upset >> them. >> > > This particular feature should not have an option IMO. > Now it can be considered a missing feature or even a bug. > When a user presses Alt-key when selecting, he clearly wants something > special to happen with Ctrl-C. > > > Well, if the user selects a column selection of a single line, then yes > (probably). > > But if the user selects column over several lines, then pasting already > acts different than it would for a normal selection. > (Select 3 full lines (start to end) using column selection => paste will > be different than the same 3 lines in normal selection) > > And users who grew up without the feature may not like it. > > Now nothing special happens which is a semi-bug. > I am sure everybody will be happy when this feature gets implemented. I > can remember many situations where it would have been useful. > > I don't have an example at hand, but I am sure I have more than a few > times made the experience that small, seemingly really useful changes got > someone coming up wanting the old behaviour back. > > > IMO there are too many options already. > > That is true, or rather they are badly organized. They need break down > into basic, and expert (like the mouse options have) > > If I accidentally change something during my tests, it takes a long time > to figure out what changed and how to revert it. > > Take a copy of your ___Options.xml files. > You can restore or diff them. > > Please add more options only when really needed. > > What I really would want to do, is include config in the keymap. > You could add new commands to the keymap. > > So you would assign ctrl-v to > paste(true) > or > paste(ColumnAdvanceLine) > ecPaste(ColumnAdvanceLine, IndentToContext, TabsToSpaces) > > They look like pascal script, but they would not require pascalscript. > (PascalScript does not work on all platforms, so it can not be used here) > They would always be a single command, with hardcoded options. > > This is like in some browser, you can do config in css, JavaScript or > similar. > > But that is a topic on its own. > > > -- > _______________________________________________ > lazarus mailing list > lazarus at lists.lazarus-ide.org > https://lists.lazarus-ide.org/listinfo/lazarus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lazarus at mfriebe.de Tue Mar 16 21:42:50 2021 From: lazarus at mfriebe.de (Martin Frb) Date: Tue, 16 Mar 2021 21:42:50 +0100 Subject: [Lazarus] editor bug? In-Reply-To: References: Message-ID: <2242b560-ebd3-7536-51c5-6d15b081ae1a@mfriebe.de> On 15/03/2021 19:01, duilio foschi via lazarus wrote: > > You will find a zip file at this link: > https://mega.nz/file/T85iARDY#kK9i6JbM-aDJfRafL5PMN2MenSfxJoK4Yg9tnVwGsTo > > > The zip file contains: > > 1. the corrected synedit.pp for Lazarus stable v. 2.0.12 > 2. the corrected synedit.pp for Lazarus trunk v. 2.1.0 > 3. the diff file for #1 > 4. the diff file for #2 > > I am not accustomed to version control software. > > Please feel free to use the attached fix in the way you like > First of all, thanks for the patch. Please only sent patches, the full files are not needed (and quickly outdated in case of trunk). Ideally go to https://bugs.freepascal.org/ register and submit your patch with a new issue. I can not always deal with patches immediately, and in my mail inbox they can get lost very quickly. Once you opened an issue, you can link to it, when you sent an email. Patches against trunk are the correct way. Other than getting trunk, there is no need to deal with svn or any revision management system. Besides the issues described below, your patch was very helpful, as it pointed me to the correct location for the fix. And it's review brought up more issues that need/needed fixing. ------------------------------------ About the patch itself. Both of the issues below, had been present before your patch. So they are not a result of your patch. I have fixed the first of the 2 issues, and committed this to trunk 2.1 ***1) If the text contains tabs, or special chars (such as umlauts äöü, accents, Japanese, Arabic, ....) then it can fail. X (in the search code) is a byte position into the string. It is not a position on the screen. https://wiki.lazarus.freepascal.org/SynEdit#Logical.2FPhysical_caret_position Consider those Lines:  . for spaces,  \t shall be a tab, with tab-width = 4 ........ab cd ef gh  // 8 spaces "cd" is at x=12 ääääööööab cd ef gh // 8 umlauts (each 2 bytes) "cd" is at x=20 \t\tab cd ef gh  // 2 tabs (same width as spaces) "cd" is at x=6 ........ab cd ef gh  // 8 spaces "cd" is at x=12 However, the "cd" on each line are aligned on the screen. So you can have a column selection, that in each line has "cd ef g" If in that column selection you replace "ef" with "EF", then your ptStartX=12 and ptEndX=19 => will replace nothing in the 2 middle lines. ***2) Further more, if the text to be replaced occurs twice on a line ........ab cd cd ef gh and "cd" is replaced by "CB and more", then the 2nd "cd" may get pushed out of the range, before being replaced. This is not yet fixed. According to me test this is "compatible" with Delphi 10.3 (I.e. it seems to be not working in Delphi too) From lazarus at mfriebe.de Tue Mar 16 21:59:59 2021 From: lazarus at mfriebe.de (Martin Frb) Date: Tue, 16 Mar 2021 21:59:59 +0100 Subject: [Lazarus] I say a little prayer (for the Lazarus editor) In-Reply-To: References: <1ab8b340-6c65-7af4-d3a0-244e827e34d1@gmail.com> <7baf3e58-a5fb-951a-4e99-3a699ec39197@mfriebe.de> Message-ID: On 16/03/2021 19:03, duilio foschi wrote: > Hi Martin > > somebody fixed this point, too. See > > https://mega.nz/file/SkwVwIaS#qC1UeaSGy2kLwEQTSl57CPIYJZY34LYdMQQh7zb9ruY > > > I am sending the unit synedit.pp fixed for both the stable and the > trunk version. > > I can finally work in column mode as I was accustomed to do in Delphi :) > Patch would be helpful (ideally at https://bugs.freepascal.org/my_view_page.php ) Your trunk is a bit older, and I get over 300 changed lines, when I compare. From octopushole at gmail.com Tue Mar 16 22:00:05 2021 From: octopushole at gmail.com (duilio foschi) Date: Tue, 16 Mar 2021 22:00:05 +0100 Subject: [Lazarus] editor bug? In-Reply-To: <2242b560-ebd3-7536-51c5-6d15b081ae1a@mfriebe.de> References: <2242b560-ebd3-7536-51c5-6d15b081ae1a@mfriebe.de> Message-ID: I have made the patches for myself. Please do what you like with them. Thank you Duilio. On Tue, Mar 16, 2021 at 9:42 PM Martin Frb via lazarus < lazarus at lists.lazarus-ide.org> wrote: > On 15/03/2021 19:01, duilio foschi via lazarus wrote: > > > > You will find a zip file at this link: > > > https://mega.nz/file/T85iARDY#kK9i6JbM-aDJfRafL5PMN2MenSfxJoK4Yg9tnVwGsTo > > < > https://mega.nz/file/T85iARDY#kK9i6JbM-aDJfRafL5PMN2MenSfxJoK4Yg9tnVwGsTo> > > > > The zip file contains: > > > > 1. the corrected synedit.pp for Lazarus stable v. 2.0.12 > > 2. the corrected synedit.pp for Lazarus trunk v. 2.1.0 > > 3. the diff file for #1 > > 4. the diff file for #2 > > > > I am not accustomed to version control software. > > > > Please feel free to use the attached fix in the way you like > > > First of all, thanks for the patch. > Please only sent patches, the full files are not needed (and quickly > outdated in case of trunk). > Ideally go to https://bugs.freepascal.org/ register and submit your > patch with a new issue. I can not always deal with patches immediately, > and in my mail inbox they can get lost very quickly. > Once you opened an issue, you can link to it, when you sent an email. > > > Patches against trunk are the correct way. > Other than getting trunk, there is no need to deal with svn or any > revision management system. > > Besides the issues described below, your patch was very helpful, as it > pointed me to the correct location for the fix. And it's review brought > up more issues that need/needed fixing. > > ------------------------------------ > About the patch itself. > > Both of the issues below, had been present before your patch. So they > are not a result of your patch. > I have fixed the first of the 2 issues, and committed this to trunk 2.1 > > > ***1) > If the text contains tabs, or special chars (such as umlauts äöü, > accents, Japanese, Arabic, ....) then it can fail. > > X (in the search code) is a byte position into the string. It is not a > position on the screen. > > https://wiki.lazarus.freepascal.org/SynEdit#Logical.2FPhysical_caret_position > > Consider those Lines: . for spaces, \t shall be a tab, with tab-width = 4 > > ........ab cd ef gh // 8 spaces "cd" is at x=12 > ääääööööab cd ef gh // 8 umlauts (each 2 bytes) "cd" is at x=20 > \t\tab cd ef gh // 2 tabs (same width as spaces) "cd" is at x=6 > ........ab cd ef gh // 8 spaces "cd" is at x=12 > > However, the "cd" on each line are aligned on the screen. So you can > have a column selection, that in each line has "cd ef g" > If in that column selection you replace "ef" with "EF", then your > ptStartX=12 and ptEndX=19 => will replace nothing in the 2 middle lines. > > > ***2) > Further more, if the text to be replaced occurs twice on a line > ........ab cd cd ef gh > and "cd" is replaced by "CB and more", then the 2nd "cd" may get pushed > out of the range, before being replaced. > > This is not yet fixed. > According to me test this is "compatible" with Delphi 10.3 > (I.e. it seems to be not working in Delphi too) > > > -- > _______________________________________________ > lazarus mailing list > lazarus at lists.lazarus-ide.org > https://lists.lazarus-ide.org/listinfo/lazarus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lazarus at mfriebe.de Tue Mar 16 22:03:03 2021 From: lazarus at mfriebe.de (Martin Frb) Date: Tue, 16 Mar 2021 22:03:03 +0100 Subject: [Lazarus] editor bug? In-Reply-To: References: <2242b560-ebd3-7536-51c5-6d15b081ae1a@mfriebe.de> Message-ID: <6099cdf2-a3e0-5261-88bf-65592bf75622@mfriebe.de> On 16/03/2021 22:00, duilio foschi via lazarus wrote: > I have made the patches for myself. > > Please do what you like with them. > > Well as I said, it helped me fixing your issue, and a 2nd related issue (and one issue identified, but still open) Here is what I did (and that will be in the 2.2 release): https://github.com/User4martin/lazarus/commit/932f4524db99025245f1eda7dc2e6868f81fc266 From juha.manninen62 at gmail.com Sun Mar 21 09:46:14 2021 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Sun, 21 Mar 2021 10:46:14 +0200 Subject: [Lazarus] Type used in function TListItem.GetState() Message-ID: Partly related to issue https://bugs.freepascal.org/view.php?id=38565 I changed function TListItem.GetState to use enum TListItemState directly instead of casting it to an integer. It allows to remove many ugly typecasts. I don't see any problems caused by it. None of the properties are published, thus component streaming is not a problem. However I don't know TListView very well, somebody may spot a potential problem. So, is it safe to apply? Please see the attached patch. Juha -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-State-index-TListItemState.patch Type: text/x-patch Size: 4872 bytes Desc: not available URL: From bo.berglund at gmail.com Sat Mar 27 10:15:55 2021 From: bo.berglund at gmail.com (Bo Berglund) Date: Sat, 27 Mar 2021 10:15:55 +0100 Subject: [Lazarus] Do I really need to use Build to get all recent changes included? Message-ID: <56tt5ghod3q8kbgqsvr4ens2b5422vdtph@4ax.com> I am using Lazarus 2.0.8 / Fpc 3.0.4 on a RaspberryPi4 I am writing a program intended to be run as a systemd service on Linux, so no GUI components. While debugging code on this I have noted a strange Lazarus behaviour: - Edit the source in order to for example add a debug log line - Use Run/Compile to get a new binary - Use strip -s to reduce the executable size - scp the executable to the target system (8400 km away) - Run the executable on the target system Now when I run a cycle on the target through the newly created binary the log line does *not* appear! So back to the dev system and use Run/Build instead Then repeat the strip-scp-run sequence And NOW the log line appears in the target system log! Question: --------- Should not Run/Compile create the binary based on *all* the latest sources? If I use Run/Build I am going to increment the build number all the time while debugging, which I would rather avoid. Is there some Lazarus setting I am unaware of, which will force Compile to actually compile based on all the modified sources since last compile? Or does Lazarus only consider changed files which are marked in the IDE as unsaved? If so then my use of AutoSave is the problem??? It saves changed sources every 5 seconds. -- Bo Berglund Developer in Sweden From nc-gaertnma at netcologne.de Sat Mar 27 10:29:29 2021 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Sat, 27 Mar 2021 10:29:29 +0100 Subject: [Lazarus] Do I really need to use Build to get all recent changes included? In-Reply-To: <56tt5ghod3q8kbgqsvr4ens2b5422vdtph@4ax.com> References: <56tt5ghod3q8kbgqsvr4ens2b5422vdtph@4ax.com> Message-ID: <20210327102929.5a89ac55@limapholos.matflo.wg> On Sat, 27 Mar 2021 10:15:55 +0100 Bo Berglund via lazarus wrote: >[...] > Question: > --------- > Should not Run/Compile create the binary based on *all* the latest > sources? If I use Run/Build I am going to increment the build number > all the time while debugging, which I would rather avoid. Maybe you modified a file of a package, that is not listed in the package? Lazarus only checks files listed in the package. > Is there some Lazarus setting I am unaware of, which will force > Compile to actually compile based on all the modified sources since > last compile? > > Or does Lazarus only consider changed files which are marked in the > IDE as unsaved? No. Mattias From bo.berglund at gmail.com Sat Mar 27 16:31:42 2021 From: bo.berglund at gmail.com (Bo Berglund) Date: Sat, 27 Mar 2021 16:31:42 +0100 Subject: [Lazarus] Do I really need to use Build to get all recent changes included? References: <56tt5ghod3q8kbgqsvr4ens2b5422vdtph@4ax.com> <20210327102929.5a89ac55@limapholos.matflo.wg> Message-ID: On Sat, 27 Mar 2021 10:29:29 +0100, Mattias Gaertner via lazarus wrote: >On Sat, 27 Mar 2021 10:15:55 +0100 >Bo Berglund via lazarus wrote: > >>[...] >> Question: >> --------- >> Should not Run/Compile create the binary based on *all* the latest >> sources? If I use Run/Build I am going to increment the build number >> all the time while debugging, which I would rather avoid. > >Maybe you modified a file of a package, that is not listed in the >package? Lazarus only checks files listed in the package. No, I added a better exit from a threaded function in my main code plus a log line right there. No logging appeared, that is why I started looking for the cause. After I used build and re-ran the test it worked as it should. -- Bo Berglund Developer in Sweden From lazarus at mfriebe.de Sun Mar 28 01:49:47 2021 From: lazarus at mfriebe.de (Martin Frb) Date: Sun, 28 Mar 2021 01:49:47 +0100 Subject: [Lazarus] Chromium Embedded for Lazarus / Cef4Delphi Message-ID: As part of a project by the Foundation, the Cef4Delphi project has been extended. - It now includes support for Cocoa. (Requires Lazarus trunk or patch to 2.0.12 / see wiki). - It has new Components that are easier to use (less code in the project units required) https://wiki.lazarus.freepascal.org/CEF4Delphi Downloads via the OPM need the "external version". From lazarus at mfriebe.de Sun Mar 28 03:03:06 2021 From: lazarus at mfriebe.de (Martin Frb) Date: Sun, 28 Mar 2021 03:03:06 +0200 Subject: [Lazarus] Testers for GDB Based debugger / Windows / Lazarus SVN Message-ID: Looking for testers for some updates to the GDB based debugger. Anyone using Lazarus SVN on Windows (64 or 32 bit) * Testing the current GDB  (includes users on all other OS - if gdb is used) - please update to rev 64877 or later Ensure all works as before. * Testing the **NEW** GDB - please update to rev 64877 or later - Download the new version of GDB (and cygwin1.dll) from   32Bit: https://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2032%20bits/Alternative%20GDB/GDB%209.2/   64Bit: https://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2064%20bits/Alternative%20GDB/GDB%209.2/ - Place GDB exe and cygwin1.dll in a new Folder. - Tools > Options > Debugger Backend   Choose the new gdb.exe What are the changes. The new version of GDB supports Unicode for - Environment (any existing, as well as any env-var set under "Run > Run Param" can now contain Unicode) - Command line arguments "Run > Run Param" - Hopefully the Path of the current dir, and the exe name (though the latter is limited by what FPC can generate) This does/should not affect inspecting variables, even if the contain Unicode. All else should work as before. Since the new gdb has a habit of showing directories as /cygdrive/c/path, the IDE now has code to correct that. Look out, if "/cygdrive/" is displayed anywhere by the debugger. Thanks