Re: [Lazarus] Project.pp
On Wed, Apr 10, 2024 at 3:42 AM Flávio Etrusco via lazarus < lazarus@lists.lazarus-ide.org> wrote: > delete the offending units from the uses clause then report back the > missing classes or functions. > Yes, I guess a project icon API should be added. > The LazIDEIntf unit doesn't exist anymore and has been refactored into > other units. > It does exist in IdeIntf. It is still a rather big unit. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] What happened to code templates?
On Wed, Feb 28, 2024 at 10:50 AM Martin Frb via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Just to be sure, did you directly edit the lazarus.dci inside the ide > folder in the lazarus install dir? > > Because then, it would have stopped working. > If you edit via the IDE, then the modified file is saved in your PCP. > > If the above is your issue copy the modified file to the PCP. > Renaming "lazarus_dci_file.dci" to "codetemplates.dci" should not affect a file named "lazarus.dci". I searched in my home dir if I have "lazarus.dci". It is found in a config dir for Lazarus 2.0. I don't remember creating such a file. How did it get there? I guess I don't know everything about the templates and their history. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] What happened to code templates?
On Tue, Feb 27, 2024 at 7:45 PM John Landmesser via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Now i have in lazarus.dci > > > [sm | showmessage] > > [todo | ToDo item creator] > .. and there is no way how i can use that?!! > First, "lazarus_dci_file.dci" was renamed to "codetemplates.dci". See https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40657. I guess this is not related to your issue. On Tue, Feb 27, 2024 at 8:15 PM John Landmesser via lazarus < lazarus@lists.lazarus-ide.org> wrote: > > Ok, i have to redefine my own code templates using the new Makro edit > box ?! > But why this change? I see no benefit. > A new Makro edit box? No, code templates are managed in Tools -> Code Templates ... There was another change. Templates in the Ctrl-J list are now sorted and work as expected always. https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40764 I admit I have not added much templates myself. I have used the existing ones. Maybe there is something in the common workflow that I don't know. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Need a good replacement for TMemo
OK, I found the reason. I had made experimental reordering in component palette pages. A new installed component does not go to a user modified page. After doing "Restore defaults" the RichMemo icon became visible. It means there is a bug in the palette config code. :( Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Need a good replacement for TMemo
On Thu, Feb 8, 2024 at 12:18 AM Werner Pamler via lazarus <
lazarus@lists.lazarus-ide.org> wrote:
> What "does not show up mean"? No icon on the component palette? In this
> case you probably missed to install the designtime package which is a bit
> hidden in the "ide" folder among all the interface folders.
>
Correct, there is no RichMemo icon on the component palette. Not found with
the component list either.
I installed the designtime package and saw the line
RegisterComponents('Common Controls', [TRichMemo]);
Maybe my earlier experiments screwed the system somehow. I will test more
later ...
Juha
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Need a good replacement for TMemo
On Wed, Feb 7, 2024 at 2:46 PM John Landmesser via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Please test RichMemo for Linux AND Windows! > > Long ago i tried to use RichMemo that worked for windows but not for linux! > I cloned the GitHub repo (https://github.com/skalogryz/richmemo) and installed RichMemo. Now the code compiles also with LCL-GTK2 but still the component does not show up. Tested only with Linux so far. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Need a good replacement for TMemo
On Wed, Feb 7, 2024 at 11:30 AM Werner Pamler via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Yes. But you should not use the version in the CCR repository. You > probably did not see the "readme.txt" which states that the ccr version is > no longer maintained, development has been moved to github: > https://github.com/skalogryz/richmemo. Or when you use the OPM version it > will be working, too. > Oops yes. Now I remember it was mentioned somewhere also earlier. I will test the GitHub / OPM version later. I agree that having the out-dated richmemo in CCR is misleading. There are > two options: I could delete that these files in OPM completely and keep > only the readme, or I could copy the current github files over them (but I > do not like the next step to become maintainer of the ccr version of > richmemo...). > I guess you mean delete from CCR. Yes please. Having such duplicates will always cause problems but won't bring any benefits. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Need a good replacement for TMemo
On Tue, Feb 6, 2024 at 11:31 PM Timothy Groves via lazarus <
lazarus@lists.lazarus-ide.org> wrote:
> ... and RichMemo won't work. (It will compile
> in, but then Lazarus crashes on startup with an Access Violation.)
>
I updated lazarus-ccr repo and tried to install the RichMemo_design
package. Lazarus does not crash but the RichMemo component does not show up
either. It should be in the 'Common Controls' palette page.
I tested with Lazarus trunk + LCL-GTK2 and LCL-QT5 widgetsets. For LCL-GTK2
I had to add {$define RMLCLTRUNK} in unit Gtk2RichMemo. It is used for
function GetWidgetInfo() which was last edited by Mark in 2010. Maybe an
IFDEF was needed for Lazarus trunk some 14 years ago but now the code
should be updated.
Does RichMemo installation work for somebody?
Juha
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus and Wayland display manager
On Sun, Dec 31, 2023 at 3:36 PM John Landmesser via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Is that still true ... ? > Wayland in general has strange issues?! > As LCL binds to widgetsets like QT5 and GTK3, it should depend on those widgetsets only. Lazarus IDE also uses LCL and its underlying widgetsets. I guess other QT5 and GTK3 apps work, thus the problem is in LCL binding code. They should be studied and fixed case by case. I don't think GTK2 should be used with Wayland. GTK2 was made before Wayland existed. Do distros that use Wayland by default still include GTK2 applications? BTW, the mail you copied is from me but I forgot the context. libXtst library dependency was removed from somewhere. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Proper procedure after changing files for an installed package?
On Mon, Dec 25, 2023 at 10:37 PM Bo Berglund via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Do I open Lazarus and use the function "Tools/Build Lazarus with Profile > Normal > IDE" or do I have to find the package below menu item "Packages" and > explicitly > command a Compile/Install? > Just rebuilding Lazarus is enough. Actually the "Install" in a Package window does the same thing. I believe that the file timestamps are not really reliable indicators of > the new > files... > Yes they are. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Running FPC in the browser...
How big is the difference in performance? I guess it is very big. Ten-fold maybe? You are right, for teaching programming this is a perfect tool. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] LazGitGui a git tool.
Same with logcache. I am in Git Lazarus source directory but it asks for a parameter. [juha@juha-fp30 lazarus]$ ../lazgitgui/logcache a file or directory of a git repository is needed [juha@juha-fp30 lazarus]$ These are standalone applications. An idea for future development : An IDE plugin that runs "git blame" for an active editor source file and shows a HashID for each line. The associated commit is shown in another window when the HashID is clicked. All that using a local Git repo history, no network access is needed. That kind of IDE integration would make sense. I never understood the traditional revision control plugins that allow commits from the IDE. What is the benefit? I have anyways saved and tested all my changes when I want to commit. I can as well start a proper commit tool from outside the IDE. There is no true integration, the IDE plugin is only started from a different place. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] LazGitGui a git tool.
I tested it. Quite nice! One issue: lazgitgui requires a filename as a cmd line parameter but does not use it. You should be able to run it without parameters just like "git gui". Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus trunk version number
On Friday, June 30, 2023, John Landmesser via lazarus < lazarus@lists.lazarus-ide.org> wrote: > perhaps that should have become 3.00 ? > > Lazarus *3.99* (rev main_3_99-41-g3d8dd85474) FPC 3.2.2 x86_64-linux-gtk2 > > You are looking at trunk, the development version. See : https://wiki.freepascal.org/Version_Numbering#Lazarus_3.0_and_newer Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Build Lazarus trunk clean
Please test again. Mattias generated the makefiles and saved me once again. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Build Lazarus trunk clean
On Sunday, June 11, 2023, John Landmesser via lazarus < lazarus@lists.lazarus-ide.org> wrote: > make all clean useride > > (3104) Compiling inputhistory.pas >> /home/john1/lazarus/components/ideintf/inputhistory.pas(46,3) Fatal: >> (10022) Can't find unit FileProcs used by InputHistory >> Fatal: (1018) Compilation aborted >> make[1]: *** [Makefile:3745: ideintf.ppu] Fehler 1 >> make[1]: Verzeichnis „/home/john1/lazarus/components/ideintf“ wird >> verlassen >> make: *** [Makefile:3870: lazbuild] Fehler 2 >> > > Whats the difference between these two methods? > Yes I screwed again with the makefiles. They are nasty. Hold on ... There are 2 build systems. Building from the IDE does not use makefiles at all. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Build Lazarus trunk clean
I did some refactoring in Lazarus sources. At least one file was moved and dependencies changed. It may require building clean to avoid "incompatible .ppu file" warnings and similar. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] LazMouseAndKeyInput + MacOS Cocoa
Mac owners please look at the patch here: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/38500 Does it make any sense? I created it based on a forum post attachment. I don't have a Mac myself. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Minor annoyance in IDE
On Sun, Jan 15, 2023 at 5:03 AM Don Ziesig via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Or might it just be the OS (Linux Mint XFCE)? > As Zeljko mentioned it is a window manager issue. Not OS. My KDE also has such a setting but I don't have it enabled. I hope you recovered from your health issues whatever they were. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus IDE 'testall' program
On Thu, Nov 24, 2022 at 3:00 PM Aruna Hewapathirane via lazarus < lazarus@lists.lazarus-ide.org> wrote: > On Thu, Nov 24, 2022 at 7:16 AM Martin Frb via lazarus < > lazarus@lists.lazarus-ide.org> wrote: > >> In the "main" branch the example folder was re-ordered. During this >> process the "testall" appears to have been removed. Not sure of the >> reasons... >> > > Oh-kay that explains why I was unable to find it and am sure the reasons > were all good and valid :-) > There may be a valid reason or there may be a mistake. Let's see. I committed to changes to example project management made by David Bannon. I did not notice the removal of "testall". I sent a message to David. We will figure it out. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Improved Editor Macro Viever
In 06352700aa7c I improved the GUI for managing editor macros, View -> Editor Macros ... Please test. Earlier in 7485ac827a the IDE toolbar button for macros got a dropdown list. The editor statusbar seems to have a button to stop recording a macro. It is not synchronized with the Editor Macros window buttons. Maybe the statusbar should also have a button to start recording. Things can be improved. Maybe I missed something important in the macro GUI rework, too. Comments? Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Trayicon popup menu no longer showing images
On Wed, Feb 16, 2022 at 4:49 PM Kostas Michalopoulos via lazarus < lazarus@lists.lazarus-ide.org> wrote: > From a quick look at the code there seems to be a way to force the > "traditional" backend by using LAZUSEAPPIND=NO environment variable, so > try to launch your program as > >$ LAZUSEAPPIND=NO ./yourprogram > > ...and see if that fixes it. If so then it might be a bug in the app > indicator backend or an issue with Cinnamon's app indicator > implementation (i remember reading it had some issues some time ago). > Yes, it is mentioned also here: https://wiki.lazarus.freepascal.org/How_to_use_a_TrayIcon I wish it worked always without any environment variables. However I understand David Bannon studied the issue a lot with many Linux distros and this was the best solution for all distros, new and old. I guess the problem will go away gradually when the new AppInd stuff spreads. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Treeview question
@Martin Collins, please see the issue: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39590 I guess Alexey started to implement TTreeNode.Enabled inspired by your post. I continued and I believe it is quite robust now. Please test. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Treeview question
TTreeNode.Enabled would be a useful addition. "Enabled" instead of "Disabled" for consistency with other components. There is TTreeNode.Visible. I believe much of its code logic could be copied and used for Enabled. Patches are welcome. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] UTF8LengthFast returning incorrect results on AARCH64 (MacOS)
On Tue, Dec 28, 2021 at 1:45 PM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > @Juha: can you please comment on my possible improvement using PopCnt > instead of a multiplication with ONEMASK. > I confess I didn't remember what PopCnt does. I checked from the net. FPC implements it as internproc. function PopCnt(Const AValue : QWord): QWord;[internproc:fpc_in_popcnt_x]; I guess it translates to one x86_64 instruction. Is it implemented for all CPUs? I found this: https://gitlab.com/freepascal.org/fpc/source/-/issues/38729 If it works everywhere, good. It looks like another good optimization for this highly optimized function. I will patch the function using unsigned types where applicable. > I will keep the loop variables unsigned though. > Yes, thank you. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] UTF8LengthFast returning incorrect results on AARCH64 (MacOS)
On Tue, Dec 28, 2021 at 3:29 AM Noel Duffy via lazarus < lazarus@lists.lazarus-ide.org> wrote: > So it appears to me that an unsigned pointer type is required in > UTFLengthFast. > Can you please create a patch for UTFLengthFast. You can upload it here or create a merge request in GitLab or anything. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] UTF8LengthFast returning incorrect results on AARCH64 (MacOS)
On Mon, Dec 27, 2021 at 1:44 AM Noel Duffy via lazarus < lazarus@lists.lazarus-ide.org> wrote: > I need some help getting to the root of a problem with incorrect results > on Apple hardware (M1, aarch64) for the function UTF8LengthFast in lazutf8. > > On MacOS, when given a string containing one or more UTF8 characters, > UTF8LengthFast returns wildly incorrect results. On Fedora, the function > returns the correct answer. > You mean both MacOS and Fedora run on the same aarch64 CPU? It must be a Big endian / Little endian issue. IIRC it can be adjusted in ARM CPUs. Why do MacOS and Linux use a different setting there? I have no idea. If somebody can figure out how to port the function, good. Otherwise we can make UTF8LengthFast call the standard UTF8Length using an IFDEF when needed. What is the correct define then? Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Source file license
On Wed, Dec 15, 2021 at 2:24 PM Martin Frb via lazarus < lazarus@lists.lazarus-ide.org> wrote: > It is also acceptable to have a "mixed license". E.g. >Licensed [L]GPL 2 [OR: "2 or later"] or MIT at the users choice. >Anyone using/modifying this code must keep at least either one of the > two Licenses, but is free to remove the other. > Yes, a dual license. I forgot to mention that. Lazarus sources include a fork of the Jedi Code Format package which has a dual license: Mozilla Public License v1.1 or GNU General Public License v2 Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] New Synthwave Demo
On Wed, Dec 1, 2021 at 2:04 AM Anthony Walter via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Did someone steal access to Juha's email? Not only are his ramblings > off-topic, but he sounds like a deluded conspiracy theorist bent on > disenfranchising rational people from using these mailing lists. > It is me myself. I am ready to explain both my theories and pure facts to anyone. Yes, cognitive dissonance is inevitable. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] New Synthwave Demo
Now people are dying because of the jabs. Those are not side-effects, the jabs work as intended. I am more and more convinced there is no SARS-CoV-2 virus. It has not been isolated from any patient during the 2 year "pandemic". Why? The only reliable measure of a pandemic is the total number of deaths compared to earlier years. There has been no increase in deaths in almost anywhere (*) so far. In this winter we will see an increase because of the jabs' effects ... and the new Omicron variant is blamed of course. It was all planned a long ago. How are the variants detected, anyone? Even the original virus has not been isolated and the PCR tests give mostly false positives. In a Marbug plandemic (or similar) symptoms will be imposed by the "booster-shots" and a new virus will be blamed. It will not be about a real virus then either. The agenda behind the plandemic is much worse than most people realize. Wake up please. This scam can be stopped only if enough people raise to oppose it. Don't put diapers on your face, don't consent to segregation passports etc. Juha (*) The few exceptions, Italy, Spain, some US cities, in early 2020 can be explained. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] New Synthwave Demo
On Tue, Nov 30, 2021 at 10:46 AM Alexey Tor. via lazarus < lazarus@lists.lazarus-ide.org> wrote: > This is damned country. > Russia was damned then. Now the western world, meaning North America, Australia and EU, follows the same steps. Dissidents and Christian people are persecuted. There is segregation with special "passports". The constitution is dumped and broken constantly by corrupt politicians. Production and delivery channels are sabotaged, finally leading to food shortage and chaos. Australia already has concentration camps where the army is moving people against their will, and there is genocide of their indigenous people. Europe is following step by step. See what happens in Austria. Germany has promised similar restrictions. Russia now has better freedom of speech than my country Finland. An example: A video platform TokenTube executes freedom of speech as our laws define it. It was censored and shut down from the internet without an explanation. It came back using servers in Russia or in China (not sure which). See, people in Finland must now rely on Russia or China for their freedom of speech. Our new VKK party and its resistance has drawn attention also in Australia. https://tokentube.net/v/1598697905/Australia-haastatteli-Ilkka-Tiaista Something must be done! The plandemic is used as an excuse. I hope everybody now understands it is a scam. A request for everybody: Do not take the jabs. If you took already, don't take more. It would be unfortunate if the small Pascal community got reduced by their effects. In a year or so a new plandemic will come, most likely Marburg. Things will get worse before they get better. Sorry for being out of topic on a Pascal programming list. I am happy to exchange more information in personal mails or by other means. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TFrame improvements
On Mon, Nov 29, 2021 at 11:14 PM Ondrej Pokorny via lazarus < lazarus@lists.lazarus-ide.org> wrote: > That is nonsense. I reverted your change. The code user code is just plain > wrong and your change in TFrame doesn't change anything about it. > > Try e.g. : > > procedure TForm1.Button1Click(Sender: TObject); > var > grid: TNewGrid; > begin > grid := TNewGrid.Create(Self); > grid.MyProperty := 1; // exception > end; > > Btw. Delphi behaves the same. > Of course your example code throws an exception because the grid has no Parent. Assign a Parent after creation and it works. Your example shows that you don't understand the issue at all! The problem was not the grid's parent but the Frame's parent. The grid's parent is requested, it is there, then its parent's parent is requested. The Frame has no Parent by definition at design time -> exception. My fix is 100% correct. Calling it nonsense and reverting it was not nice. Please restore it. You can fix the commit message at the same go. It must go to 2.2, too. One less bug in the release. There is one alternative solution. If you are right and the component behaves wrong, then an exception must be thrown when it is placed on a Form as well. Now the behavior is inconsistent and buggy. I personally don't see why component authors should be punished with such an exception. If the component does not work, it will be evident by other means. @Martin: > 2) Is it a bug in first? (and therefore is a fix needed): No. > No (at least if it is at runtime) it is not a bug, because it is by design that a frame needs a form as parent. Why you play dummy now? You know the problem happens at design time, not runtime. The exception happened only because the code required a Frame to have a Parent which BY DEFINITION it does not have at design time under the default designer. The correct fix is to NOT require a Frame to have a Parent, which I did in my commit. > 3) Before the patch, ignoring the design time issues => did it work at runtime? (And is it indented to?) Yes, at runtime it works on both a Form and a Frame. At design time it works on a Form but crashes on a Frame which is clearly a bug. Agree? I wrote about a hypothetical situation where a Frame stands alone at runtime. It obviously does not happen with the current TFrame. I meant that my fix is logically correct also if somebody derives a *SuperFrame* for whatever reason for extra capabilities. The frame's params would still be right then. Yes, the error message is confusing. "*NewGrid1.MyProperty: Control '' has no parent window*" while it actually came recursively from the Frame.Parent. Maybe it confused Ondrej's head. It confused mine initially, and Flávio Etrusco's (see his comment). Now that I understand the issue, my fix clearly was the right one. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TFrame improvements
On Mon, Nov 29, 2021 at 11:14 PM Ondrej Pokorny via lazarus < lazarus@lists.lazarus-ide.org> wrote: > On 29.11.2021 17:18, Juha Manninen via lazarus wrote: > > The commit message is not perfect but the committed code is, now that I > fully understand the issue. > > That is nonsense. I reverted your change. The code user code is just plain > wrong and your change in TFrame doesn't change anything about it. > No, the code is valid although not recommended. Accessing Canvas outside Paint works with some widgetsets and then an exception is wrong. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TFrame improvements
On Mon, Nov 29, 2021 at 6:47 PM Martin Frb via lazarus < lazarus@lists.lazarus-ide.org> wrote: > I suspect in the Designer it does not stand alone => The designer is the > parent. But I have not checked. > No, it has no parent. That is why it crashed. This is with the default IDE with floating windows. With the docked IDE it does have a parent. If it does not, then we have a new problem. > We now provide a canvas, and let the user believe they painted on it. But > its invisible. And if in order to make it visible, a parent is required, > then that means a new Handle. > So then we throw away the users work. (and the user will forever wonder > way his output is not drawn) > The same potential problem applies to TForm. They both behave equally well now in the designer. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TFrame improvements
On Mon, Nov 29, 2021 at 1:32 PM Ondrej Pokorny via lazarus < lazarus@lists.lazarus-ide.org> wrote: > There are many scenarios when the Canvas cannot be accessed and it is a > common mistake to access it when not allowed. > > I didn't study the issue further but to me it looks strange that setting > some parameters in CreateParams helps with it. Juha, your commit > description "Somehow fixes issue ..." doesn't help to understand your > change either. > The commit message is not perfect but the committed code is, now that I fully understand the issue. CreateParams for Frame now follows the same logic as CreateParams for Form. It allows a Frame to stand without a parent in the designer or even at runtime in some hypothetical situation(?). Using Canvas outside Paint may not be recommended but it can be done in some widgetsets. The component's duty is to not crash in designer or anywhere else when it happens. So I would encourage the component author to rewrite his code. > Rewrite? Ok, then TCustomForm must be rewritten, too. They now follow the same logic, at least regarding CreateParams(). Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TFrame improvements
On Mon, Nov 29, 2021 at 12:36 PM Michael Van Canneyt via lazarus < lazarus@lists.lazarus-ide.org> wrote: > > On Mon, 29 Nov 2021, Martin Frb via lazarus wrote: > > - The property accesses "canvas" => that triggers asking for a handle > > (which is created based on CreateParams) > Ah yes, Canvas. TStringGrid also uses Canvas a lot, but apparently not in a property setter. I often create a frame in code (so no parent) which is then placed on a > form. > Will this scenario still work ? > Yes, after my fix it still works. It is better *not* to add other artificial restrictions. They would bring no benefit as Martin noted. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] TFrame improvements
Please everybody test issue: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/25124 Some components caused an error when placed on a Frame. Now it apparently works. Can somebody please explain why it works. (See my comment there). There are also improvements for a custom Frame installed as a component in the palette. See: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39488 The improvements will be merged to 2.2. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] New install on Ubuntu 20.04.3 Cinnamon - Errors when recompiling IDE
A clean build usually solves such problems. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus on Linux, which desktop environment?
On Sun, Nov 21, 2021 at 1:06 PM Kostas Michalopoulos via lazarus < lazarus@lists.lazarus-ide.org> wrote: > On 11/21/21 11:45, Juha Manninen via lazarus wrote: > > LCL-QT5 works better than LCL-GTK2 now IMO. > > What are the issues on Gtk2 that are fixed in Qt5? > Different LCL bindings have their own bugs, and so do the underlying libraries GTK2, QT5 etc. LCL-QT5 and LCL-GTK2 both have bugs but LCL-QT5 has less of them. The underlying QT5 is also less buggy than the old GTK2. I agree with Michael. You need GTK2 development libraries initially when building Lazarus from sources with "make". LCL-QT5 bindings require the libQT5Pas (IIRC) which must be installed manually in some systems. Manjaro + KDE has it nicely as a dependency. Once you have them both installed you can freely select your favorite widgetset. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus on Linux, which desktop environment?
On Sun, Nov 21, 2021 at 10:33 AM Michael Van Canneyt via lazarus < lazarus@lists.lazarus-ide.org> wrote: > You can install KDE, but then installing Lazarus will most likely add the > GTK libraries as a dependency. > With KDE I recommend Lazarus with LCL-QT5 bindings. KDE itself is based on QT5. LCL-QT5 works better than LCL-GTK2 now IMO. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Drag/drop project and package filenames on the IDE
On Sun, Nov 14, 2021 at 2:52 AM Alexey Tor. via lazarus < lazarus@lists.lazarus-ide.org> wrote: > This must be tested with the patch: --pcp= parameter, which is used in > IDE shortcuts from fpcupdeluxe. What if different --pcp content is > passed (1st instance has another --pcp). > My commit only changed the way the parameters are interpreted. *.lpi is interpreted as a project always, *.lpk as a package. It does not affect the logic of how a single instance / multiple instances are opened. Do you see a problem in how it behaves? Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TextHint in TComboBox
On Mon, Nov 15, 2021 at 8:12 PM Marcos Douglas B. Santos via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Yes, I'll try to copy from 2.2RC. Thank you. > Why can't you use 2.2RC directly? It is very close to the final 2.2. Do you experience a regression bug there? Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Drag/drop project and package filenames on the IDE
On Sat, Nov 13, 2021 at 11:46 PM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Isn't the policy to not merge new features, but only bugfixes? > Yes but this one is clearly a bugfix. A project and a file name passed as cmd line parameters behaved differently depending on Lazarus being already running or not. When it was not running, all worked as expected. When a running Lazarus instance got those parameters, unexpected things happened. It turned out the same faulty code was used for drag'n'drop. It also behaved in an unexpected way. I am quite happy with the result. My only worry is that the change could cause regressions. Thus I ask people to test it. Fortunately most changes were refactoring. The moved code already worked elsewhere for the same purpose. No problems have come up in my tests. I will mark it for merging in a few days. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Drag/drop project and package filenames on the IDE
Regarding issue : https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39338 The issue is about passing project info .lpi files etc. through cmd line for a running Lazarus IDE instance. However the same code is used for drag/drop which makes it a bigger improvement than I thought initially. I would like to merge this to 2.2. Does anybody see potential problems? Please test. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus Release Candidate 2 of 2.2.0
On Tue, Nov 2, 2021 at 2:54 PM Mattias Gaertner via lazarus < lazarus@lists.lazarus-ide.org> wrote: > The Lazarus team is glad to announce the second release candidate of > Lazarus 2.2. > Mattias, this should be announced in the forum, too. There are many people who don't read the mailing list. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: the naming of ...
On Wed, Nov 3, 2021 at 12:27 AM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Whilst doing that I fiddled around with bot the tests and the masks unit. > I then wanted to commit (push) these changes seperately. > I got stuck. > In svn I could commit a single file, then another. > I git I don;t know how to do that. > A resolution by file for commits in arbitrary and limiting. Often changes for one feature or bug fix must spread to many files, and often changes made in one file should be split into many commits. "git gui" allows to include/exclude hunks and even single lines in/from a commit. I believe your GUI tool supports the same thing. My workflow currently is: > > make changes > git commit files I changed (solve one problem per commit) > git pull (I have pull.rebase=true) > git push > Make many commits. Some of them may be experimental, no problem. Finally go through them, fix errors, join commits together, remove commits purely for debugging, and finally push. If a feature gets longer to finish, keep it in a local branch and rebase to main sometimes. PS. The test suite runs fine again (but see my remarks on the > wqFilenameEnd quirk. > Here it gives an error from procedure TestWindows. I don't see commits from you in the TestMasks project. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: the naming of ...
I am away from my development computer now. Short comments about the git issues: I use "git gui" for commits. It shows untracked files in a separate pane which does not bother much. IIRC there is a setting to not show them at all. You can make many commits and push them sometime later. Actually you can modify, join and reorder them before pushing which is handy. Regards Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: the naming of ...
Bart, please run the TMask unit test project while you change the code. I fixed its compilation in 3c7586c0f8 but many tests fail. A unit test is especially useful with such text manipulation code. It is a good idea to run the tests after every change. Keep the test project open when changing. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Attn José: TWindowsMask oddity?
On Sun, Oct 31, 2021 at 6:16 PM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Why did you disable ranges and sets in the Windows implementation? > AFAIK it simulates the DOS/Windows command line behavior. José can answer more accurately. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: ConstructLegacy
On Thu, Oct 28, 2021 at 12:02 AM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Attached the codetools popup for TMask.Create constructor. > I would think it would be clear enough? > Ok, if you say so. :) It is clear for people who know the details already. For new users there is no hint of an extended syntax. Anyway, we can consider it as an advanced feature which requires users to study deeper. No problem. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: ConstructLegacy
On Wed, Oct 27, 2021 at 10:06 PM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > You totally lost me here. > IMHO there is no need for CreateExtende or similar new constructor. > Why not? THis is what we currently have. > > TMask: > constructor Create(const aMask: String; aCaseSensitive: Boolean; > aOpcodesAllowed: TMaskOpCodes); virtual; overload; > I understood you will change constructor Create() to support the backwards compatible syntax. Now there is CreateLegacy() to make it easy and intuitive to use. The same way a new CreateExtended() would make the new syntax easier to use. Such a constructor is handy and intuitive especially when code completion is used. A user sees alternative constructor names right away. A sign of an intuitive well designed API is that you can select methods and properties etc. with code completion by their names without referring much to documentation. At least you then get an idea of what to search from the documentation. These __are__ the extended constructors for aal the fancy new/extended > stuff. > They are called by all the other constructors that only have the old > parameters. > > So we have backwardscompatibility and extended capability just with > all constructors named simply Create. > The idea was only to offer an intuitive API which gives a hint there is something extended available, just like CreateLegacy() gave a hint there is the good old legacy syntax available. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: ConstructLegacy
On Wed, Oct 27, 2021 at 6:44 PM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > > The extended syntax would have another constructor. > > Not really sure what you mean by that. > There would be a constructor named CreateExtended or CreateAdvanced or similar, allowing the new nice syntax. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: ConstructLegacy
On Wed, Oct 27, 2021 at 2:50 PM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > The new masks unit has several CreateLegacy constructors (and some > *Legacy* functions). > They call the new constructros with mocEscapeChar disabled. > > Wouldn't is be a bit more logical to exclude mocEscapeChar form the > MaskOpCodesDefaultAllowed constant, since we'ld like to have the > default behaviour as compatible as possible? > That is fine with me. The Create constructors would then behave like CreateLegacy now. The extended syntax would have another constructor. I was pondering this same topic in an earlier post. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] New TMaskList [forked from: TMask revisited]
On Tue, Oct 26, 2021 at 8:24 PM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > However, now that we have a dedicated TMaskWindows, wouldn't it also > make more sense to have a TMaskListWindows class? > > The TMaskList constructors > constructor CreateWindows(const aValue: String; aSeparator: Char; > aOptions: TMaskOptions); > constructor CreateSysNative(const aValue: String; aSeparator: > Char; CaseSensitive: Boolean); > would not be necessary anymore. > Yes, sounds OK, but it cannot cover CreateSysNative which is now used in procedure TFileSearcher.Search. The IFDEF can be placed there directly of course. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Mon, Oct 25, 2021 at 7:20 PM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > As I see it now, we are planning to remove all the old TMask stuff (in > the future) and replace it with the new and improved TMask. > > Shouldn't that mean that we should also deprecate the CreateLegacy method? > That way we can remove all backwards compatibility stuff in 2.5/2.6. > And the same for the TMaskOption(s) type? (Although it stands to > reason that we remove this once we remove the methods that use those > as a paramater-type.) > I personally would like to keep the CreateLegacy constructor, or a similar one with another name. Users who are accustomed to the old syntax may find it useful. I leave it for you to decide. I was thinking hard if I should name the current CreateLegacy as Create and then have another constructor for the improved / extended syntax. That would be more backwards compatible. I am happy with both solutions. Fortunately the backwards compatibility issue is not serious because the vast majority of masks are simple *.txt or similar and they keep on working. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Sat, Oct 23, 2021 at 11:21 PM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > AFAICS the TMaskOpCode and TMaskOpcodesEnum types are not related at all. > TMaskOpCode is some kind of internal identifier in the internal mask > representation, whereas TMaskOpcodesEnum are options for interpreting > the mask. > > Q1: is it possible to have the TMaskOpCode as an internal type in the > class (maybe in the protected part of the class definition)? > It seems it is not needed outside (as in the public part of the interface). > > If we did not already have the old TMaskOption type, I would actually > have liked to propose to rename the TMaskOpcodesEnum into > TMaskOption... > In 964d5f4d69 I changed most names as you suggested. The original TMaskOpCode is now TMaskParsedCode because it is not related to the other enums directly. I did the changes before reading your last mail. I remember many enums actually are class internals in José's original code (in GitHub). I moved them outside to create the constants more easily. Maybe they can be moved back to a class. You can experiment with it. You can rename other stuff, too, if you like. I will not touch it for a while now. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Thu, Oct 21, 2021 at 11:30 AM José Mejuto via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Now you need to match a string that starts with a number and the second > char must be a letter, with a set it will be too large and unclear: > > "[0123456789][abcdefghijklmnopqrstuvwxyz]*" > With all Unicode characters included it would be even larger. :) Your code supports full Unicode also in the mask itself which is impressive. I would like to get opinions of the "Legacy" constructors and functions in the current code. They use constant MaskOpCodesNoEscape which makes the mask behave more close to the earlier mask implementation. For example : constructor TMaskUTF8.CreateLegacy(const aMask: String; aCaseSensitive: Boolean); and function MatchesMaskLegacy(const FileName, Mask: String; CaseSensitive: Boolean): Boolean; As the comment for MaskOpCodesNoEscape says: // Interpret [?] as literal question mark instead of 0..1 chars wildcard. // Disable backslash escaping characters like "\?". // Leave out eMaskOpcodeAnyCharOrNone and eMaskOpcodeEscapeChar The constructors and functions without "Legacy" allow backslash escaping and treat [?] as a wildcard. It can be seen as the default behavior because "Create" is the default constructor name by convention. It is also the default behavior in José's original code. I allowed it because the new syntax is an improvement. It is intuitive and more expressive. Now, should we emphasize backwards compatibility and use MaskOpCodesNoEscape by default? The new improved syntax would then have constructors and functions with different names, "Extended" maybe. How does Delphi do it? Should we be Delphi compatible here? Interestingly there are no standards for Mask syntax. They have evolved and diverted freely. Thus we cannot follow standards. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Tue, Oct 19, 2021 at 5:34 PM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > With only eMaskOpcodeOptionalChar enabled [a-z] would match 'a', '-' or > 'z'? > (This would be the old behaviour of TMask) > There is now a constant MaskOpCodesNoEscape which leaves out eMaskOpcodeAnyCharOrNone and eMaskOpcodeEscapeChar. It matches more or less with the old behavior and is used in the ...Legacy constructors and functions. The eMaskOpcodeOptionalChar enum name is not very self-explanatory, > maybe we should come up with another name (better now than in half a > year). > Suggestions? And maybe a constant that has all opcodes except the ones that enable > ranges. > There is MaskOpCodesDisableRange which leaves out eMaskOpcodeAnyCharOrNone, eMaskOpcodeRange and eMaskOpcodeOptionalChar. It is used in unit ShellCtrls. I forgot to answer this earlier : > The corresponding Create in TMaskBase is not deprecated: is that by design? The Create in TMaskBase is never called directly by a user. He will get a deprecated message from elsewhere. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Process differences
On Tue, Oct 19, 2021 at 7:58 AM Steve Gatenby via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Hoping someone could shed some light on why different results on the > following code :) > My guess is that a GTK2 session adjusts user and group rights somehow. When I run your command 'ps -eo pid:1,cpu:1,cgroup' in a console, I get many output lines. Very different from your output. I did not study what the parameters do exactly. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] TortoiseGit (was TMask revisited)
On Sat, Oct 16, 2021 at 3:27 PM Maxim Ganetsky via lazarus < lazarus@lists.lazarus-ide.org> wrote: > You can right-click on the revision entry (in the log) itself, and there > you will be able to open unified diff viewer. Also 'raw' diffs are not > very convenient to me, I prefer to inspect them in a separate viewer > (TortoiseGit has an excellent built-in one, and on Linux I use Meld). > Ok, I found the unified diff for the whole commit. Still requires clicking. Gitk shows it right away in a pane. Having the mouse cursor over it I can scroll with the wheel. No clicks needed. Keyboard Up/Down changes the selected commit. Revision graph is located at the left of the log window. You mean it? It > looks just like in any other tool? > It was in the main popup menu of the Explorer integration. You didn't try to cherry-pick, TortoiseGit has the best interface for > this in my experience. > Ok, can be. I have done "git cherry-pick c28cc988ec" or similar on a console. No problems so far. I still feel uncomfortable with external branch management and synchronization. I believe a GUI tool could help with that. My main development platform is Linux where TortoiseGit is not available. I may look at some other GUI tools later. However I remember even the console commands suggested the right syntax for me when I experimented with external branches. I just copied it and things worked. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Sun, Oct 17, 2021 at 1:10 AM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > I see you implemented the "old" constructors with the TMaskOptions > parameter and deprecated them as suggested. > Thanks for that. > Maybe add: 'Will be removed in 2.4' or similar to the deprecated message? > The corresponding Create in TMaskBase is not deprecated: is that by design? > Actually this will be published in 2.4 initially. After that the deprecated stuff can be removed. I added comments. Thanks also for implementing MaskOpCodesDisableRange > It needs to be apllied in the TShell* components, to presevere default > behaviour. > ShellCtrls.pas was updated already in the initial commit d7036bb0009 last wednesday. The method TMask.MatchesWindowsMask still is not implemented, so it > immediately causes compiler errors in my code. > This also needs to be implemented an deprecated IMHO. > Ok, yes. I implemented it in c28cc988ec. It requires a temporary TMaskUTF8Windows instance because the syntax is decided in creation. What does eMaskOpcodeOptionalChar do? > It's not very clear to me from the comments in the code. > Good question. It is the one syntax I don't fully understand yet. Below is an explanation from José himself. I will study this syntax later and add more unit test cases. --- eMaskOpcodeOptionalChar is the set "1[ab]2" matches "1a2" and "ab2" but not "1c2". --- I am not sure if it is correct. I will return to this later... Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
I turned the define RANGES_AUTOREVERSE into a run time option in 67111d9a30. A boolean RangeAutoReverse is True by default. I don't really know when somebody would want to turn it off. I also added constructors and functions for legacy syntax, which means [?] represents a literal '?' and characters cannot be escaped with '\'. constructor CreateLegacy() etc. That was the syntax used earlier but the default syntax now is improved. [?] is a wildcard and means 0 or 1 characters. Remember, '?' alone is 1 character. [??] means 0,1 or 2 chars. Useful and quite intuitive. Any character can be escaped with '\' now. For example literal '?' is \?, and literal '*' is \*. In the Windows mask syntax that is always disabled for obvious reasons. Question is, should the old legacy syntax be used when default constructors and functions are called? Like TMask.Create() etc. Then the improved syntax would be supported by constructors having different names. Mask syntax has no standards. They have evolved and diversified. How does Delphi's Mask work? A positive fact however is that some 99.5% of masks use simple '?' and '*' wildcards and continue to work in any case. The TMask syntax can be tweaked in many ways. A set TMaskOpcodesSet can be passed as a parameter to constructors / functions. I made constants MaskOpCodesDisableRange which treats all brackets [..] as literal characters and MaskOpCodesNoEscape which is the "legacy" syntax explained above. The Windows style mask can be tweaked with TWindowsQuirkSet. Ideas? Comments? Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Sat, Oct 16, 2021 at 12:23 AM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > > Yes, there should be an option for backwards compatible syntax, like > "[?]" . However the small changes in the syntax can be seen as improvements. > > There already is a define for converting "[z-a]" to "[a-z]". > > Why a define? > Shouldn't that better be configurable at runtime? > Yes, it should be a run time option. I will look at it. BTW, I forgot the details of "[?]" syntax. I will go through the old mails. >> José's code also catered for some odd DOS behaviour where a mask like > >> > >> 'file.txt?' actually matches with the filename 'file.txt' and a mask > >> 'file?.txt' would match 'file1234.txt' (but not 'file12345.txt'). > >> That would be rather counter-intuitive to most users. > >> I did not test (it was in one of the "quirks" settings) if it behaves > >> like this by default, but that should IMHO not be the case. > > I tested it now, and by default it returns fals for those cases. > Bart, can you please list cases where the Windows mask behavior differs from actual Windows cmd prompt behavior. Adding them to the unit test case would help, too. The case with Unit1.pas.bak syntax was fixed already. I did not study th enre code at length, but it looks quite a bit more > complicated to me than the old one. > Not sure if I will be able to contribute to it anymore. > It is not so bad. Debugging is difficult because pointer syntax is used, but I remember the old code was difficult to debug as well. There are 2 essential methods: procedure Compile and function Matches(). I refactored the procedure Compile a bit. Originally it was one big block of code. Juha P.S. Not related to the Mask code but I installed TortoiseGit on Windows. It works OK but still does not offer anything as good as *gitk*. The "Show log" view shows commits and their messages, and names of changed files but no diffs. Getting diffs requires extra mouse clicking for each file separately. Then there is "Revision graph" which is actually a branch graph. Not very useful. Earlier I have tried SmartGit but I didn't see any benefit using it either. "*git gui*", *gitk* + some git console commands work best for me. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Sat, Oct 16, 2021 at 11:20 AM Juha Manninen wrote: > Yes, the TMaskWindows indeed behaves wrong. '**.pas*' matches with ' > *abc.pas.bak*'. > Fixed in a111270ed0. Please test. No code changes were needed. I only disabled one of the Windows quirks, namely eWindowsQuirk_Extension3More. Please read the comments in code for details. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Fri, Oct 15, 2021 at 3:38 PM Maxim Ganetsky via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Please try with, for example bla.pas and bla.pas.bak files. > I got another mail from Maxim. It was also sent to this list but didn't appear. I also configured my Windows under Virtualbox for GitLab. Now I can test with Windows and I can reproduce the issue. Yes, the TMaskWindows indeed behaves wrong. '**.pas*' matches with ' *abc.pas.bak*'. Now I added a test revealing it. I keep studying the issue... Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Fri, Oct 15, 2021 at 3:38 PM Maxim Ganetsky via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Please try with, for example bla.pas and bla.pas.bak files. > I did basically that. I copied a .pas file to .pas.bak. Find in Files does not find extra entries with File mask "*.pas;*.pp;*.inc;*.lpr;*.lfm" With File mask "*.pas;*.pp;*.inc;*.lpr;*.lfm;*.bak" they are correctly found in the .bak file. Works as expected. Is the bug you experience caused by my recent unit Masks changes? Does it depend on OS / Platform? Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Fri, Oct 15, 2021 at 3:10 PM Sven Barth via lazarus <
lazarus@lists.lazarus-ide.org> wrote:
> Non-static class methods *do* have a Self parameter, but it's the class
> type and not the class instance. They can also be virtual, which is a
> really great feature of the Object Pascal language (I often miss that at
> work where I use C++). They are also assignment compatible to method
> variables ("of object").
>
> Static methods on the other hand don't have a Self parameter, can't be
> virtual and are assignment compatible to normal procedure variables.
>
Ok, right.
I confess I never used "static" with class procedures/functions. Thanks for
the info.
Juha
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
This may be a dummy question but what does "static" do for a class procedure? José's mask code has for example: class procedure Exception_IncompleteMask(); static; I thought class procedures are kind of static anyways, meaning they don't have a Self pointer. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
I restored the backwards compatible TMaskOptions in 04b0a04a45. Please test. When ranges (sets) are disabled, [] is interpreted as literal []. Works perfectly. Next I will study the little syntax differences. There should be a backwards compatible option for those, too. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Fri, Oct 15, 2021 at 2:54 AM Juha Manninen wrote: > Noticable the ability to NOT interpret [] as a set in the mask has now >> disappeared. >> > > How should a range / set [] be interpreted? > Ok, forget that question. I will study this more tomorrow. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Thu, Oct 14, 2021 at 7:57 PM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > You have changed the existing interface for both TMask and the > Matches(Windows)Mask(List) functions. > TMaskOptions has been removed. > It can be added for compatibility. Noticable the ability to NOT interpret [] as a set in the mask has now > disappeared. > How should a range / set [] be interpreted? This is not some cornercase: Suppose you have files that have > filenames like foo[1].dat, foo[2].dat etc. > Now you could specify a mask of 'foo[*].dat' with the moDisableSets > option set and it would find those files. > The new implementation won't. > (This was the usecase of the person who reported the bug for > TShellListView, which first was hacked by using [[] to mean a single > '[', but later was properly fixed by adding the TMaskOptions. > Now the same thing is done by passing MaskOpCodesDisableRange constant where type TMaskOpcodesSet parameter is used. TMaskOptions can be restored for compatibility. This was discussed at length in february. > > Now you're doing it all over again. > You have sacrificed consistent and reliable behaviour for gain of speed. > No Bart, that is not true. This is not *only* about speed. The old Mask was buggy and limited. Please run the test project testmasks.lpi. All current tests pass. Now checkout a revision before my Mask changes, eg. e5ed5082d and run tests again. Many errors. Notably there was no support for Unicode. Yes, there should be an option for backwards compatible syntax, like "[?]" . However the small changes in the syntax can be seen as improvements. There already is a define for converting "[z-a]" to "[a-z]". José's code also catered for some odd DOS behaviour where a mask like > 'file.txt?' actually matches with the filename 'file.txt' and a mask > 'file?.txt' would match 'file1234.txt' (but not 'file12345.txt'). > That would be rather counter-intuitive to most users. > I did not test (it was in one of the "quirks" settings) if it behaves > like this by default, but that should IMHO not be the case. > Yes it is counter-intuitive but it matches with Windows' behavior. You can test it on a DOS/Windows cmd prompt. That is why it is called TMaskWindows. The normal TMask behaves more logically. The "quirks" prove that Jose has tested it a lot. About the speed: TMask can also be used without disk file operations. Then the speed matters. Disk operations are typically slow, yes. I will look at the compatibility issues and possible bugs tomorrow. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Thu, Oct 14, 2021 at 12:53 AM Maxim Ganetsky via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Don't know if it is related but just noticed that `Find in files` dialog > now "ignores" file masks. > > E. g. I have the following file mask: `*.pas;*.pp;*.inc;*.lpr;*.lfm`, > but it also finds (existing) entries in *.bak files, which is not really > desired. > I cannot reproduce that. No matches in *.bak files here. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
On Wed, Oct 13, 2021 at 7:03 PM Marcus Sackrow via lazarus < lazarus@lists.lazarus-ide.org> wrote: > it breaks "make all" for x86_64-linux > LazBuild, yes. Again I forgot to test compiling it. Now it is fixed. Please test. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] TMask revisited
I restored the great TMask implementation by José Mejuto in our development branch. I also fixed a few issues that hindered the transition last time. It was discussed at least in this mailing list with title "unit Masks vs. unit FPMasks" in 23 February this year. The logic in ShellCtrls unit is retained as it was. MaskList is used only when there are many ';' separated masks. I found a way to disable ranges in the new TMask code. The syntax differs a little from the old one though. If the old TMaskOptions syntax is needed, it can be added as a compatibility layer. function TMaskList.MatchesWindowsMask() now works using a hack. It is deprecated for that reason. Tests to lazutils/test/testmasks.lpr were added for disabled ranges. Please test everybody. I will read the old posts more carefully later. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Possible bug in TFrame
On Thu, Aug 19, 2021 at 11:59 PM Marcos Douglas B. Santos via lazarus < lazarus@lists.lazarus-ide.org> wrote: > If I publish the full source of the component—which is not a big > deal—or send it to you in private, could you test it using the Demo > which exists already? > Yes, both ways are OK, although publishing the component is better. I am not the only developer here. Others may want to reproduce the bug, too. Open source you know. I suggest you study your component a little more. Strip out parts which have no effect on the bug. Finally you figure out the problematic part. It was not a TCollection, so it must be something else. Then you may be able to create a minimal example to reproduce the bug. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Possible bug in TFrame
Is there an example project without external packages or customdrawn widgetset? Customdrawn widgetset is incomplete and broken at least here in my Linux system. If not, then please upload such a project into one of the tickets. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] cannot compile git trunk from today
On Sat, Jul 31, 2021 at 11:09 PM John Landmesser via lazarus < lazarus@lists.lazarus-ide.org> wrote: > gtk2trayicon.inc(387,5) Error: Identifier not found > "gtk_status_icon_set_tooltip_text" > > What should i do? > Use the released FPC 3.2.2 or get the latest FPC trunk. Now you have an old trunk. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] The "Use" button in Component List
The list opens with Ctrl-Alt-P and is an alternative to the Component Palette. Is the "Use" button somehow useful? A component can be added by selecting it and clicking on designer, or by double-clicking it. The behavior was slightly changed in r64929, issue: https://bugs.freepascal.org/view.php?id=38706 Now the "Use" button inserts a component at coord(0,0) right away, which is the double-click behavior. Should the button be removed? Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Fwd: Registering a TFrame to component palette
It went to Sven Barth only, forwarding here. I clicked the reply button as always. I don't know what happened. -- Forwarded message - From: Juha Manninen Date: Sun, Jun 13, 2021 at 6:41 PM Subject: Re: [Lazarus] Registering a TFrame to component palette To: Sven Barth On Sun, Jun 13, 2021 at 2:50 PM Sven Barth wrote: > Yes, it does work this way. I don't know what you mean with "information > about sub-components". The VMT vFieldTable entry contains all published > fields of the class and thus all the sub controls that are visible through > the RTTI and thus for the designer. If the IDE does not use that yet, then > it definitly should. > Ok, through RTTI, yes. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Registering a TFrame to component palette
Regarding issue : https://bugs.freepascal.org/view.php?id=28450
The parameter passed to function RegisterComponents() is TComponentClass
which means "class of TComponent". It is only type information and does not
carry information about sub-components.
Could somebody please explain how it works in Delphi. Does this really work
:
RegisterComponents('Sample', [TMyFrame]);
I added a comment to the report but it is old and the reporter may not read
it.
Maybe there should be a new function RegisterFrame() or similar?
Regards
Juha
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] AutoSave does not save project file...
On Thu, Jun 10, 2021 at 4:48 PM Bo Berglund via lazarus < lazarus@lists.lazarus-ide.org> wrote: > I have never ever looked at stuff that integrate within Lazarus itself so I > could not fix it > Maybe it is time you look at such stuff. It may be an easy bug. A list of file endings missing .lpr maybe. DebugLn() lines are a good way to debug code which is part of the Lazarus IDE. This bug is not my "itch to scratch". Apparently it is yours. Please tell us what you find by debugging. Other people may get inspired to study the issue once you show you really tried to solve it. This is FOSS development, you know ... Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Type used in function TListItem.GetState()
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
From 2807655b1928a9caff738a357b63f3c07aba4077 Mon Sep 17 00:00:00 2001
From: Juha
Date: Sun, 21 Mar 2021 10:28:57 +0200
Subject: [PATCH] State index TListItemState.
---
lcl/comctrls.pp | 12 ++--
lcl/include/listitem.inc | 19 +++
2 files changed, 13 insertions(+), 18 deletions(-)
diff --git a/lcl/comctrls.pp b/lcl/comctrls.pp
index 8e3115455..f797e52a8 100644
--- a/lcl/comctrls.pp
+++ b/lcl/comctrls.pp
@@ -1014,7 +1014,7 @@ type
function GetLeft: Integer;
function GetListView: TCustomListView;
function GetPosition: TPoint;
-function GetState(const ALisOrd: Integer): Boolean;
+function GetState(AState: TListItemState): Boolean;
function GetImageIndex: TImageIndex; virtual;
function GetIndex: Integer; virtual;
function GetStateIndex: TImageIndex; virtual;
@@ -1029,7 +1029,7 @@ type
procedure WSUpdateState;
procedure SetChecked(AValue: Boolean);
-procedure SetState(const ALisOrd: Integer; const AIsSet: Boolean);
+procedure SetState(AState: TListItemState; AIsSet: Boolean);
procedure SetData(const AValue: Pointer);
procedure SetImageIndex(const AValue: TImageIndex); virtual;
procedure SetLeft(Value: Integer);
@@ -1058,17 +1058,17 @@ type
property Caption : String read GetCaption write SetCaption;
property Checked : Boolean read GetChecked write SetChecked;
-property Cut: Boolean index Ord(lisCut) read GetState write SetState;
+property Cut: Boolean index lisCut read GetState write SetState;
property Data: Pointer read FData write SetData;
-property DropTarget: Boolean index Ord(lisDropTarget) read GetState write SetState;
-property Focused: Boolean index Ord(lisFocused) read GetState write SetState;
+property DropTarget: Boolean index lisDropTarget read GetState write SetState;
+property Focused: Boolean index lisFocused read GetState write SetState;
property Index: Integer read GetIndex;
property ImageIndex: TImageIndex read GetImageIndex write SetImageIndex default -1;
property Left: Integer read GetLeft write SetLeft;
property ListView: TCustomListView read GetListView;
property Owner: TListItems read FOwner;
property Position: TPoint read GetPosition write SetPosition;
-property Selected: Boolean index Ord(lisSelected) read GetState write SetState;
+property Selected: Boolean index lisSelected read GetState write SetState;
property StateIndex: TImageIndex read GetStateIndex write SetStateIndex;
property SubItems: TStrings read GetSubItems write SetSubItems;
property SubItemImages[const AIndex: Integer]: Integer read GetSubItemImages write SetSubItemImages;
diff --git a/lcl/include/listitem.inc b/lcl/include/listitem.inc
index 0b003e7a3..0c7e058ee 100644
--- a/lcl/include/listitem.inc
+++ b/lcl/include/listitem.inc
@@ -542,12 +542,10 @@ end;
{--}
{ TListItem GetState }
{--}
-function TListItem.GetState(const ALisOrd: Integer): Boolean;
+function TListItem.GetState(AState: TListItemState): Boolean;
var
- AState: TListItemState;
LV: TCustomListView;
begin
- AState := TListItemState(ALisOrd);
LV := FOwner.FOwner;
if WSUpdateAllowed
@@ -562,7 +560,7 @@ begin
end;
{--}
-{ TListItem GetStates }
+{ TListItem GetStates}
{--}
function TListItem.GetStates: TListItemStates;
var
@@ -577,10 +575,10 @@ begin
else
begin
Result := [];
-if GetState(Ord(lisCut)) then ;
-if GetState(Ord(lisDropTarget)) then ;
-if GetState(Ord(lisSelected)) then ;
-if GetState(Ord(lisFocused)) then ;
+if GetState(lisCut) then ;
+if GetState(lisDropTarget) then ;
+if GetState(lisSelected) then ;
+if GetState(lisFocused) then ;
Result := FStates;
end;
end;
@@ -746,13 +744,10 @@ end;
{--}
{ TListItem SetState }
Re: [Lazarus] unit Masks vs. unit FPMasks
On Fri, Feb 26, 2021 at 10:24 PM Bart via lazarus <
lazarus@lists.lazarus-ide.org> wrote:
> On Fri, Feb 26, 2021 at 7:15 PM Bart wrote:
> My backup and some related programs still compile, but instatly raise
> an exception when they start to perform their main task.
> Thank you very much.
>
> The normal way of doing this is:
> Deprecate the function in question, but d NOT kill it's functionality.
> Add a useful deprecated message.
> Remove the function in the next major release (deprecate in 2.1, and
> so 2.2, only remove in 2.3, si't be gone in 2.4).
> Simply removing functionality like you have done now will alienate
> users from Lazarus, since apparently "we" cannot be trusted.
>
> Juha: you seem to be obsessed with speeding up string handling code.
> This is not really a problem as long as you are not deaf to arguments
> against your changes.
> You introduce new bugs, remove old features, all for the sake of speed.
> All that when, in my perception, this code is mostly used in
> conjunction with file IO, which is orders of magnitude slower than
> even slopy string handling.
>
True, it created more conflicts than I anticipated.
I reverted the new TMask in r64675. It must be worked later in trunk. Now a
2.2 fork will happen in few weeks.
Sorry for the hassle.
José and others. you can see my adaptation of your code in Lazarus trunk
just before the revert, eg. r64674.
I also attach the unit here.
I fixed the case-insensitive Unicode match by simply replacing LowerCase()
with UTF8LowerCase(). It is a well optimized function.
First I planned to use UTF8CompareLatinTextFast() but it did not fit here.
There is a unit test project in components/lazutils/test/.
The code passes all tests there!
Unicode is fully supported also in mask ranges.
Let's continue the integration later.
Regards,
Juha
{
*
This file is part of LazUtils.
See the file COPYING.modifiedLGPL.txt, included in this distribution,
for details about the license.
*
Match text using wildcards and sets.
Current version is from José Mejuto. When porting to LazUtils,
functions from LazUTF8 were used for full Unicode support.
}
unit Masks;
{$mode objfpc}{$H+}
// RANGES_AUTOREVERSE
// If reverse ranges if needed, so range "[z-a]" is interpreted as "[a-z]"
{$DEFINE RANGES_AUTOREVERSE}
{$DEFINE USE_INLINE}
interface
uses
Classes, SysUtils, Contnrs, LazUtilsStrConsts, LazUTF8;
type
{ EMaskError }
EMaskError=class(EConvertError)
public
type
TMaskExceptionCode=(eMaskException_InternalError,
eMaskException_InvalidCharMask,
eMaskException_MissingClose,
eMaskException_IncompleteMask,
eMaskException_InvalidEscapeChar,
eMaskException_InvalidUTF8Sequence
);
protected
cCode: TMaskExceptionCode;
public
constructor Create(const msg: string; aCode: TMaskExceptionCode);
constructor CreateFmt(const msg: string; args: array of const; aCode: TMaskExceptionCode);
property Code: TMaskExceptionCode read cCode;
end;
{ TMaskBase }
TMaskBase = class
private
procedure SetMaskEscapeChar(AValue: Char);
protected
type
// Literal = It must match
// Range = Match any char in the range
// Negate = Negate match in a group
// AnyChar = It matches any char, but one must match
// AnyCharOrNone = Matches one or none char (only in a group)
// AnyCharToNext = Matches any chars amount, if fail, restart in the
// next position up to finish the mask or the matched string
// OptionalChar = Optional char
// CharsGroupBegin = Begin optional chars or ranges "["
// CharsGroupEnd = End optional chars or ranges "]"
TMaskOpCode = (
Literal=0,
Range=1,
Negate=2,
AnyChar=3,
AnyCharOrNone=4,
AnyCharToNext=5,
OptionalChar=6,
CharsGroupBegin=10,
CharsGroupEnd=11
);
TMaskOpcodesEnum=(eMaskOpcodeAnyChar,
eMaskOpcodeAnyCharOrNone,
eMaskOpcodeAnyText,
eMaskOpcodeRange,
eMaskOpcodeOptionalChar,
eMaskOpcodeNegateGroup,
eMaskOpcodeEscapeChar);
TMaskOpcodesSet=set of TMaskOpcodesEnum;
TMaskFailCause = (
Success = 0,
MatchStringExhausted = 1,
MaskExhausted = 2,
MaskNotMatch = 3,
UnexpectedEnd = 4
);
(*
Windows mask works in a different mode than regular mask, it has too many
quirks and corner cases inherited from CP/M, then adapted to DOS (8.3) file
names and adapted again for long file names.
Anyth?ng.abc= "?" matches exactly 1
Re: [Lazarus] unit Masks vs. unit FPMasks
On Thu, Feb 25, 2021 at 12:44 PM José Mejuto via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Backwards compatibility, in special the escape character which can be > used in old masks like: "C:\*.*". The other functions can be kept > active, but escape char could be a compatibility problem. > Ok, true. Escaping special characters would be very handy. A pity. I kept the name TMaskUTF8 after all and inherited TMask from it. It helps synchronise changes between our versions, among other things. Now I need instructions or a piece of code into TMask constructor to make it ~ backwards compatible. Later we can see if the advanced features can be used. I will look at the case-insensitive match of Unicode next... Anyway, revisiting code I've found a bug in the escape character in char > groups, which simply are ignored. It has been fixed in UTF8 version, I'm > now porting to UTF16 and Ansi and I'll send you the updated version. > Also fixed the "[!]" mask to raise an exception and the > "RANGES_AUTOREVERSE" (was a variable rename from "cMask" to "lMask" > which was missed in the IFDEF). > I renamed "cMask" to "lMask" here. Earlier I made other changes. I renamed UTF8Length to UTF8CodepointSizeFast. LazUTF8 has that function for the purpose (and UTF8CodepointSize). Then I used the LazUTF8 version. UTF8Length in LazUTF8 means the number of codepoints in a whole string. I also changed PByte to PChar because of that function change. It seems to compile everywhere. An exception from "[!]" mask would be good, yes. It is clearly an error from a user. The current TMask also complains about it. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] unit Masks vs. unit FPMasks
On Thu, Feb 25, 2021 at 10:47 AM José Mejuto via lazarus < lazarus@lists.lazarus-ide.org> wrote: > In fact I think that the whole unit is needed. It has (info for other > readers) 3 classes TMaskUTF8, TMaskAnsi and TMaskUnicode, maybe > TMaskAnsi can be omitted but UTF8 and Unicode should be present. Many > times TMask is used over zillions of strings, converting Unicode to UTF8 > (for UnicodeStrings and WideStrings) is time consuming, much more than > the masking itself in most cases. > UTF8 is also Unicode, one of its encodings. The name UnicodeString is misleading. It should be UTF16String. Please remember our Unicode solution uses UTF-8. It is done by changing the default encoding of AnsiString and triggered by the same LazUTF8 unit that is used by Masks unit. Everything is UTF-8. I suggest to keep the 3 classes and create a new TMask one which mimic > the behaviour of current TMask, disabling the masking extensions (escape > char, [?],...) which is very simple as you only need to subclass the > Create method, mask compilation happens at first use time, not at > creation time. > I can include the TMaskUnicode class there if you want, although its name is also misleading. TMaskAnsi must be left out. It has no use with our Unicode solution. TMaskUTF8 I have renamed to TMask in my tests. It replaces the current TMask which supports Unicode only partially. I could make an alias type TMask = class(TMaskUTF8) but why should I? Basically every String in our Unicode system has UTF-8 encoding. No need to have a special mask class for UTF-8. This way current code using TMask will behave 99.9% identical, but an > user that needs to mask other strings can use TMaskUnicode, in example, > and activate or deactivate other extensions. > Where do the other strings come from? Anyway TMaskUnicode can be included, no problem. I am not sure we want a new TMask to behave 99.9% identical with the current one. The new one has some clear improvements. Interestingly there does not seem to be any standard for the mask syntax. So we cannot be compliant to any "standard". Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] unit Masks vs. unit FPMasks
On Wed, Feb 24, 2021 at 1:05 PM José Mejuto via lazarus <
lazarus@lists.lazarus-ide.org> wrote:
> Note: Just to put in context, my "explore" in the TMask world started
> when writing my NTFS filesystem reader, when all file names are read
> (400,000) I can search for them using masks. When compiled in fpc
> (Lazarus) the "*.txx" search takes 1-2 seconds (not measured) and when
> compiled with Delphi it takes +/- 0.3 seconds, so I stated to write my
> own TMask.
>
I am interested in how well your TMask version compares with Delphi's
version.
Does it match the speed or even surpass it?
Anyway this unit looks very promising!
It works with Unicode as advertised. It passes all cases in the updated
unit test. Our current implementation fails miserably.
See components/lazutils/test/testmasks.lpi
For example this
TestMask('ö', '[!☺-☂]', True);
means that 'ö' is not between a happy face and an umbrella.
Case-insensitive matching of Unicode can be fixed later with functions
found in LazUTF8.
With José's approval the license will be LGPL with a linking exception. It
will be part of the LazUtils package. Author's name will be mentioned of
course.
Is that OK?
I will not copy the whole original unit but use the UTF-8 parts + rename
and tweak some things.
Regards
Juha
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] unit Masks vs. unit FPMasks
MaskList is used in TCustomShellTreeView.GetFilesInDir().
It sets a mask option *moDisableSets*. Why are sets disabled? Is it to stay
compatible with FindFirstUTF8() syntax?
I don't fully understand the comment. Why would EConvertError be raised?
//Disable the use of sets in the masklist.
//this behaviour would be incompatible with the situation if no
MaskList was used
//and it would break backwards compatibilty and could raise
unexpected EConvertError where it did not in the past.
//If you need sets in the MaskList, use the OnAddItem event for that.
(BB)
MaskOptions := [moDisableSets];
{$ifdef NotLiteralFilenames}
if (ACaseSensitivity = mcsCaseSensitive) then
MaskOptions := [moDisableSets, moCaseSensitive];
{$else}
if (ACaseSensitivity <> mcsCaseInsensitive) then
MaskOptions := [moDisableSets, moCaseSensitive];
{$endif}
MaskList := TMaskList.Create(MaskStr, ';', MaskOptions); //False by
default
Anyway I don't see why a useful Mask syntax should be disabled. Can this be
solved by other means?
Can José's mask do a similar thing?
Juha
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] unit Masks vs. unit FPMasks
On Wed, Feb 24, 2021 at 12:22 PM José Mejuto via lazarus < lazarus@lists.lazarus-ide.org> wrote: > In my code there is non 100% unicode compatibility when using the > "CaseInsensitive" mode as as it uses lowercase mask and lowercase string > to perform the test which is wrong by definition but I was unable to > find a method to test codepoints case insensitive without pulling in big > unicode tables. > > I was thinking in import the NTFS (the filesystem) case comparison > tables which are 128 KB "only". > That is not necessary. LazUTF8 has functions like UTF8CompareText(), UTF8CompareTextP() and the latest UTF8CompareLatinTextFast(). UTF8CompareLatinTextFast supports full Unicode but is optimized for mostly Latin text. We should add a PChar version UTF8CompareLatinTextFastP() and use it in your mask code. > Comprehensive unit tests are a way to prevent breaking things. > > And also define if a compatibility break is a bug in the new code or in > the old code. In example my mask supports (there is a define to disable) > "[z-a]" converting it to "[a-z]" which is a compatibility break. Your code does not compile when RANGES_AUTOREVERSE is not defined. cMask is not found. The reverse logic can be enabled by default. It does not break anybody's masks as I understand it. Earlier it was an error, now it does something sensible. Also there is the support (also can be disabled) for the mask "[?]" > which is the counterpart for "*" but with one char position. > Where did you get this "[?]" syntax? There must be a reference documentation somewhere but I have not seen it. What is the difference between "?" and "[?]" ? On Wed, Feb 24, 2021 at 1:28 PM José Mejuto via lazarus < lazarus@lists.lazarus-ide.org> wrote: > > Sometimes I wish we would migrate to using UnicodeString by default. > > It would make life a bit easier. > > (And yes I know you would have to deal with composed characters > > (grapheme defined by more than 1 16-bit word)). > > That's a can of worms! UTF8 forces you to write "correct code" (at least > try it) for any character >127, with UnicodeString you get the false > apparence that everything magically works until everything cracks when a > string with surrogate pairs come in play :-) and ALL you text handling > must be rewritten, and most of them completly rewritten. > Exactly. UnicodeString uses UTF-16 which is also a variable length encoding. The same rules should be applied but often they are not. There is plenty of sloppy UTF-16 code out there. Writing proper code UTF-8 is not difficult once you wrap your mind around the concept. There is a learning curve, true. I also scratched my head for some time when studying it. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] unit Masks vs. unit FPMasks
On Wed, Feb 24, 2021 at 1:00 PM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > > > There are no tests for MatchesWindowsMask() yet. > I tested that extensively on my machine with all scenarios I could think > of. > Please add your tests to the project I mentioned. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] unit Masks vs. unit FPMasks
I will not touch MaskEdit. Don't worry. On Wed, Feb 24, 2021 at 11:03 AM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Without a major rewrite (which increases the cange of breaking > compatibility). > José Mejuto's code is a major rewrite for Masks. It supports Unicode in masks, too. I try to make it compatible by changing some class and method names, and then run the unit tests. Comprehensive unit tests are a way to prevent breaking things. Please everybody provide more test cases. The project is in components/lazutils/test. There are no tests for MatchesWindowsMask() yet. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] unit Masks vs. unit FPMasks
On Wed, Feb 24, 2021 at 12:08 AM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > TMask (unit masks) deals with masks with wildcards (*,? and sets of > single byte chars). > It is mainly used for matching filenames (similar to the Path supplied > to FindFirst). > > TMaskEdit gives you the possibility to constrain user input to almost > anything you like, > Can be used for e.g. ZIP codes, only numbers etc. > TMask also supports ranges and sets. See the unit test. Eg. '[a-b]', '[!a-b]', '[abc]', '[0-9]' Now I found documentation for TCustomMaskEdit.EditMask. It explains the syntax and it looks like the MaskUtils syntax. It was documented, good! I missed it earlier. I know filename wildcards and I know regular expressions. Now learning this Mask thingy... As you have pointed out before, the GetCodePoint function in the Masks > unit needs overhoaling. > It is much worse than that! Yes, GetCodePoint does its own nested loops and useless copies. But then it and other UTF8...() functions are called inside a loop, effectively causing many nested loops. The scalability is maybe O(n^3) or O(n^4). José Mejuto's Mask unit looks promising. He mentioned in a private mail (which should be public IMO, no deep secrets there) that a pattern * "*something*to*write*here*""which with current mask it takes a lot of time to be processed. If matchable string is of more than 200 chars long it could take seconds to be resolved. My classes are typically O(n)."* Many seconds in a modern computer is a lot. (It is the same as in TMaskEdit, but that only reacts to user input > with strings <=255 chars, so speed is not required there: I'ld love to > see someone typing faster that the code in TMaskEdit calculates what > needs to be done.) > True, but the code should be cleaned anyway and maybe reuse some other code. Code has aesthetic values, too. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] unit Masks vs. unit FPMasks
On Tue, Feb 23, 2021 at 7:38 PM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > I have copied in the past some of the TMaskEdit logic and methods to > the MaskUtils unit. > Ok, the TEditMask thing was in MaskUtils. I didn't pay attention. How about TMask? Does it have the same syntax as TMaskEdit or are they different? Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] unit Masks vs. unit FPMasks
On Tue, Feb 23, 2021 at 2:54 PM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > MaskEdit is a LCL control and hence has nothing to do in fpc. > I am not suggesting to move MaskEdit to FPC libs obviously. I have in the past copied bits of TMaskEdit to a related fpc unit > (cannot remeber exactly which), so that they work the same (setting > and removing masks IIRC), with the exception that TMaskEdit does this > on UTF-8, while the fpc unit assumes 1-byte ANSI encoding (so it won't > work on UTF-8). > Given the release cycle of fpc, I would strongly advise to have this > code on "our side" (Lazarus), so bugs can be eliminated much faster. > > The Masks unit is not related to TMaskEdit. > Does it mean the mask syntax is different? I found this: http://docwiki.embarcadero.com/Libraries/Sydney/en/System.MaskUtils.TEditMask Is TEditMask the same as TMaskEdit? Or is TEditMask used for TMask? Can you please explain it so that I understand? Is it all documented somewhere? For the Masks unit: the same UTF-8 problems exist with it's fpc > counterpart IIRC (did not study the code recently). > So, I would like to keep it "here" as well. > Yes, I realized it must stay in LazUtils. Iterating codepoints is needed. FPMasks is good for ASCII only despite having UTF8String type. Does Michael have a plan for that unit? Fortunately I found a unit test for Masks unit under LCL tests directory. I moved it under LazUtils in r64653. I will add tests for multibyte codepoint text. Then optimizing TMask will be safe. Nothing can go wrong... :) Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] unit Masks vs. unit FPMasks
On Tue, Feb 23, 2021 at 12:56 PM Juha Manninen wrote: > Oops, now I understand that FPMasks does not really support Unicode. > Type UTF8String only converts encoding automatically when assigning values. > There is no code to identify codepoints. > The LazUtils Masks iterates codepoints, although in a very slow way. > Has anybody tested FPMasks with multibyte-codepoints? I guess it may not > work correctly. > I am not sure if iterating multibyte codepoints is even necessary. I must create a unit test. Does anybody have a list of use cases or some example code? The Embarcadero documentation is very plain. It is difficult to find comprehensive examples. I must confess I have not used TMask or TMaskList myself. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] unit Masks vs. unit FPMasks
A related thing. I am confused with different mask classes. Embarcadero docs for TMask http://docwiki.embarcadero.com/Libraries/Sydney/en/System.Masks.TMask says: "*Note:* Do not confuse TMask with the EditMask of a field or masked edit object. While both are used for comparing strings to a symbolic description of valid values, the special mask symbols and matching rules are completely different." Is the "*masked edit object*" the same as MaskEdit? Is the syntax really different? Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] unit Masks vs. unit FPMasks
Hello LazUtils has unit Masks with classes TMask and TMaskList. FPC's packages/fpindexer has unit FPMasks also with classes TMask and TMaskList. A comment in FPMasks says "Moved here from LCL". Revision control shows it was added 9 years ago in 2012. Since 2.5 years ago it supports Unicode by using UTF8string for all strings. LCL has a related MaskEdit. It was first added in 2002 by Mattias with comment "added TMaskEdit from Tony" I don't know who Tony is. Unit Masks was first added to LCL in 2007 by tombo with comment "LCL: implemented TMask, MatchesMask, added Masks docs" I don't know who Tombo is either. In 2011 Masks was moved to LazUtils by Felipe. Masks and MaskEdit have some identical code. IMO MaskEdit should reuse some code from Masks. MaskEdit is maintained by Bart but he didn't know details of the history. Masks in LazUtils has a slow implementation. I planned to optimize it but now I realize we may have overlapping code. Q: Are Masks (LazUtils) and FPMasks (fpindexer) compatible? If they are, we should dump the LazUtils Masks and use code from FPC's libs. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] LHelp and LazMouseAndKeyInput package
On Mon, Feb 22, 2021 at 10:52 AM Juha Manninen wrote: > The libXtst library dependency pulled in for Linux (and UNIX) was a > 100% increase of system dependencies for a Lazarus release, and for > absolutely no benefit. > Now Lazarus BigIde depends on just libgtk2.0-dev. > Ok, that was not accurate. Many other system libraries are pulled in by libgtk2.0-dev. However in a distro package system level it is the only requirement. Adding dependency for X brings another problem: Lazarus would not work with Wayland display server. Now it works if the widgetset supports Wayland. Major widgetsets like GTK3 and QT5 do support it. Not sure about GTK2. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] LHelp and LazMouseAndKeyInput package
On Mon, Feb 22, 2021 at 3:29 AM Andrey Sobol via lazarus <
lazarus@lists.lazarus-ide.org> wrote:
> You excluded this code from lcore.pas
>
> procedure THelpForm.ShowApp();
> ..
> {$IFDEF WINDOWS}
> // Go to TOC TreeView and to get focus on foreground window
> KeyInput.Apply([ssCtrl]);
> KeyInput.Press(VK_T);
> KeyInput.UnApply([ssCtrl]);
> {$ENDIF}
>
Oh, LazMouseAndKeyInput was just for that code.
It created a serious bug. After pressing F1 in source editor the end of
current word was cut off.
The reason was that VK_T went to Lazarus IDE, although LHelp sent it to
itself, and the default command for VK_T is "Delete to end of word".
Didn't you notice the bug?
It was discussed in Lazarus devel mailing list. It should have happened
here instead.
Something funny happens in the interprocess communication. How could key
VK_T bring LHelp to front if it went to Lazarus' source editor?
> Without the code on windows system we can`t get rightly a focus lHelp
> by an event of restore the window after hide (the window is blinking on
> an aplication panel sometimes). We should send an user input sentence to
> the foregroud window from a mouse or from keyboard to get focus (that is
> windows specific problem).
>
Yes, in Windows terminology bringing to front means blinking an icon in
Taskbar.
A Lazarus user however wants to see the help window right after pressing F1.
I see some solutions of that:
> 1. To rewrite that code by WinApi (that is simple).
> 2. To exclude the package dependency on Mac system, but I don`t know how?
>
LazMouseAndKeyInput must be fixed for MacOS Cocoa but that is a whole
different issue.
Now that problem involves only Windows. A cross-platform package is not
needed for that.
The libXtst library dependency pulled in for Linux (and UNIX) was a
100% increase of system dependencies for a Lazarus release, and for
absolutely no benefit.
Now Lazarus BigIde depends on just libgtk2.0-dev.
3. To fix the Application.BringToFront() function at windows to rightly
> bring a foreground window to a front of a display.
>
That was my idea, too.
The method name BringToFront() is quite unambiguous. It should bring the
application to front. :)
The name is not BlinkAnIconInTaskbar().
If you know how to fix it, please do. I don't use Windows much myself. Does
this idea go against some Windows convention?
But I don`t see that problem now :). May be the blinkg was also a part
> of that issue https://bugs.freepascal.org/view.php?id=38276
>
> I redone many pieces after that, that a second round :)
>
I removed the LazMouseAndKeyInput dependency in r64647.
Please fix the remaining issues as you see fit (without libXtst dependency
for Linux).
Regards,
Juha
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] LHelp and LazMouseAndKeyInput package
Help has improved lately thanks to Andrey Sobol's patches mostly. However a new dependency was added: LazMouseAndKeyInput. On Linux and UNIX systems it pulls in libXtst dependency. LHelp is part of Lazarus BigIde target which is used for releases. Extra dependencies for BigIde should be avoided if possible. Now I studied how LazMouseAndKeyInput is used in LHelp. Well, it is not used! LHelpCore has MouseAndkeyInput in its uses section but removing it and the whole package dependency makes no difference. My analysis: LazMouseAndKeyInput dependency can be removed from LHelp. Am I right? Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] I say a little prayer (for the Lazarus editor)
On Sun, Feb 21, 2021 at 1:30 PM Martin Frb via lazarus < lazarus@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. 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. IMO there are too many options already. If I accidentally change something during my tests, it takes a long time to figure out what changed and how to revert it. Please add more options only when really needed. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
