Re: [Lazarus] Using Microsoft Excel workbooks with Lazarus
On Tue, 20 Feb 2024, Larry Dalton via lazarus wrote: I am writing an application that requires extensive use of Microsoft Excel .xlsx worksheets. I have no success using OCDB connections. Does anyone use TODBCConnection with excel? There are reports that it works. Why not use the fpspreadsheet that comes with lazarus ? It has always proved sufficient for me. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] DBGrid displays Float as integer
On Thu, 1 Feb 2024, John Landmesser via lazarus wrote:
In my SQlite Database laufdaten.db column "km_gelaufen" is of Type
float. But SQlite does not know this type and if i understood that
correct SQLite creates this type as needed?!
If i execute: "SELECT CAST(AVG(km_gelaufen) *AS REAL*) FROM laufdaten"
the known problem of integer only shows up again.
BUT:
If i execute this "SELECT CAST(AVG(km_gelaufen) AS REAL) FROM laufdaten
" in SQliteStudio it works as it should.
Is DBgrid or Zeos Access components the culpit? I don't know.
For Object pascal, sqlite is something of a problem as it does not have real
"types".
The following works:
sqlite> create table abc (id int);
sqlite> insert into abc values ('xyz');
Which is of course total nonsense. It should refuse the insert, but it does not.
The FPC database layer will do its best to detect the type of a result field,
but there is no guarantee that it will be the correct type, or that the actual
data will be of the correct type.
You will experience problems with data such as the above.
What you can do is to check
YourQuery.Fields[0].ClassName
if it has something different from TFloatField or TBCDField, then you know it has not correctly
detected the type.
But if you value correctness and integrity of your data, don't use sqlite.
At best it should be used for config or textual data. Anything else is risky.
Michael.--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Email sending program using Indy stopped working - seems to be an SSL problem
On Sun, 14 Jan 2024, Bo Berglund via lazarus wrote:
On Sat, 13 Jan 2024 17:03:55 +0100 (CET), Michael Van Canneyt via lazarus
wrote:
You could also use Synapse. I always prefer synapse over Indy.
So I have now verified that I cannot use Indy10 for email sending anymore :( ...
I have used Indy since a very long time like 20 years or so when dealing with
Internet accesses. So I am not used to other ways.
Now I have looked around for valid examples which will work like my send
function but using Synapse but the result is confusing.
I have found your pdf document "Sending mails using Lazarus.pdf".
But I am not clear as to how to map the Indy properties to Synapse...
And the example's uses clause is not shown so I don't know what to put there...
It says so in the text: 'the smtpsend unit'.
In fact I have looked for Synapse and in OnLine Package Manager I find
Synapse_40.1, which I have installed via OLPM. But when looking through the
packages in Lazarus I cannot find any match to synapse at all.
What have I done wrong?
Nothing.
The synapse package is not installed in the IDE, it does not
install any components on the component palette.
The Synapse package just offers classes which you must create in code.
But once you compiled the package, you can specify it as a dependency.
This is explained in my article, in the first paragraphs.
Inside the pdf I found a link to http://synapse.ararat.cz/ but there seems to be
only files from more than 10 years ago, how could they solve the recently
encountered ssl problem?
The latest code is on sourceforge:
https://sourceforge.net/p/synalist/code/HEAD/tree/trunk/
You can see it referenced on:
http://synapse.ararat.cz/doku.php/download
The maintainer is considering switching to git(lab|hub), but this will take
some time.
However, the package in lazarus should be up-to-date for your needs, I think.
Could you (or someone else reading this) suggest a new SendSvnMessage function
that will replace the following (snippets) but using Synapse (and say from where
I can get synapse):
The following program compiles:
With the aid of my article, you should be able to extend the code to work with
attachments etc.
program sm;
{$mode objfpc}
{$h+}
uses
ssl_openssl, smtpSend, mimepart, mimemess, sysutils, classes;
type
{ TSvnUser } //Data from SVN user config is put here
TSvnUser = class
public
LoginName,
FullName,
Email: string;
end;
TSvnUsers = Array of TSVNUser;
{ TSvnMessage }
TSvnMessage = class
private
FSMTP: TSMTPSend;
FMailMessage: TMimeMess;
FSender : String;
FMailServer: string;
FMailLogin: string;
FMailPwd: string;
FMailPort: word;
FMailUseSSL: boolean;
FMailTimeout: integer;
FSvnUsers: TSvnUsers; //A list of users (TSvnUser) and data
function SendSvnMessage: boolean;
procedure preparemessage;
end;
Procedure Log(Msg : string);
begin
writeln(msg)
end;
Procedure MailError(Msg : String);
begin
Raise Exception.Create(Msg);
end;
procedure LogException(Msg : string);
begin
Writeln('Exception occurred : ',Msg);
end;
function TSvnMessage.SendSvnMessage: boolean;
var
sSubject: string;
i: integer;
begin
Result := false;
try
PrepareMessage;
//Set up the SMTP transfer properties
FSMTP.TargetPort := IntToStr(FMailPort);
FSMTP.TargetHost := FMailServer;
FSMTP.AutoTls:=true;
FSMTP.Username := FMailLogin;
FSMTP.Password := FMailPwd;
//FSMTP.MailAgent := 'SVNMailer';
FSMTP.Timeout := FMailTimeout;
// compose the message
FMailMessage.EncodeMessage;
//Now send message
Log('Connecting to mailserver');
if FSMTP.Login then
begin
Log('Sending message');
if not FSMTP.MailFrom(FSender,0) then
MailError('Setting mail from')
else
begin
if not FSMTP.MailTo('u...@example.com') then
MailError('Setting mail to')
else
FSMTP.MailData(FMailMessage.Lines);
end;
Result := true;
end;
except
on E: Exception do
begin
LogException('In SendSvnMessage = ' + E.Message);
end;
end;
end;
procedure TSvnMessage.PrepareMessage;
var
i: integer;
Usr,
Msg: string;
SU: TSvnUser;
begin
(*if Pos('', FMailMessage.Body.Text) > 0 then
FMailMessage.ContentType := 'text/html; charset=utf-8'
else
FMailMessage.ContentType := 'text/plain; charset=utf-8';*)
Msg := 'Recipients:';
// for i := 0 to FSubscription.Count - 1 do
begin
//Usr := Lowercase(FSubscription[i]);
//if Pos('#', Usr) > 0 then Continue;
//SU := FSvnUsers.UserByLogin[Usr];
if SU <> NIL then
begin
// Add to TO: list. There is also CClist
FMailMessage.Header.ToList.Add(Format('%s <%s>',[SU.FullName,SU.Email]));
Msg := Msg + ' ' + Usr;
end;
end;
// Log(Msg);
end;
begin
end.
--
___
Re: [Lazarus] Email sending program using Indy stopped working - seems to be an SSL problem
On Sat, 13 Jan 2024, Bo Berglund via lazarus wrote: On Sat, 13 Jan 2024 17:03:55 +0100 (CET), Michael Van Canneyt via lazarus wrote: Or you use the system installed mailer. That's what I do. I write the mail to file and invoke sendmail. No hassle with TLS, failed connections and whatnot. sendmail will do what it takes, even retry in case of temporary failure. Michael. So you are implying there is a command line activated "mailer" on Windows Server 2016? No, only on Linux. I seem to have missed the fact that your program runs on windows. I would recommend using synapse then. It has never failed me. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Email sending program using Indy stopped working - seems to be an SSL problem
On Sat, 13 Jan 2024, Bo Berglund via lazarus wrote: Indy 10 uses a completely outdated version of the SSL library, which does not have the most recent cryptographic routines (notably for tls). Most likely the server was updated and now rejects this old version. It looks likely. I will check with the ISP tech support on Monday (this company closes support on week-ends).. There is of course a new version of the openssl library (3.2.x). The interface of that library changed, but to the best of my knowledge, indy does not support it. Then I have to switch to my backup plan, which is to do the mailing itself from a php script on my webserver (hosted at the same ISP server as the mail server is running on). You could also use Synapse. I always prefer synapse over Indy. Then I have to modify the mailer program so it posts the data to that php handler instead of using the SMTP Indy component to do the job. Or you use the system installed mailer. That's what I do. I write the mail to file and invoke sendmail. No hassle with TLS, failed connections and whatnot. sendmail will do what it takes, even retry in case of temporary failure. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Email sending program using Indy stopped working - seems to be an SSL problem
On Sat, 13 Jan 2024, Bo Berglund via lazarus wrote:
I wrote a commit reporting application for Windows Server16 back in 2018 using
then current Lazarus/Fpc.
It is a command line program called from a hook in subversion to distribute the
log message and details of commits among co-workers.
It uses Indy 10.6.2 to do its job.
The mailer class has these in uses:
{Indy units:}
IdSMTP,
IdMessage,
IdEMailAddress,
IdIOHandler,
IdIOHandlerSocket,
IdIOHandlerStack,
IdSSL,
IdSSLOpenSSL,
IdExplicitTLSClientServerBase,
IdMessageBuilder,
Back mid-december 2023 the emails stopped arriving but the problem was not
discovered/reported until I myself recently did a commit and I did not get the
expected log message email...
Now I have looked in the logfiles the application creates and found this error
example:
20240111 17:13:35.343 Connecting to mailserver
20240111 17:13:36.590 EXCEPTION: In SendSvnMessage = Error connecting with SSL.
error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version
Can someone please advice:
- Is there an external (dll?) file on Windows Server 2016 might need to be
updated for ssl to work in email handling using Indy10 with SSL?
Indy 10 uses a completely outdated version of the SSL library, which does
not have the most recent cryptographic routines (notably for tls).
Most likely the server was updated and now rejects this old version.
There is of course a new version of the openssl library (3.2.x).
The interface of that library changed, but to the best of my knowledge,
indy does not support it.
The sgcWebSockets suite has an updated version of openssl which should be able
to
support openssl 3, but that is paying software..
Michael.
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Changes to TProcess
Hello,
I merged a significant evolution of the TProcess component to FPC trunk.
Until recently, there were 2 options for TProcess when starting a new
process:
- use the parent process standard input/output/error
- use pipes to make the standard input/output/error available as streams in the
parent process.
This has been enhanced with the following new possibilities:
- For the new process, the standard input/output/error can be configured
separately.
- You can specify a filename as input/output/error.
(additionally, you can rewrite or append to the file in case of output)
- You can specify a custom I/O handle as input/output/error
(e;g. at least on unix, you can pass a socket handle)
- You can specify the null file (/dev/null on unixes or NULL on windows)
- You can specify another TProcess instance.
The last option means that you can now chain processes, just as the command
shell does.
So the equivalent of the following chain of commands:
command file.txt
would then be
Proc.Executable:='command';
Proc.InputDescriptor.FileName:='input.txt';
Proc2.Executable:='sed';
Proc2.Parameters.Add('s/delphi/FPC/g');
Proc2.OutputDescriptor.FileName:='file.txt';
Proc.OutputDescriptor.Process:=Proc2;
Proc2.Execute;
Proc.execute;
Needless to say, the component remains backwards compatible.
There is now a testsuite for the TProcess command, so everything was tested.
but nothing beats testing in the wild, so I would appreciate it if people
could test it and provide feedback.
Enjoy,
Michael.
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus and Wayland display manager
On Mon, 1 Jan 2024, Juha Manninen via lazarus wrote: 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? Yes. They work through the waylaynd X11 client. The X11 client is needed since there are way(!) too much apps that require X and which cannot be ported to wayland without major rewrites.. Michael.-- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Dbnavigator won't post to MSACESS db
On Sun, 10 Dec 2023, Larry Dalton via lazarus wrote: In my written code, yes. And I have no problems writing to the table that way. But using the Dbnavigator post button won’t work. Then I suspect that is your problem. The Dbnavigator post button only does a post, never ApplyUpdates and transaction commit. The ApplyUpdates can be automated with the sqoAutoApplyUpdates option of the TSQLQuery, but the transaction commit should be implemented for example in the AfterApplyUpdates event. Michael. Sent from my iPhone On Dec 10, 2023, at 03:29, Michael Van Canneyt via lazarus wrote: On Fri, 8 Dec 2023, Larry Dalton via lazarus wrote: I am using lazarus v2.2.6 on Windows 11. The form uses the following components: MBCCGator: TDBNavigator; MBCCGrid: TDBGrid; MBCCSource: TDataSource; MBCC_Connector: TODBCConnection; MBCCQuery: TSQLQuery; MBCC_Trans: TSQLTransaction;MBCCQuery: TSQLQuery; also includes several TDBEdits. It connects to an MSAccess Database, with a table named MBCC_2023. I have no trouble accessing the database, and reading the records. I can use MBCCGator to navigate the database. However, it will NOT post a new record or a changed record to the table. I don't get any error codes. It just won't store. Help is requested. Are you calling applyupdates and committing the transaction ? Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus-- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Dbnavigator won't post to MSACESS db
On Fri, 8 Dec 2023, Larry Dalton via lazarus wrote: I am using lazarus v2.2.6 on Windows 11. The form uses the following components: MBCCGator: TDBNavigator; MBCCGrid: TDBGrid; MBCCSource: TDataSource; MBCC_Connector: TODBCConnection; MBCCQuery: TSQLQuery; MBCC_Trans: TSQLTransaction;MBCCQuery: TSQLQuery; also includes several TDBEdits. It connects to an MSAccess Database, with a table named MBCC_2023. I have no trouble accessing the database, and reading the records. I can use MBCCGator to navigate the database. However, it will NOT post a new record or a changed record to the table. I don't get any error codes. It just won't store. Help is requested. Are you calling applyupdates and committing the transaction ? Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus make clean fails...
On Mon, 4 Dec 2023, Bo Berglund via lazarus wrote: On Mon, 4 Dec 2023 11:40:02 +0100 (CET), Michael Van Canneyt via lazarus wrote: If you have multiple compilers on your system, you may be using a different compiler compared to when you do not specify this parameter. I have several fpc:s too... I always specify the starting compiler (because I have many versions installed) so for me it is a way to make sure I am using the intended compiler. Is that switch also available for startlazarus? So it can be specified inside the desktop file for the GUI menu? Like this: Exec=/home/bosse/devtools/lazarus/2.2.4/startlazarus PP=$HOME/bin/ppcarm --pcp=/home/bosse/.lazarus_2.2.4 %f Since in the config files in home/bosse/.lazarus_2.2.4 there is already a compiler specified, it would be useless to be able to specify it again. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus make clean fails...
On Mon, 4 Dec 2023, Bo Berglund via lazarus wrote: (preferably use the full path to the ppcarm compiler) If you then still get the error, it means the makefiles for Lazarus indeed do not support your target, but how to fix that is up to the lazarus team to answer. Michael. Thanks! Indeed, it seems like the make tool does not honor the PATH setting $ echo $PATH /home/bosse/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin: $ which ppcarm /home/bosse/bin/ppcarm But I do not get the errors when make is started like this: $ make clean PP=$HOME/bin/ppcarm So now I went back to my lazarus 2.2.6 source dir where I have installed all of my customizations and ran the make clean and make bigide with a specification of the compiler location as above, and it seems to have worked this time around. But when I start Lazarus it has lost the package customizations I made earlier, so I had to go over these again and rebuild the GUI afterwards from within Lazarus itself. OLPM + my own custom components But after that was done it seems like Lazarus is OK. What are the ramifications of adding the PP= directive to the make commands? If you have multiple compilers on your system, you may be using a different compiler compared to when you do not specify this parameter. I always specify the starting compiler (because I have many versions installed) so for me it is a way to make sure I am using the intended compiler. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus make clean fails...
On Sun, 3 Dec 2023, Bo Berglund via lazarus wrote: On Sat, 02 Dec 2023 19:03:41 +0100, Bo Berglund via lazarus wrote: And concerning the compiler: $ which fpc /home/bosse/bin/fpc $ which ppcarm /home/bosse/bin/ppcarm $ fpc Free Pascal Compiler version 3.2.2 [2023/11/29] for arm $ ppcarm Free Pascal Compiler version 3.2.2 [2023/11/29] for arm What can I do now? So I have now retired the Lazarus old source dir (rename to 2.2.6.bak). Then I expanded the source tgz file yet again to get the *clean* Lazarus release 2.2.6 sources from GitLab into my system. It was expanded into a directory named 2.2.6. Now I still get the same error when I try to do the make clean operation. ~/devtools/lazarus/2.2.6 $ make clean make: -iVSPTPSOTO: No such file or directory Makefile:234: *** The Makefile doesn't support target -, please run fpcmake first. Stop. Check compiler: ~/devtools/lazarus/2.2.6 $ fpc Free Pascal Compiler version 3.2.2 [2023/11/29] for arm Copyright (c) 1993-2021 by Florian Klaempfl and others ~/devtools/lazarus/2.2.6 $ ppcarm Free Pascal Compiler version 3.2.2 [2023/11/29] for arm Copyright (c) 1993-2021 by Florian Klaempfl and others So there is an fpc/ppcarm compiler available on path and it starts OK without arguments so the version can be checked. Still with this fresh source tree and a working fpc compiler it throws this strange error... The error means it cannot find the compiler. Why and how to fix? Try this: make clean PP=ppcarm (preferably use the full path to the ppcarm compiler) If you then still get the error, it means the makefiles for Lazarus indeed do not support your target, but how to fix that is up to the lazarus team to answer. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] PasLibVLC based video player does not run on Linux...
On Tue, 21 Nov 2023, Bo Berglund via lazarus wrote: So something is not working in the Linux environment and I don't understand what. And whatever it is it does not generate any errors during compile/build on Linux. Thanks for responding! Much appreciated. I developed it on linux, so at least then it worked. Do you mean lclVlc or PasLibVlc? lclVlc I saw your name concerning the lclVlc package and the pdf documentation but another name (Robert Jedrzejczyk) is mentioned in the sources for PasLibVlc... Where did you find paslibvlc ? The one I maintain is part of FPC and is in fpc/packages/libvlc. I have tried replacing PasLibVlc with LclVlc shipped with Lazarus but I am missing a couple of items that I use during playback (varying play speed and audio shift for lipsync), which PasLibVlc does expose. It should not be difficult to add those properties to lclvlc What are the requirements for the executable's environment for it to find the libvlc files? Notmally nothing. And is it necessary for them to be there for the building process only or for the end user's execution too? libvlc is loaded dynamically, you can specify the name. I can't comment on PasLibVlc. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] PasLibVLC based video player does not run on Linux...
On Tue, 21 Nov 2023, Bo Berglund via lazarus wrote:
As I have written in other posts I am trying to port a video application from
Windows to Linux, specifically on Raspberry Pi4B with either bullseye or
bookworm operating systems.
The application runs very well on Windows and is based on PasLibVLC found here:
https://prog.olsztyn.pl/paslibvlc/
But I am not able to make it show videos on Linux..
So as a test I have now reverted to a demo application on this website in order
to minimize the possible problems:
http://lazplanet.blogspot.com/2018/01/how-to-make-simple-video-player-in.html
When I follow these instructions to create a test application on the RPi4B it
builds but when executed the video window does not appear and no video can be
played. Instead of a black player waiting for rthe file to play, there is a gray
background just like the player was not created at all.
If I copy the sources from RPi4B to my Windows10 PC and open the project in
Lazarus there (same version 2.2.6) it builds fine, and in this case it also
displays the video as expected. No problems there at all. Same sources.
So something is not working in the Linux environment and I don't understand
what. And whatever it is it does not generate any errors during compile/build on
Linux.
I developed it on linux, so at least then it worked.
I *have* enabled the threading system in the project file by putting cthreads
into the uses clause as first item so it is not a thread initializatiuon
problem:
{$IFDEF UNIX}
cthreads,
{$ENDIF}
Now I am wondering if it perhaps cannot find the VLC *libraries* that are
supposed to be available on a system with VLC installed. But I do not know how
thatr is supposed to work and I don't understand the code either.
Make sure you have libvlc-dev installed on the rpi.
This should install a symlink libvlc.so somewhere below /usr/lib
Michael.
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Building lazarus broken ?
On Sun, 19 Nov 2023, Maxim Ganetsky via lazarus wrote: 19.11.2023 19:07, Michael Van Canneyt via lazarus пишет: Hi, I did some changes to the fpcunit support. All worked in the IDE. In order to push my changes, I did a git pull. The change broke the "make bigide" command, so I was told by the CI/CD. Turns out the makefiles did not respect the lazarus dependencies in the packages: the new dependency on the codetools package was not taken into account by the makefiles. (how an uninitiated heathen like me is supposed to know this is probably only known to the happy initiated... ;)) I managed to fix that, fix is pushed so 'make bigide' works again. Makefiles are updated by updatemakefiles tool: Make sure *Additions and Overrides* are empty and run FPCDIR=/path/to/fpc/src/trunk PATH=/path/trunk/fpc/utils/fpcm/bin/x86_64-linux/:$PATH ./tools/updatemakefiles Thank you. Maybe this should be documented somewhere ? Michael-- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Building lazarus broken ?
On Sun, 19 Nov 2023, Maxim Ganetsky via lazarus wrote: 19.11.2023 19:21, Michael Van Canneyt via lazarus пишет: On Sun, 19 Nov 2023, Michael Van Canneyt via lazarus wrote: Hi, I did some changes to the fpcunit support. All worked in the IDE. In order to push my changes, I did a git pull. The change broke the "make bigide" command, so I was told by the CI/CD. Turns out the makefiles did not respect the lazarus dependencies in the packages: the new dependency on the codetools package was not taken into account by the makefiles. (how an uninitiated heathen like me is supposed to know this is probably only known to the happy initiated... ;)) I managed to fix that, fix is pushed so 'make bigide' works again. However, the git pull destroyed building the IDE in the IDE. For some reason, the IDE (I'm on linux mint) thinks it needs to build a cocoa version of the LCL. This is the lcl.pas as generated by the build procedure: uses AllLCLIntfUnits, CocoaConfig, CocoaCursor, CocoaMenus, LazarusPackageIntf; In the build settings, I did specify gtk2,linux,x86_64 as the platform settings. So why does the IDE insist on recreating a cocoa version of lcl.pas ? Well, as usual I found the answer myself after asking the question :/ This is the culprit: --- commit f821ad251b945f3435303f208b2e7de045749424 Author: rich2014 Date: Sun Nov 19 18:36:11 2023 +0800 Lcl: udpate lcl lpk and cocoa unit files --- I undid that commit: No need to do this. Well, it broke the build. Clearly, the LCL package should not use any platform/wigetset specific units. I changed settings for newly added units, they should not be included in lcl.pas just like other ones in LCL interfaces. Also good. Thank you. Still, I think this is the single failure of the lazarus package system that needs to be addressed: The missing ability to include units or requirements for certain widgetsets/platforms. (and similarly in Delphi, obviously) Michael.-- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Building lazarus broken ?
On Sun, 19 Nov 2023, Michael Van Canneyt via lazarus wrote: Hi, I did some changes to the fpcunit support. All worked in the IDE. In order to push my changes, I did a git pull. The change broke the "make bigide" command, so I was told by the CI/CD. Turns out the makefiles did not respect the lazarus dependencies in the packages: the new dependency on the codetools package was not taken into account by the makefiles. (how an uninitiated heathen like me is supposed to know this is probably only known to the happy initiated... ;)) I managed to fix that, fix is pushed so 'make bigide' works again. However, the git pull destroyed building the IDE in the IDE. For some reason, the IDE (I'm on linux mint) thinks it needs to build a cocoa version of the LCL. This is the lcl.pas as generated by the build procedure: uses AllLCLIntfUnits, CocoaConfig, CocoaCursor, CocoaMenus, LazarusPackageIntf; In the build settings, I did specify gtk2,linux,x86_64 as the platform settings. So why does the IDE insist on recreating a cocoa version of lcl.pas ? Well, as usual I found the answer myself after asking the question :/ This is the culprit: --- commit f821ad251b945f3435303f208b2e7de045749424 Author: rich2014 Date: Sun Nov 19 18:36:11 2023 +0800 Lcl: udpate lcl lpk and cocoa unit files --- I undid that commit: Clearly, the LCL package should not use any platform/wigetset specific units. Maybe time to introduce 'conditional inclusion' of units at least for the widgetset/platform ? Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Building lazarus broken ?
Hi, I did some changes to the fpcunit support. All worked in the IDE. In order to push my changes, I did a git pull. The change broke the "make bigide" command, so I was told by the CI/CD. Turns out the makefiles did not respect the lazarus dependencies in the packages: the new dependency on the codetools package was not taken into account by the makefiles. (how an uninitiated heathen like me is supposed to know this is probably only known to the happy initiated... ;)) I managed to fix that, fix is pushed so 'make bigide' works again. However, the git pull destroyed building the IDE in the IDE. For some reason, the IDE (I'm on linux mint) thinks it needs to build a cocoa version of the LCL. This is the lcl.pas as generated by the build procedure: uses AllLCLIntfUnits, CocoaConfig, CocoaCursor, CocoaMenus, LazarusPackageIntf; In the build settings, I did specify gtk2,linux,x86_64 as the platform settings. So why does the IDE insist on recreating a cocoa version of lcl.pas ? Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Running FPC in the browser...
On Sun, 22 Oct 2023, Juha Manninen via lazarus wrote: How big is the difference in performance? I guess it is very big. Ten-fold maybe? I doubt that it will be so much. Webassembly engines are highly optimized. But compilation with the webassembly binary still needs some work before we can do benchmarking. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Running FPC in the browser...
Hello, Thanks to the efforts of Nikolay Nikolov, the FPC compiler can now recompile itself to webassembly (the support for the goto statement made this possible). As a consequence, this means FPC can now be run in a browser. See the screenshot at https://wiki.freepascal.org/WebAssembly#Running_in_Web_Browsers There are still some steps to do before FPC will actually compile and link a program, but this is in the works as well. If you think this is just a cute geeky achievement, it is not. Think about the possibilities: being able to work without the need for an installation. Just go to a webpage and start developing as you would on your desktop. For teaching programming, a teacher does not need to provide anything except a browser and still have all the possibilities he would have when using a desktop. No heavy server infrastructure is needed, everything happens in the browser. No doubt, other possibilities will come to mind. Stay tuned for more goodies from the FPC team :-) Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Window Position
On Fri, 22 Sep 2023, Timothy Groves via lazarus wrote: Whenever a program I have written opens a created form, that form always appears precisely where it sat at design time, even if that would be way off the screen (my workstation has a 3440x1440 display, but the laptop I run many programs on has only 1280x800). Typically, I have to encode something in FormCreate to force it to move, which is no better really. Why won't the window manager just place it where it feels it should be, as it does with every other program out there? I've tried changing form.Position in the Object Inspector to poDefault, or poDefaultSizeOnly and that made no difference, and if I set it to poDefaultPosOnly, it turns off AutoSize, and *still* makes no difference. Is there any way to disable this behaviour? What's wrong with using poScreenCenter or poDesktopCenter ? Michael.-- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] [fpc-devel] Unicode RTL
On Fri, 28 Jul 2023, Sergey Bodrov wrote: So far, nothing catchy has been offered. WideChar RTL Note, that WinAPI says: * A Windows code page version with the letter "A" used to indicate "ANSI" * A Unicode version with the letter "W" used to indicate "wide". so, it perfectly matches AnsiString and WideString. And UnicodeString is just alias for WideString Also, what about "Delphi RTL"? Especially for Delphi compatibility. No, we discussed this in the core team, we don't want a reference to Delphi. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] [fpc-devel] Unicode RTL
On Fri, 28 Jul 2023, Mattias Gaertner via lazarus wrote: On 28.07.23 13:42, Michael Van Canneyt via lazarus wrote: On Fri, 28 Jul 2023, Alexey Torgashin via lazarus wrote: Objection duly noted. Yes, 'Unicode RTL' sounds very bad. Before it was Unicode too. So, "UTF16 RTL", "WideChar RTL" or so. The "Unicode" refers to String = UnicodeString. The latter has been in use for what, 15-20 years ? ...wrong for 20 years. The name is chosen to remain consistent with existing terminology. It seems, it was chosen because it is easier to pronounce than UTF16 RTL. No, see below (or above). Naming something Unicode without adding any new Unicode feature can hardly be called consistent. As I wrote, the "Unicode" refers to String = UnicodeString. In that sense it is 'consistent with existent terminology' That the original terminology "unicodestring" is badly chosen, see first line in the feature list: https://delphi.embarcadero.com/project/delphi-2009/ So complaints to CodeGear, please. But if all these terribly unhappy and depressed users have a better name, I'm all ears. So far, nothing catchy has been offered. We'll attribute this lack of creativity to the state of depression due to having to use such awful and horrifying terminology for ~15 years ;-) Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Compilation failed : PolygonNonZeroWindingRule unknown
On Fri, 28 Jul 2023, Maxim Ganetsky via lazarus wrote: 28.07.2023 16:10, Michael Van Canneyt via lazarus пишет: On Fri, 28 Jul 2023, Werner Pamler via lazarus wrote: Am 28.07.2023 um 11:37 schrieb Michael Van Canneyt via lazarus: I updated my lazarus today, and the following fails: procedure TLazCanvas.Polygon(const Points: array of TPoint; Winding: Boolean); begin PolygonNonZeroWindingRule := Winding; inherited Polygon(Points); end; it does not know PolygonNonZeroWindingRule. I removed that line, and all compiles, but I suppose this is not the correct fix ? Last time there was a complaint about this I checked all combinations I have access to, and it was working. You are talking of Laz/main? In combination with which FPC? And on which OS? Did you try a *clean *rebuild of the Lazarus IDE? It is Laz/Main (updated today), FPC 3.2.2 and clean rebuild (I have the option 'clean always' set in the lazarus build config). Lazarus can be built with FPC 3.2.2 just fine. Our CI ensures this (and it does exactly clean builds which include TLazCanvas too). That is why I was so surprised to see the failure... After some searching, it seems I was using a fixes compiler and didn't notice. Seems my mind wanted to read 3.2.2 instead of the actual 3.2.3 :/ Apologies for the noise. Michael.-- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Compilation failed : PolygonNonZeroWindingRule unknown
On Fri, 28 Jul 2023, Werner Pamler via lazarus wrote: Am 28.07.2023 um 11:37 schrieb Michael Van Canneyt via lazarus: I updated my lazarus today, and the following fails: procedure TLazCanvas.Polygon(const Points: array of TPoint; Winding: Boolean); begin PolygonNonZeroWindingRule := Winding; inherited Polygon(Points); end; it does not know PolygonNonZeroWindingRule. I removed that line, and all compiles, but I suppose this is not the correct fix ? Last time there was a complaint about this I checked all combinations I have access to, and it was working. You are talking of Laz/main? In combination with which FPC? And on which OS? Did you try a *clean *rebuild of the Lazarus IDE? It is Laz/Main (updated today), FPC 3.2.2 and clean rebuild (I have the option 'clean always' set in the lazarus build config). Where is this PolygonNonZeroWindingRule supposed to be defined ? Michael.-- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] [fpc-devel] Unicode RTL
On Fri, 28 Jul 2023, Alexey Torgashin via lazarus wrote: Objection duly noted. Yes, 'Unicode RTL' sounds very bad. Before it was Unicode too. So, "UTF16 RTL", "WideChar RTL" or so. The "Unicode" refers to String = UnicodeString. The latter has been in use for what, 15-20 years ? The name is chosen to remain consistent with existing terminology. Assuming you guys are consistent, I guess you people are also not comfortable with the term 'UnicodeString' ? Working with FPC must be a really annoying experience then... Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] [fpc-devel] Unicode RTL
On Fri, 28 Jul 2023, Adriaan van Os via fpc-devel wrote: Michael Van Canneyt via fpc-devel wrote: Hello, I have just completed phase one of the "Unicode RTL" effort. I object to the name "Unicode" RTL. Where people talk about what they call "Unicode" they usually mean UCS-16 or UTF-16 or UTF-16-mishandled-as-UCS16. Objection duly noted. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Compilation failed : PolygonNonZeroWindingRule unknown
Hi, I updated my lazarus today, and the following fails: procedure TLazCanvas.Polygon(const Points: array of TPoint; Winding: Boolean); begin PolygonNonZeroWindingRule := Winding; inherited Polygon(Points); end; it does not know PolygonNonZeroWindingRule. I removed that line, and all compiles, but I suppose this is not the correct fix ? Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] FPC compiler error messages file update
Hello, We're preparing FPC fixes release 3.2.4. There are some new error messages in the compiler/msg/errore.msg file, they need to be translated to other available languages: errorct.msg (Catalan) errorda.msg (Danish) errord.msg (German, CP 850) errordu.msg (German, UTF8) errores.msg (Spanish) errorfi.msg (Finish) errorf.msg (French) errorhe.msg (Hebrew CP 1255) errorheu.msg (Hebrew UTF8) errorid.msg (Indonesian CP 20127) erroriu.msg (Italian) errorn.msg (Dutch) errorpli.msg (Polish CP 8859-2) errorpl.msg (Polish CP 852) errorpt.msg (Portugese CP 850) errorptu.msg (Portugese UTF8) errorr.msg (Russian CP 866) errorru.msg (Russian UTF8) errorues.msg (Spanish UTF8) The tool compiler/utils/msgdif can be used to compare the language-specific file with the original file, and will write a new.msg file. so after compiling msgdif, if you execute the following command in the compiler/msg directory (I'm taking dutch as an example, you should obviously use your language file): msgdif errore.msg errorn.msg it will result in a file new.msg which has all original messages from errorn.msg and all new messages: this 'new.msg' file needs to be corrected/updated. I have not updated the various files myself using this method, since I am not capable of interpreting the resulting new.msg since I don't read all these languages, and would possibly commit wrong files as a result. If you speak one of these languages, please consider updating the corresponding language file and uploading a patch to the issue tracker, or you can send a diff to me and I will apply it. If creating the msgdif tool and the new.msg file is too difficult for you, feel free to mail me and I will gladly do it for you. Thanks in advance, Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] [fpc-devel] Unicode RTL
On Tue, 25 Jul 2023, Luca Olivetti via lazarus wrote: El 24/7/23 a les 23:20, Michael Van Canneyt via lazarus ha escrit: To this end, it would be helpful to add a paragraph on the wiki page underlining how to retain the single-byte RTL; or, if no user action is necessary, mention that, to set minds at ease. Thank you for this hard work! No user action is necessary. But your advice is good: I have added this to the page, and made clear that the RTL as it currently exists, is still the default RTL. So those of us that don't need delphi compatibility can be sure that nothing will break? Unless I unwittingly introduced a bug somewhere (gods forbid ;)), nothing will break. Backwards compatibility is and remains important. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] [fpc-devel] Unicode RTL
On Mon, 24 Jul 2023, Kirinn via fpc-devel wrote: Hi, A "unicode" RTL is of course great for targeting legacy Windows platforms, but for those of us on Linux, UTF-8 is the way. It is not only for legacy windows platforms. The target platform is secondary. What to use depends more on your codebase than on your target platform. There is a lot of Delphi code out there that assumes that string=unicodestring. If, like my current company, you have a large Delphi application that you wish to run on linux, then you may be better off with a unicode RTL. To this end, it would be helpful to add a paragraph on the wiki page underlining how to retain the single-byte RTL; or, if no user action is necessary, mention that, to set minds at ease. Thank you for this hard work! No user action is necessary. But your advice is good: I have added this to the page, and made clear that the RTL as it currently exists, is still the default RTL. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Unicode RTL
Hello, I have just completed phase one of the "Unicode RTL" effort. The 'Unicode RTL' is an effort to be more Delphi compatible: - Char = Unicode Char and String = UnicodeString - Provide dotted filenames. Basically closer to the RTL as it exists in more recent versions of Delphi (essentially post - Delphi 2009) This RTL will co-exist with the current RTL (single-byte char, no dotted names), but will share the same codebase. More explanations can be found here: https://wiki.freepascal.org/FPC_Unicode_RTL This coexistence of 2 RTLs is accomplished with 'Subtarget support'. Subtarget support is a means to consistently apply a set of Free Pascal compiler settings to everything that you compile. Subtarget support is explained in more detail here: https://wiki.freepascal.org/FPC_Subtarget_Support While it is now used to create a unicode rtl, it could also be used to * create a llvm-compiled RTL. * create an rtl with debug info and one without. * compile the various Lazarus widgetsets into different directories * ... any other things you may think of ... all with a single installation of FPC. For the second part of the effort, 'provide dotted filenames', the actual work is finished, but still needs merging to trunk. This second part is expected to be merged in the next days/weeks. But today, using FPC trunk, you can now recompile the Free Pascal RTL, Packages and Utils (but not the compiler itself!) into a set of units where Char = UnicodeChar String = UnicodeString To compile (and install) the unicode rtl, all you need to do is follow the steps outlined in https://wiki.freepascal.org/FPC_Unicode_RTL Basically, this means creating a 2-line configuration file for the unicodertl subtarget, and compiling the RTL, packages and utils with make SUB_TARGET=unicodertl For those that need/want more delphi-compatible code, I would love to hear of your experience with the unicode rtl. I have done extensive testing, but as practice shows, there will always be cases which defy ordinary test cases... If the 2 wiki pages need more explanations, please let me know and I will do my best to improve the explanations. Hopefully, in the near future the compiler settings dialog in Lazarus will also allow you to specify a subtarget. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] MJPEG streamer
On Sun, 23 Jul 2023, Steve Gatenby via lazarus wrote: Would anybody know if there is a component / code to enable reading an mjpeg stream from a http camera to a Lazarus form/panel (or anything really) Dont mind installing libraries etc - Looking to suit Linux specifically though vlc can play media streams, so I think Libvlc can be used for this. The lazvlc.lpk contains a component that encapsulates vlc, it's just a matter of feeding it the correct url. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus trunk version number
On Sat, 1 Jul 2023, Sven Barth via lazarus wrote: Maxim Ganetsky via lazarus schrieb am Fr., 30. Juni 2023, 15:48: 30.06.2023 16:44, Maxim Ganetsky via lazarus пишет: 30.06.2023 14:27, Martin Frb via lazarus пишет: On 30/06/2023 12:51, Michael Van Canneyt via lazarus wrote: On Fri, 30 Jun 2023, Juha Manninen via lazarus wrote: 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 You might want to add some explanation for this new versioning scheme to that page. Added. I made some improvements, hope it is even more clear now. The graph does not help. From what is currently there, I don't understand neither the logic nor the need of this change. "Need"... Well, in terms of "because it solved the issue xyz" => then there is no need. Basically, version numbering is all about "marketing". By always increasing major version we tell to the general audience that major release indeed contains major changes (which is always the case). So we solve/improve "marketing" issues. BTW, in my opinion FPC has similar issues and will benefit from such approach to versioning too. In FPC the major number *has* a meaning, namely that there have been significant changes in the code generator. Towards the 2.x series it was the rewrite of the different backends and for the 3.x series it was the introduction of the high level code generator. The minor number is then to signify a new release with many new features on top of the same base architecture and the release number is then to differentiate between development and stable. We don't follow "marketing". It might be wise to communicate or document this somewhere: either on wiki or website. I work almost 30 years on FPC, and even I didn't know this. Michael.-- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus trunk version number
On Fri, 30 Jun 2023, Maxim Ganetsky via lazarus wrote: 30.06.2023 16:55, Michael Van Canneyt via lazarus пишет: On Fri, 30 Jun 2023, Maxim Ganetsky via lazarus wrote: Basically, version numbering is all about "marketing". By always increasing major version we tell to the general audience that major release indeed contains major changes (which is always the case). So we solve/improve "marketing" issues. BTW, in my opinion FPC has similar issues and will benefit from such approach to versioning too. That was funny to read :-) I think the biggest issue in this regard is actually making releases to begin with. Yes indeed, but then in case of rare releases it is even more important to have right version numbering. :) Changing versioning is an easy and logical move in any case, why not do it? That was even more funny to read... Honestly: I'll settle for actually managing to get a release out. Michael.-- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus trunk version number
On Fri, 30 Jun 2023, Maxim Ganetsky via lazarus wrote: Basically, version numbering is all about "marketing". By always increasing major version we tell to the general audience that major release indeed contains major changes (which is always the case). So we solve/improve "marketing" issues. BTW, in my opinion FPC has similar issues and will benefit from such approach to versioning too. That was funny to read :-) I think the biggest issue in this regard is actually making releases to begin with. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus trunk version number
On Fri, 30 Jun 2023, Maxim Ganetsky via lazarus wrote: 30.06.2023 14:27, Martin Frb via lazarus пишет: On 30/06/2023 12:51, Michael Van Canneyt via lazarus wrote: On Fri, 30 Jun 2023, Juha Manninen via lazarus wrote: 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 You might want to add some explanation for this new versioning scheme to that page. Added. I made some improvements, hope it is even more clear now. The graph does not help. From what is currently there, I don't understand neither the logic nor the need of this change. "Need"... Well, in terms of "because it solved the issue xyz" => then there is no need. Basically, version numbering is all about "marketing". By always increasing major version we tell to the general audience that major release indeed contains major changes (which is always the case). So we solve/improve "marketing" issues. Thanks to all for the explanations, all is clear now ! Michael.-- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus trunk version number
On Fri, 30 Jun 2023, Martin Frb via lazarus wrote: On 30/06/2023 13:27, Martin Frb via lazarus wrote: But, there was no need (anymore) to reserve 2 digits for major releases. When 1.0 was released there was no need for further major releases to be 1.2 instead of 2.0. I forgot to add the explanation for "anymore" Prior to 1.0 the minor and patch numbers were used: 0.minor.patch But therefore the "major" number was not used (always 0). Since Lazarus became stable, the major number became 1 and it became available for use. Yet - without perceivable need - minor and patch were kept in used too. Making it 3 digits to be used. When only 2 were needed. So basically you did a shift left of the version number ? Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus trunk version number
On Fri, 30 Jun 2023, Juha Manninen via lazarus wrote: 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 You might want to add some explanation for this new versioning scheme to that page. The graph does not help. From what is currently there, I don't understand neither the logic nor the need of this change. Also, how come trunk is 3.99 (indicating development for 4.0, if I understand the page correctly) if 3.0 is not yet out ? Based on the graph, I would think trunk should be at 2.99 now. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Sciter for Lazarus: VCL Handle vs. LCL Handle
On Wed, 14 Jun 2023, Marcos Douglas B. Santos wrote: On windows, the handle should work the same. If you're working on another platform, then it works very different, and then you'll need to see what sciter actually expects. I would like it to work on Windows, Linux and MacOS, but for now I will be glad that it only works on Windows. Michael, Do you have any more ideas to try to solve this issue? I think that first of all the result of API.SciterSetCallback (2 lines before) needs to be checked. If this also gives an error, then we at least know the window handle is totally not OK. If that does not give an error, then I think it means the createparams are not OK for the event handler. It can be that the customcontrol window handle is created with different create params than the one in Delphi. I don't know how to check this. There is also 'HANDLE_ALL' which requests event handling for all kinds of events, including DND So I would also change HANDLE_ALL to something like HANDLE_MOUSE OR HANDLE_KEY OR HANDLE_FOCUS Because maybe the window handle is not created with the correct parameters for HANDLE_ALL. I found some Go code that initializes OLE stuff for the window, and I would be surprised if Lazarus does this by default; if HANDLE_ALL also must handle OLE messages, then it can be it fails for those messages. Unfortunately, the sciter documentation is very unclear in terms of what is expected of the window handle. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Sciter for Lazarus: VCL Handle vs. LCL Handle
On Tue, 13 Jun 2023, Marcos Douglas B. Santos via lazarus wrote: Hi, I'm trying to run Sciter.TIS https://sciter.com/download/ on Lazarus, which could be an open source project in the future — yes, not the newer version (named Sciter.JS) as I don't need these new features. I've started looking into https://github.com/da-baranov/SciDe (~8 years ago). Then, I discovered a fork https://github.com/Mikanoshi/SciDe (~5 years old) and forked from it because it is "newer". The da-baranov's original repository already tried to run on Lazarus, but they have an issue which couldn't be solved: https://github.com/da-baranov/SciDe/issues/3#issuecomment-87698772 If you look at the issue, you see there is a commit that claims to solve this issue. Did you test if that commit is incorporated in your code ? I have the same issue, even using the newer version... When it calls API.SciterWindowAttachEventHandler() here https://github.com/Mikanoshi/SciDe/blob/master/source/Sciter.pas#L1439-L1440, the result is always SCDOM_INVALID_HWND. Why am I asking this here? Well, the project claims that it works from Delphi 7 to newer; they could compile on Lazarus; I also could compile (creating a package, a component, etc) on Lazarus; but it do not work because something looks like different about how a Handle works on VCL comparing to LCL. On windows, the handle should work the same. If you're working on another platform, then it works very different, and then you'll need to see what sciter actually expects. Michael.-- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Output directories
Hello, There is a problem when installing Lazarus through the package manager on Linux, and when you try to install/recompile additional packages: Error: (lazarus) unable to create package output directory "/usr/share/lazarus/2.2.4/components/fpweb/lib/x86_64-linux" of package "weblaz 1.0" I suspect that the IDE tries to create the output directories of packages, but of course it has no write permission in /usr/share. Should this not be detected and the output put in ~/.local/share/lazarus/... instead ? Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Who uses "caret past EOL"?
On Fri, 2 Jun 2023, Martin Frb via lazarus wrote: On 02/06/2023 15:07, Michael Van Canneyt via lazarus wrote: On Fri, 2 Jun 2023, Martin Frb via lazarus wrote: If you do, do you use it within the range of the "longest line" only? What if I want to add a comment at column 60 (think explanation about enumerated value) but the max line length is 40 ? Now I click at col 60 and add the comment. Will this still be possible ? Yes, it will. The question is how far should it allow by default? --- Background: Currently the scroll always goes to 1024. Except when the longest line is longer, then it goes (on any line) to the max = longest line. But never behind that. In future, if you hold cursor-right, it will go further (like notepad ++, if "virtual space" is enabled). Of course that covers the range for cursor keys. About the range for mouse. The current limit is quite big. But if you really have lines that long => it's not enough. So instead you will (optional) be able to scroll (scrollbar / mouse) up to "longest line" + "width of screen". If your Window shows 85 chars, and your longest line is 20 chars, you can mouse move the caret up to 105 (and right cursor will go behind). Those options are already there in the main branch: - no extra scroll, just cursor keys (well on shorter lines, the mouse can go up to "longest line", but that is placement, not scroll range) - add one page to longest line - Max(1024, longest line) Currently the last is default. Maybe "add one page" is a better default. +1, but as you say, use cases vary :-) Michael.-- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Who uses "caret past EOL"?
On Fri, 2 Jun 2023, Martin Frb via lazarus wrote: If you do, do you use it within the range of the "longest line" only? What if I want to add a comment at column 60 (think explanation about enumerated value) but the max line length is 40 ? Now I click at col 60 and add the comment. Will this still be possible ? Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] locate command for dBase
On Fri, 26 May 2023, wkitty42--- via lazarus wrote:
On 5/25/23 8:12 PM, john Ward via lazarus wrote:
if
temp.Locate('temp_no', (tempid),[loPartialkey])
then
begin
showmessage('we found the field or Partial' + tempid);
showmessage('current temp_no is ');
tno := temp.FieldbyName('temp_no').asString;
showmessage('tempno is = ' + tno);
end;
The above code, executes the 'then', shows me what was searched for BUT
when a
data field is displayed, the original record is pointed to, NOT a record
further
in the database.
i don't see where you did a seek to the record you are trying to get to...
granted, it has been a long while since i did anything with FPC/Lazarus or an
dBase databases but it would seem there should be an obvious seek action...
maybe...
the locate() is a seek action.
But without more info/code it is difficult to give an answer to the OP's
question.
Michael.--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Some source editor context menu items broken
On Sun, 21 May 2023, Mattias Gaertner via lazarus wrote: On Sun, 21 May 2023 10:48:30 +0200 (CEST) Michael Van Canneyt via lazarus wrote: [...] I saw a remark in main.pp that this is supposed to be faster than using the codetools: CurWordAtCursor := ASrcEdit.GetWordAtCurrentCaret; //it is faster to get information from SynEdit than from CodeTools ASrcEdit.EditorComponent.CaretAtIdentOrString(ASrcEdit.EditorComponent.CaretXY, IdentFound, StringFound); Faster? Probably. Correct? clearly not (yet). Problem is that this function checks: AtIdent := Attri = Highlighter.IdentifierAttribute; But TSynPasSyn has its own attribute ProcedureHeaderName: TSynHighlighterAttributesModifier Asking the syntax highlighter means there is a probability that the code breaks again whenever a new attribute is introduced. Looking at the code, I think it should not be hard to change this algorithm so it uses the codetools. Simply start scanning tokens on the line of the caret, and determine the token type when the caret position is reached. That is what the highlighter does, after all. The advantage is that it will be more unambiguous. Well, just an idea. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Some source editor context menu items broken
On Sun, 21 May 2023, Luca Olivetti via lazarus wrote: El 21/5/23 a les 10:48, Michael Van Canneyt via lazarus ha escrit: Any solutions ? I found this issue a while ago (and I think I reported it here but I cannot find the message right now) and even if the context menu is greyed out, the "F2" key still works to rename the identifier. That would be an error in itself. No idea about the "find identifier references" sorry. They are updated at the same time with the same logic. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Some source editor context menu items broken
Hello, The refactoring context menu item and the find identifier references context menu are broken. Type TSourceParser = Class(TObject) function ParseSource: TPasModule; end; With the cursor on "ParseSource", the 'Find identifier references' and 'Rename identifier' menu items in the context menu are grayed out. (plus some others) The same problem exists if the cursor is on "ParseSource" in the implementation: function TSourceParser.ParseSource: TPasModule; I did some digging, and it seems to me that the error is in the TCustomSynEdit.CaretAtIdentOrString routine, which does not detect an identifier correctly. It seems a bit strange to me that the syntax highlighter is used to determine whether the cursor is on a identifier or something else. I saw a remark in main.pp that this is supposed to be faster than using the codetools: CurWordAtCursor := ASrcEdit.GetWordAtCurrentCaret; //it is faster to get information from SynEdit than from CodeTools ASrcEdit.EditorComponent.CaretAtIdentOrString(ASrcEdit.EditorComponent.CaretXY, IdentFound, StringFound); Faster? Probably. Correct? clearly not (yet). Any solutions ? Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Source Hint Popup window markup ?
Hi, The IDE - in its desire to be helpful - shows a popup whenever you hover your mouse over an identifier. It seems to me the popup contains some markdown (e.g. underscores): see attached screenshot. I assume this is supposed to be formatted ? If so, how to enable that formatting ? Michael.-- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Copilot, VS Code, and OmniPascal
On Mon, 15 May 2023, Anthony Walter via lazarus wrote: Hello all! I would very much like to use Github Copilot with Free Pascal, and possibly within the Lazarus IDE. I have been using Github Copilot a lot recently with my C and C# coding projects and have found it to be an immensely useful tool. Recently I used it rapidly to create documentation comments for a large C# API I wrote and was impressed with the speed and accuracy. I've also found it extremely productive when it comes to working with third-party libraries where I haven't much used a new-to-me library. Copilot aids me greatly by generating code to do tasks with such code while I learn and become familiar with how to use the aforementioned libraries. This has led me to experiment with using Github Copilot in Visual Studio Code with Pascal, and while it simply works by opening files with a ".pas" extension, there is obviously a lot more which can be done to make a tool like Copilot with better IDE support. Specifically supporting Pascal project files that reference packages with their unit source paths, building and debugging, and problem solving (fixing errors in source code). My question to you in the Lazarus community is has anyone even attempted to integrate the Copilot system into Lazarus? If this is not at all possible, has anyone here used the OmniPascal extension to VS Code and configured it to work with lazbuild and have working tasks and launch JSON configuration files they could share along with their insights? I've googled a few supposed "guides" on the subject and found them to be horribly wrong or missing many critical steps. I've discarded OmniPascal, because it eats 100% cpu on Linux on every project I tried, and that is simply unacceptable. It's also closed source, so we can't improve it. Instead I'm working with Ryan Joseph on the Pascal LSP based on the lazarus code tools: https://github.com/genericptr/pascal-language-server This project does not yet give all the possibilities of Omnipascal, but it is very usable (identifier completion and code completion work) and we're improving it still. I've made many improvements and stabilized the code, removed all memleaks. It's now also ready to listen on a socket instead of stdin and can be debugged. At the same time Mattias Gaertner and I are improving the fcl-passrc codebase so it contains some error-recovery mechanisms. Currently it stops at the first error, we're improving this so it tries to continue to analyze the code. This work is needed to provide better user experience in Pas2js and will give better diagnostics than the Lazarus codetools give us. The codetools are very forgiving of errors, so it keeps functioning in the presence of some errors, which is a different goal than the what the diagnostics needs. Once that is done, I plan to continue to work on the LSP process to integrate the new possibilities, and then provide an additional VS Code extension that does some project management for lazarus and lazbuild. Any help on this project is of course more than welcome. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Resources without RC files
On Thu, 4 May 2023, Ondrej Pokorny wrote: On 04.05.2023 08:38, Michael Van Canneyt wrote: On Thu, 4 May 2023, Ondrej Pokorny via lazarus wrote: How is it possible that the LFM files are included directly but *.SQL files are parsed as RC files? Because the file extension is recognized ? LFM is included as RC_DATA, and probably everything that is not .lfm is assumed to be a RC format. I believe fpcres also has this check. Thanks for the tip. I found it - it is directly in the compiler. In comprsrc.pas TWinLikeResourceFile.IsCompiled there is a logic that defines what the compiler does with the included resource file based on the extension or file header. I don't like the fact that there are hard-coded constants for what seems to be (for a stranger) arbitrary file extensions and that it is not documented anywhere. Well, developers that are using lazarus and form files know what happens. This is undoubtedly the majority of FPC users, so I don't think this is an issue. But it should definitely be documented. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Resources without RC files
On Thu, 4 May 2023, Ondrej Pokorny via lazarus wrote:
Hello,
I see that the LCL includes LFM files as resources directly without a *.RC
file:
{$R *.lfm}
---
But if I do this with my custom file. E.g.:
{$R *.sql}
I get an "error when compiling resources":
Compile Project, Mode: Debug, Target: Test.exe: Exit code 1, Errors: 1,
Warnings: 1
Warning: windres: can't open file `REPLACE': No such file or directory
uTest.pas(96,0) Error: Error while compiling resources -> Compile with -vd
for more details. Check for duplicates.
---
How is it possible that the LFM files are included directly but *.SQL files
are parsed as RC files?
Because the file extension is recognized ? LFM is included as RC_DATA, and
probably everything that is not .lfm is assumed to be a RC format.
I believe fpcres also has this check.
Michael.
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TSQLConnector for MySQL non-standard port
On Mon, 24 Apr 2023, Koenraad Lelong via lazarus wrote: Hi, I would like to use a non-standard port for my MySQL-connection. Is this possible ? If so, how ? Standard port is 3306. I tried to add my non-standard port to the hostname (:), but that does not work: 'TMySQL57Connection : Server connect failed.' Sniffing the network on that port gives nothing, so there is no attempt to connect. MySQLWorkbench with the same parameters works OK, so there is a server listening on that port. Try this: Params.Values['Port']:='3306' Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TLS connection to MySQL
On Thu, 20 Apr 2023, Koenraad Lelong via lazarus wrote: Hi, I'm updating an application that uses TSQLConnector to connect to MySQL 5.7. The MySQL server (5.7.42) will be restricted to use only TSLv1.2 (or higher). Is this possible with TSQLConnector ? TLSv1.1 works without configuring anything. With my test-server, it fails to connect when this is set to allow only TLSv1.2. The application will run on Windows 11 if that matters. My libmysql.dll is version 5.7.42.0, in the same directory as the application. TSQLConnector will only pass on any connection parameters you set up to the mysql layer. If it fails for a particular TLS version, then I think it is more likely that the libmysql.dll is too old (or the openssl lib that it uses) and does not properly support TLSv1.2. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] animated splash screen for lengthy operation, works with windows, doesn't with linux
On Tue, 28 Mar 2023, Luca Olivetti via lazarus wrote: El 28/3/23 a les 0:01, Michael Van Canneyt ha escrit: My bad, I made a typo, it should have been MyException:=ExceptionClass(ut.FatalException).ClassType).Create(Exception(ut.FatalException).message) Thank you. Actually it is MyException:=TExceptionClass(Exception(ut.FatalException).ClassType).Create(Exception(ut.FatalException).message); with ExceptionClass= class of exception; Actually, I never write it like this in one statement, Yep, it's quite a mouthful, I had to break it up to spot the error :-) I save the class pointer and message in local variables, do cleanup first and then use the class pointer and message later to raise an exception. But the effect is the same: you create a copy with the same class and message as the original. But not with the same detail (i.e. any extra fields are missing). Not that I'm really interested in them (usually I just use the message), but still... I am aware of that. But the extra fields are usually only interesting in the debugger. You will see them if you inspect ut.FatalException. For the user normally only the message is interesting. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] animated splash screen for lengthy operation, works with windows, doesn't with linux
On Mon, 27 Mar 2023, Luca Olivetti via lazarus wrote: El 27/3/23 a les 17:26, Luca Olivetti via lazarus ha escrit: El 27/3/23 a les 16:50, Michael Van Canneyt ha escrit: Ehm. In case of an exception, ut will never be freed ? That's what I said. I was looking for a way to free it *and* raise the exception in the context of the main thread. If I move the ut.free before the raise, the exception has already been freed and it's invalid, causing a sigsev, if I enclose it in a try..finally the exception handler will be called after the finally has freed the thread (and the exception, so it's the same problem). Normally, I'd do Raise Exception(ut.fatalexception.classtype).Create(ut.fatalexception.message); Actually I'd have to first create the exception, then free ut, then raise the exception (keep in mind that FatalException is a TObject and it isn't necessarily of class Exception), otherwise a direct raise as you wrote would not free ut. I only gave the line to show that you can raise a second exception object with the same class and message as the original. MyException:=nil; if ut.FatalException<>nil then begin if ut.FatalException is Exception then MyException:=Exception(ut.FatalException).Create(Exception(ut.FatalException).message) Ouch, I left out the ClassType, but if I change it to MyException:=Exception(Exception(ut.FatalException).ClassType).Create(Exception(ut.FatalException).message) it's an instant segfault. My bad, I made a typo, it should have been MyException:=ExceptionClass(ut.FatalException).ClassType).Create(Exception(ut.FatalException).message) with ExceptionClass= class of exception; Actually, I never write it like this in one statement, I save the class pointer and message in local variables, do cleanup first and then use the class pointer and message later to raise an exception. But the effect is the same: you create a copy with the same class and message as the original. Michael.-- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] animated splash screen for lengthy operation, works with windows, doesn't with linux
On Mon, 27 Mar 2023, Luca Olivetti via lazarus wrote: El 27/3/23 a les 16:13, Michael Van Canneyt via lazarus ha escrit: On Mon, 27 Mar 2023, Luca Olivetti via lazarus wrote: El 27/3/23 a les 11:59, Luca Olivetti via lazarus ha escrit: [*] instead of opening the query I spawn a thread that opens it, wait for it to finish while executing Application.ProcessMessages and eventually reraise the exception that was generated inside the thread. Speaking of which, I encapsulated it in a procedure (TWaitForm is the spash screen, Aproc is a procedure of object, TExecInThread simply calls AProc in its execute method): procedure ExecWithSplash(AProc:TThreadProc); var wf:TWaitForm; ut:TExecInThread; begin Wf:=TWaitForm.Create(Application); WF.Show; ut:=TExecInThread.create(AProc); while not ut.Finished Application.ProcessMessages wf.free; if ut.FatalException<>nil then raise(ut.FatalException); ut.free; Ehm. In case of an exception, ut will never be freed ? That's what I said. I was looking for a way to free it *and* raise the exception in the context of the main thread. If I move the ut.free before the raise, the exception has already been freed and it's invalid, causing a sigsev, if I enclose it in a try..finally the exception handler will be called after the finally has freed the thread (and the exception, so it's the same problem). Normally, I'd do Raise Exception(ut.fatalexception.classtype).Create(ut.fatalexception.message); Michael.-- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] animated splash screen for lengthy operation, works with windows, doesn't with linux
On Mon, 27 Mar 2023, Luca Olivetti via lazarus wrote: El 27/3/23 a les 11:59, Luca Olivetti via lazarus ha escrit: [*] instead of opening the query I spawn a thread that opens it, wait for it to finish while executing Application.ProcessMessages and eventually reraise the exception that was generated inside the thread. Speaking of which, I encapsulated it in a procedure (TWaitForm is the spash screen, Aproc is a procedure of object, TExecInThread simply calls AProc in its execute method): procedure ExecWithSplash(AProc:TThreadProc); var wf:TWaitForm; ut:TExecInThread; begin Wf:=TWaitForm.Create(Application); WF.Show; ut:=TExecInThread.create(AProc); while not ut.Finished Application.ProcessMessages wf.free; if ut.FatalException<>nil then raise(ut.FatalException); ut.free; Ehm. In case of an exception, ut will never be freed ? Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus fails to build
On Sun, 19 Mar 2023, Mattias Gaertner via lazarus wrote: On Sun, 19 Mar 2023 00:00:02 +0100 (CET) Michael Van Canneyt wrote: [...] As this happens seldom there is no detection built in (yet) to handle this automatically. I added a simple detection, so in the future the IDE will not add base packages to staticpackages.inc. I also added some comments. Thank you ! I pulled you changes and rebuilt, all recompiles without issues. And the comments will definitely give a hint as how to proceed in case it still goes wrong... Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus fails to build
On Sat, 18 Mar 2023, Mattias Gaertner via lazarus wrote: On Sat, 18 Mar 2023 23:39:02 +0100 Martin Frb via lazarus wrote: [...] This error happens everytime, when packages become part of the core list. Because older IDE are not forward compatible with that sort of change. As this happens seldom there is no detection built in (yet) to handle this automatically. If possible, might be a good idea. And rather than hardcoding this in the uses clause of lazarus, I would think it is better to have a list of 'always-include' package names coded somewhere in the sources. Then the 'hardcoded' packages are simply added to staticpackages.inc, and the IDE can warn when it is started after recompilation when an additional recompilation is needed: It can then detect that the list of hardcoded packages has changed after compilation. The problem is then simply non-existant. [...] To work around: Build once via make clean bigide ... or update lazbuild and use that to build the new IDE. As all naive users, I use 'Tools - Build lazarus'. Silly me... Michael.-- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus fails to build
On Sat, 18 Mar 2023, Martin Frb via lazarus wrote: If some functionality of the IDE uses laz.virtualtreeview then the IDE should properly list a depencency on that package, instead of adding it hardcoded in the IDE uses clause. As soon as a user installs the package in question (s)he will have the same error as I did. I removed the duplicates and pushed the change. Michael. They werent duplicates. Those units (or their packages) are now hardcoded included. This error happens everytime, when packages become part of the core list. Because older IDE are not forward compatible with that sort of change. Is there no way to make the IDE forward compatible with that kind of change ? With then removed, the IDE will fail to build, when those packages are not installed manually. == To work around: Build once via make clean bigide and after that all should work. Or remove the 3 units from lazarus.pp / rebuild / add them again Once you have a new IDE, it wont add them to staticpackages anymore. OK. I will re-add them. Maybe this should be documented somewhere, or some warning should be given on the mailing lists that this change has happened. If I just do a git pull and have this problem, currently there is no way to know. And if it happens again in 5 years, I will surely have forgotten this mail. Michael.-- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Lazarus fails to build
Hi, I did a git pull of latest lazarus sources. Someone added laz.virtualtreeview and fpdebuggerfp to the IDE uses clause. This caused the compilation to fail, since these units are also in the installed packages. For instance the online packagemanager also used laz.virtualtreeview, so laz.virtualtreeview was added to staticpackages.inc, which is included in the uses clause and leading to duplicate units in the uses clause. If some functionality of the IDE uses laz.virtualtreeview then the IDE should properly list a depencency on that package, instead of adding it hardcoded in the IDE uses clause. As soon as a user installs the package in question (s)he will have the same error as I did. I removed the duplicates and pushed the change. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] version `GLIBC_2.34' not found error when running app on different PC
On Fri, 17 Mar 2023, Bo Berglund via lazarus wrote:
On Fri, 17 Mar 2023 08:43:55 +0100 (CET), Michael Van Canneyt via lazarus
wrote:
FPC has not changed. It still works the same.
Everything that is under control of FPC is linked statically.
But a complex GUI system like the LCL uses GTK/GDK/Qt and other libraries,
and those are dynamic, external libraries over which FPC or lazarus has no
control.
This aplication is a console (i.e NO GUI) application and it only uses these
units:
videosplitcmb.lpr:
uses
{$IFDEF UNIX}
cthreads,
{$ENDIF}
Classes,
{ you can add units after this }
sysutils,
utils,
runthread;
and
utils.pas:
uses
Classes,
SysUtils,
Process;
What is complex here?
cthreads. The name says it all: C threads. It uses the C library.
See:
https://www.freepascal.org/docs-html/rtl/cthreads/index.html
If you use a unit that relies on LibC somewhere, you automatically depend on
the libc
version.
Since I am only using FPC units, how can I know???
You want to say that you don't even know what the units do that you are using ?
You have no idea how scary that is to me...
Michael.
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] version `GLIBC_2.34' not found error when running app on different PC
On Fri, 17 Mar 2023, Bo Berglund via lazarus wrote: On Fri, 17 Mar 2023 08:53:01 +0300, Mehmet Erol Sanliturk via lazarus wrote: Some portability is obtained if the libraries are linked as "static" . If "dynamic" linking is selected , during execution of the program , the "same" library should be in the executing computer . How is this accomplished in Lazarus? You need to change the units that refer to other libraries so they use static linking. Does this change happen randomly or is it connected to the major Ubuntu releases like going from 20.04 to 22.04 rather than just keeping 20.04 up-to-date? It is unpredictable, but will mostly happen in major releases of linux distributions. It implies having to build applications on as old a system as ever possible, maybe using 16.04 or earlier just for making apps that can run on all systems, is that really true? No, this will not help you, as then you will have another problem: old libraries installed on such systems may not exist on newer systems. It makes no sense to me... Why not ? It's perfectly simple. Distributions changed the libraries which they ship, and the libraries are no longer compatible. And from https://wiki.freepascal.org/Lazarus/FPC_Libraries -- Static linking FPC compiles and links a static executable by default. That means it tells the linker to put all .o files of the project and all packages into one big executable. Advantages: No external dependencies. Disadvantages: No code is shared between different programs on the same computer. You can not load/unload a plugin. --- This idea was always why I liked Delphi when it came along in 1995 or so, just build an executable and it could be run everywhere. This is also why I liked FreePascal when it appeared because I did not need to bother with distributing extra files all over the place. So why has it changed now and how can I get around it? FPC has not changed. It still works the same. Everything that is under control of FPC is linked statically. But a complex GUI system like the LCL uses GTK/GDK/Qt and other libraries, and those are dynamic, external libraries over which FPC or lazarus has no control. If you use a unit that relies on LibC somewhere, you automatically depend on the libc version. Developing on an up-to-date system should ensure the output could work everywhere, but not so now it appears No-one can ensure this. It was never so. It used to be worse in the past. Distributions change, and sometimes break binary compatibility. This means you must cater for that. There are roughly 2 ways: - Compile on a system that has the correct version of libraries as on the target computer. - Distribute the needed libraries with your executable. I cannot find any setting for this in Lazarus. This cannot be solved with some setting. Notice: This is a command line utility so it needs no access to any GUI components at all... You use libc through some unit that is included in your sources. The libc library on both systems you tested on differ too much, that is why you have the error. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] small issue
On Thu, 2 Mar 2023, John Landmesser via lazarus wrote: if i try to compile an application with qt5 LCLwidgetType i get an error messages and thats ok: Error: /home/john1/lazarus/lcl/interfaces//qt5/qtobject.inc:43: undefined reference to `QGuiApplication_setFallbackSessionManagementEnabled' Alter_berechnen.lpr(20,1) Error: Error while linking *BUT:* The Lazarus IDE writes strange files that i have to delete myself: Actuall, this is written by the FPC compiler. link1622848.res Is that worth to write a bug report? No. The file is left on purpose to be able to analyze the problem or to manually call the linker. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] questioning ARequest: TFPHTTPConnectionRequest :)
On Sun, 26 Feb 2023, duilio foschi via lazarus wrote: my simple BE server uses this function to handle all inbound calls: procedure TTestHTTPServer.HandleRequest( var ARequest: TFPHTTPConnectionRequest; var AResponse: TFPHTTPConnectionResponse ); When the call is a POST, I want to read the json payload inside ARequest. I expected to find a property like Body:string inside TFPHTTPConnectionRequest, but I could not find it. The property is called Content. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] db grid/dataset components that only load currently visible records?
On Fri, 24 Feb 2023, Luca Olivetti via lazarus wrote:
El 23/2/23 a les 17:16, Michael Van Canneyt ha escrit:
write a TDataset descendant tailor made for this
application, any pointer on how to write a minimal descendant?
I'm looking at the TMemDataset implementation as an example, is it a good
one?
As good as any other.
The idea is to substitute open and scrolling (next/prior/locate/etc.) with
the appropriate sql statements to just retrieve a small buffer of data
around the current record (I can do that easily enough), though I'm not
sure that would be enough to fool the TDBGrid.
I don't know what the grid exactly does, so I cannot advise.
I did some tests and the grid is not a problem (it only fetches the records
that are visible), the TDataset is: either I am blind or the only way for
the TDataset to realize there is data is to fetch every record and allocate
the corresponding buffers.
That's because FRecordCount/FBof/FEof are private
FRecordCount is the number of records in internal buffers,
and has nothing to do with the total number of records.
The total RecordCount must be given by TDataset descendents,
but defaults to FRecordCount in TDataset itself.
The terminology is confusing, I know.
We should probably rename FRecordCount to FBufferRecordCount.
procedure TDataSet.DoInternalOpen;
begin
InternalOpen;
FInternalOpenComplete := True;
{$ifdef dsdebug}
Writeln ('Calling internal open');
{$endif}
{$ifdef dsdebug}
Writeln ('Calling RecalcBufListSize');
{$endif}
FRecordCount := 0;
RecalcBufListSize; <-- this will fetch all the records
FBOF := True;
FEOF := (FRecordCount = 0); <--- FRecordCount must be set
end;
No.
RecalcBufListSize does not necessarily fetch all the records. It fetches as
much records as needed: 10 by default, but classes such as TDBGrid may set
the number of needed records to the number of visible grid lines.
It can be that TBufDataset fetches all records on open, there is a property that
controls this. But it can also fetch on an as-neede basis.
FEOF is simply initialized from the first batch.
But it is maintained based on the result of GetNextRecord.
Check the MoveBy procedure.
Only when GetNextRecord returns false, is FEOF set to True (line 2005).
There's no point overriding
GetNextRecords/GetNextRecord/GetPriorRecords/GetPriorRecord (called by
RecalcBufListSize) since I cannot directly modify the private fields of the
TDataSet.
You don't need to modify them. They are automatically maintained based on
the result of GetNextRecord. TDataset is responsible for maintaining a
correct state based on what descendants return in the methods they override.
Exposing these internal state fields for modification means TDataset cannot
guarantee the correct state, and therefore that will not happen.
Any idea?
Personally, I believe you are on the wrong path by wanting to modify TDataset or
its descendants.
But if you want to pursue that track, study TDataset a little more and ask questions.
It is a complex class, one of the most complex in the whole FCL.
Michael.
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] db grid/dataset components that only load currently visible records?
On Thu, 23 Feb 2023, Luca Olivetti via lazarus wrote: El 23/2/23 a les 13:52, Michael Van Canneyt via lazarus ha escrit: On Thu, 23 Feb 2023, Luca Olivetti via lazarus wrote: El 23/2/23 a les 11:11, Michael Van Canneyt via lazarus ha escrit: But IMO: in the first place you should ask yourself if displaying 10.000 records is what you actually want to do. No, I just need to display 20 or so records, the problem is I'd like the user to be able to scroll over the whole table, so I'd have to hook a lot of events in the TDBGrid (if that's even possible, otherwise I'd have to implement a replacement) and get rid of the TDBNavigator and implement a custom one in its place. The LCL could do with a pager component. Seems to be standard when Web pages display grids/tables, so users should be used to it :-) Even if such a component existed, I don't think it would fit my use-case. Why do you think so ? Paging is exactly what you want to do. Maybe I should just write a TDataset descendant tailor made for this application, any pointer on how to write a minimal descendant? I'm looking at the TMemDataset implementation as an example, is it a good one? As good as any other. The idea is to substitute open and scrolling (next/prior/locate/etc.) with the appropriate sql statements to just retrieve a small buffer of data around the current record (I can do that easily enough), though I'm not sure that would be enough to fool the TDBGrid. I don't know what the grid exactly does, so I cannot advise. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] db grid/dataset components that only load currently visible records?
On Thu, 23 Feb 2023, Luca Olivetti via lazarus wrote: El 23/2/23 a les 11:11, Michael Van Canneyt via lazarus ha escrit: But IMO: in the first place you should ask yourself if displaying 10.000 records is what you actually want to do. No, I just need to display 20 or so records, the problem is I'd like the user to be able to scroll over the whole table, so I'd have to hook a lot of events in the TDBGrid (if that's even possible, otherwise I'd have to implement a replacement) and get rid of the TDBNavigator and implement a custom one in its place. The LCL could do with a pager component. Seems to be standard when Web pages display grids/tables, so users should be used to it :-) Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] db grid/dataset components that only load currently visible records?
On Thu, 23 Feb 2023, Luca Olivetti via lazarus wrote: El 23/2/23 a les 9:43, Michael Van Canneyt via lazarus ha escrit: Something like this: https://docwiki.embarcadero.com/RADStudio/Rio/en/Browsing_Tables_(FireDAC)#Live_Data_Window_Mode This is not something that the grid handles. This is a dataset feature. Yes, I supposed so At this moment I know of no FPC/Lazarus dataset component that handles this automatically. bummer :-( Note the remark on that page: "Although FireDAC minimizes the number of generated and executed SQL commands in LDW mode, it still produces a heavier DB load than TFDQuery. So, application developers should carefully choose when to use TFDTable and LDW mode. " This is exactly why FPC does not have a database table component. It's horribly inefficient. OTOH a TDBGrid is a very convenient way to display data. I my application I just use it to display (in read-only mode) an sqlite table that holds less than 1000 records and it could be updated quite frequently (hence the need for the frequent TDataset.refresh), and it works fast enough with that limited amount of records. Now I need to expand the table to 1 records and the performance is unacceptable. The best way is to use "limit N offset M" in your query and use a paging mechanism. Make sure you sort the records, obviously. But IMO: in the first place you should ask yourself if displaying 10.000 records is what you actually want to do. Maybe your application is better off with some filtering ? Michael.-- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TFPHTTPServer
On Thu, 23 Feb 2023, duilio foschi via lazarus wrote: I wrote a simple server using TFPHTTPServer. All incoming calls are processed using procedure HandleRequest(var ARequest: TFPHTTPConnectionRequest; var AResponse: TFPHTTPConnectionResponse); My first tests were ok and encouraging but... how do I know if the call was a GET or a POST? I guess that ARequest "knows" it, but I cannot find a way to ask :) Try ARequest.Method, this is the HTTP method string as sent by the client. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] db grid/dataset components that only load currently visible records?
On Thu, 23 Feb 2023, Luca Olivetti via lazarus wrote: El 23/2/23 a les 9:04, Luca Olivetti via lazarus ha escrit: Hello, do you know of any component/dataset combo that works like a TDBGrid but doesn't load all the records from the db when doing a refresh, just the ones that are currently visible, yet offering seamless scrolling? I looked in the wiki but I couldn't find any. Something like this: https://docwiki.embarcadero.com/RADStudio/Rio/en/Browsing_Tables_(FireDAC)#Live_Data_Window_Mode This is not something that the grid handles. This is a dataset feature. At this moment I know of no FPC/Lazarus dataset component that handles this automatically. Note the remark on that page: "Although FireDAC minimizes the number of generated and executed SQL commands in LDW mode, it still produces a heavier DB load than TFDQuery. So, application developers should carefully choose when to use TFDTable and LDW mode. " This is exactly why FPC does not have a database table component. It's horribly inefficient. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus and FreePascal version relations on Linux and Windows?
On Wed, 22 Feb 2023, Bo Berglund via lazarus wrote: I have used Lazarus on Windows and Linux many years and I have built the Linux versions from sources but used the official installer for Windows. On Linux I have had parallel versions of Lazarus but usually the same FPC and this has worked fine. I think that on Linux the FPC becomes a global version and then new Lazarus gets confused... On Windows the installer separates the complete package into a separate directory which contains both Lazarus and FPC and none is put on system path. So when I have say 6 different versions of Lazarus on Windows they are all separate and do not conflict with each other. Now I am having problems installing Lazarus 2.2.4 on Linux systems where older Lazarus version exist because they use an older FPC which the new Lazarus cannot use (3.0.4 vs 3.2.2). On Linux FPC is put on path and so the instant one installs 3.2.2 on a system already using 3.0.4 disaster follows... On my home PC, I have 16 FPC versions installed, and 4 or 5 different lazarus systems. (in fact, a single lazarus installation, just with different --pcp options) Yet I experience none of the problems that you experience. The only thing that is different from a default setup is that I make symlinks /usr/local/bin/ppcx64-3.2.2 -> /usr/local/lib/fpc/3.2.2/ppcx64 (similar for the other tools) A lazarus install always refers to a versioned ppc/fpc tool. What we could possibly do is to install fpc with the version numbers suffixed, and an extra symlink to the current version without suffix. This way, when you install a newer version, the old version is still available. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Conditional Debugger breakpoints not working ?
On Mon, 20 Feb 2023, Martin Frb via lazarus wrote: On 20/02/2023 13:46, Michael Van Canneyt via lazarus wrote: I suggest you adapt the wiki to clarify all this. While you're at it, The link in the wiki page to the gdb convenience functions is broken. updated In general, I don't think you can expect the user to know that he should use $_streq(myvar, "hello"), specially the cmem condition that seems necessary. Ideally, the IDE could detect a string and transform the expression. This always has been the issue with gdb. If you had a watch with anything but just a plain variable name, then gdb may give you: - an error, - or an incorrect result, - or the correct result For watches, there is quite a lot of code in the IDE to try and fix those things. There are testcases, that can be run with different debug-info, and diff gdb versions. (And they run for many hours / and unfortunately still have some errors, some false errors...). But there is no way to get to 100%. In many cases gdb simple does not give enough info to detect the necessary information on the underlaying type. (And when trying to get this, one has to be carefully not to crash gdb). Also it makes evaluating each individual watch a lot slower (at least factor 3 or 4). Though on that I have always pushed the point that a "correct result" is worth *any* wait time. Yes. An incorrect result may result in infinite wait time :-) In any case, with conditional breakpoints it would be even more complex It would be nice to have, but with the availability of FpDebug, it is very unlikely that will be fixed. (There are simply a lot of other things that (should) have more priority) I may add a warning to the breakpoint dlg, that for non-fpdebug will display a red TLabel below the input, with some text that the condition may not work at all. I think this is a good idea. It is a problem on Mac, with LLDB. Though I am not even sure that conditional breakpoint are supported at all... They are: https://stackoverflow.com/questions/37204551/lldb-setting-conditional-breakpoint-with-string-equality-as-condition LLDB probably can do them (with restrictions like gdb). But the IDE has absolutely on code to translate "pascal to lldb" => because for watches it can evaluate with fpdebug. But conditional breakpoints must be done by lldb, or they become very very slow. (That is if they need to pass lots of time before they match the condition, and each hit pass 1 second or more, you quickly get to several minutes of wait time) No problem. I realize it is not easy to solve generally, although a solution for 'simple' strings would be welcome. I'll stick to poor man's conditionals. Then the compiler will tell me what I do wrong :) Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Conditional Debugger breakpoints not working ?
On Mon, 20 Feb 2023, Martin Frb via lazarus wrote: On 20/02/2023 12:31, Michael Van Canneyt via lazarus wrote: I'm trying to set a condition on a breakpoint. I have a local variable aUnit, type string: var aUnit : string; I wish the breakpoint is only triggered when aUnit equals 'termio'. So, in the breakpoint properties dialog, I enter the condition: aUnit='termio' It seems to have no effect whatsoever. The breakpoint is triggered always at the first traversal of the line. I tried variations (uppercase, lowercase) , but to no avail. Looking at the debug internals window, I see that the expression is only (correctly) evaluated by gdb when I move the mouse over the identifier in the sources: (gdb) gdb doesn't know pascal strings, or how do an "=" operation on them. You can try to get $_streq(myvar, "hello") to work https://sourceware.org/gdb/onlinedocs/gdb/Convenience-Funs.html Or use FpDebug. FpDebug can compare strings. I suggest you adapt the wiki to clarify all this. While you're at it, The link in the wiki page to the gdb convenience functions is broken. In general, I don't think you can expect the user to know that he should use $_streq(myvar, "hello"), specially the cmem condition that seems necessary. Ideally, the IDE could detect a string and transform the expression. Michael.-- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Conditional Debugger breakpoints not working ?
Hi,
I'm trying to set a condition on a breakpoint.
I have a local variable aUnit, type string:
var
aUnit : string;
I wish the breakpoint is only triggered when aUnit equals 'termio'.
So, in the breakpoint properties dialog, I enter the condition:
aUnit='termio'
It seems to have no effect whatsoever. The breakpoint is triggered always at
the first traversal of the line.
I tried variations (uppercase, lowercase) , but to no avail.
Looking at the debug internals window, I see that the expression is
only (correctly) evaluated by gdb when I move the mouse over the identifier
in the sources:
(gdb)
&"ptype AUNIT\n"
~"type = ^Char\n"
^done
(gdb)
&"ptype AUNIT^\n"
~"type = Char\n"
^done
(gdb)
&"whatis AUNIT\n"
~"type = ANSISTRING\n"
^done
(gdb)
<-data-evaluate-expression AUNIT>
^done,value="0x77f73b18 'si_prc'"
(gdb)
So it can correctly evaluate the value aUnit.
The question is, why is it ignoring my condition ?
After some digging in the gdb output I find this:
&"Error in testing breakpoint condition:\n"
&"evaluation of this expression requires the program to have a function
\"malloc\".\n"
Hm. No mention of this in:
https://wiki.lazarus.freepascal.org/Debugger_Setup
https://wiki.lazarus.freepascal.org/IDE_Window:_Breakpoints#Breakpoint_properties
OK, File under 'undocumented' and ignore for the time being, but I add cmem unit
to my program.
Seemingly, gdb now accepts the breakpoint condition:
<-break-insert "\"/home/michael/domakefile.lpr\":161">
^done,bkpt={number="7",type="breakpoint",disp="keep",enabled="y",addr="0x00401fe7",func="ADDRECIPE",file="domakefile.lpr",fullname="/home/michael/domakefile.lpr",line="161",thread-groups=["i1"],times="0",original-location="/home/michael/domakefile.lpr:161"}
(gdb)
<-break-condition 7 AUNIT="termio">
^done
(gdb)
<-break-enable 7>
^done
That makes it even worse: the breakpoint is simply never observed.
If I do a poor man's conditional breakpoint:
if (aUnit='termio') then
Writeln('Aloha'); <-- set breakpoint on this line
and run, I see that unit 'termio' is definitely encountered.
So, "Houston, we have a problem..."
Suggestions, things I maybe forgot ?
Michael.
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Folding ?
On Sun, 19 Feb 2023, Martin Frb wrote:
On 19/02/2023 19:06, Michael Van Canneyt wrote:
On Sun, 19 Feb 2023, Martin Frb via lazarus wrote:
On 19/02/2023 12:28, Michael Van Canneyt via lazarus wrote:
Hi,
Is it possible to enable/disable code folding on a per-language basis ?
No, or only in the way you described below. Or by changing the source in
each highlighter, and make the pretend they don't fold.
That seems a strange way. Since folding can be globally switched on and
off, it should also be
possible to switch it on/off on a language basis.
Well, it just hasn't been implemented. There is no reason not to add it, if
someone wants to do it.
To entertain my lack of imagination: What is the issue, if e.g. Pascal shows
fold indicators, and you just don't use them?
For starters, some people think adding
{%region /fold}
to the code is a good idea. I think not.
Secondly, I sometimes inadvertently click on the fold markers.
The above 2 reasons are why I disabled it. Also, I think that if you need
folding in Pascal, your code is not very well structured. As a general rule,
I think a procedure may not occupy more than 50 lines. If you adhere to
that, folding is simply not needed.
(strictly my personal opinion)
In any case, there also remains the "fold selected lines" folding.
That would defeat the purpose. I use the folding to see if the HTML tags
are closed properly without having
to select them.
You don't have to select them.
If you do select text, the gutter will show an additional fold (actually
"hide") symbol, allowing you to collapse whatever text is selected.
Btw, folding may not be the best way to check for correct html nesting.
IIRC, the highlighter tries to find a matching-name closing tag, even if that
means to skip other tags.
No doubt. But there are other uses: in large html structures (HTML can be
very verbose in some CSS frameworks, there is no way around it) ,
it helps to be able to see the larger structure.
Ideally, the fold indicators are also not visible in HTML/XML,
but I can simply right-click a div and ask to collapse/expand that div.
Michael.--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Folding ?
On Sun, 19 Feb 2023, Martin Frb via lazarus wrote: On 19/02/2023 12:28, Michael Van Canneyt via lazarus wrote: Hi, Is it possible to enable/disable code folding on a per-language basis ? No, or only in the way you described below. Or by changing the source in each highlighter, and make the pretend they don't fold. That seems a strange way. Since folding can be globally switched on and off, it should also be possible to switch it on/off on a language basis. In any case, there also remains the "fold selected lines" folding. That would defeat the purpose. I use the folding to see if the HTML tags are closed properly without having to select them. Michael.-- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Folding ?
Hi, Is it possible to enable/disable code folding on a per-language basis ? I would like to enable it only for HTML/XML and disable for all other languegs. (I'd add JSON, but there is no language JSON in the IDE ;), Currently it seems you can only do this by enabling code folding globally, and then disable it for all constructs in all languages except the ones you want... But it can be that I missed the option somewhere... Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Format an integer with thousandseparators by function format()
On Fri, 17 Feb 2023, John Landmesser via lazarus wrote: Hi, this one works, but i don't know why to devide the integer by 1: fmt := '%.0n'; s1 := Format(fmt,[MyInteger/*1*]); Because the result of the division is a float; not an integer. And %n will only format a float, not an integer. Michael.-- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Porting Delphi (2007/XE5) application, how to handle ADODB?
On Fri, 10 Feb 2023, Bo Berglund via lazarus wrote:
On Mon, 23 Jan 2023 09:59:14 +0100 (CET), Michael Van Canneyt via lazarus
wrote:
On Mon, 23 Jan 2023, Bo Berglund via lazarus wrote:
I have a number of "older" applications developed on Windows using
Delphi7-2007-XE5, which use ADODB for database accesses.
The database is Microsoft SQLSERVER.
Now I no longer have the old Borland software installed (issues with Windows 10
etc) so I want to port the projects to FPC/Lazarus.
I have ported some other non-database applications which (with some effort)
seems to have worked out OK.
Now I am facing the challenge of doing it on an adodb database enabled
application and I would like to know if there is some "compatible" way of doing
it, which is described somewhere?
Yes.
You need to use SQLDB, and the TMSSQLConnection.
See https://wiki.freepascal.org/SQLdb_Tutorial1 for a simple explanation.
The page https://wiki.freepascal.org/SQLdb_Package also contains some
explanations
for setup.
There are some other pages in the wiki.
A more in-depth explanation is in the lazarus book.
Or you can look at
https://www.freepascal.org/~michael/articles/
several articles discuss SQLDB, in particular:
https://www.freepascal.org/~michael/articles/lazviddb/lazviddb.pdf
That should be enough to get you started.
Michael.
Thanks!
Almost there but not quite...
I am using Lazarus 2.2.4 with fpc 3.2.2 on a Windows 10 box.
The application seems to have been converted pretty well using the Lazarus
Delphi Conversion function to migrate from Delphi with some extra defines
needing adjustments. But these have been minor considering the size of the
application.
But the ADODB conversion is now halted on the TSqlQuery and TMSSQLConnection
items which operate so differently from ADODB...
I added this in uses:
mssqlconn, //Had to add this in order to use TMSSQLConnection
sqldb,
This made the code pass the defines of the objects:
TAppDbHandler = class
private
FConn: TMSSQLConnection; // TADOConnection;
FQuery: TSQLQuery;// TADOQuery;
FDatabaseServer,
FDatabase,
FConnString,
FDbUser,
FDbPassword,
FUserName,
FUserPassword: string;
But next I get a lot of errors because of the differences between this and the
Delphi ADODB we used before.
I got lost here...
constructor TAppDbHandler.Create;
begin
FConn := TMSSQLConnection.Create(NIL); //was: TADOConnection.Create(NIL);
FQuery := TSQLQuery.Create(NIL); //was: TADOQuery.Create(NIL);
FQuery.Connection := FConn; //<== Triggers an error
FQuery.Database:=FConn;
FDatabaseServer :=
ReadRegString(HKEY_CURRENT_USER,'Software\...\AppManager','DatabaseServer','servername');
FDatabase :=
ReadRegString(HKEY_CURRENT_USER,'Software\...\AppManager','Database','APPMANAGER');
FConnString := 'Provider=SQLOLEDB.1;Persist Security Info=False;' +
'Network Library=DBMSSOCN;Data Source=' + FDatabaseServer + ';'
+
'Initial Catalog=' + FDatabase;
FDbUser := '';
FDbPassword := '';
end;
Is there some example which does not use component drag-drop and properties
settings in the GUI but does all of it in code towards MSSQLserver?
Try this:
FConn.DatabaseName:=FDatabase;
FConn.HostName:=FDatabaseServer;
FConn.Params.Add('Provider=SQLOLEDB.1');
FConn.Params.Add('Persist Security Info=False');
FConn.Params.Add('Network Library=DBMSSOCN');
FConn.UserName:=FDbUser;
FConn.PasswWord:=FDBPassword;
it is all pretty generic. I am not sure that the Params are needed, they
look more like some ODBC/ADO specific things. The MS-SQL connection of Free
Pascal does not use ODBC/ADO. So I would start without the params,
only add them if it does not work without them.
One thing: make sure your SQL server accepts TCP/IP connections.
You must do this in the Microsoft Management Console.
Google is your friend there.
Michael.
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] odbc driver
On Mon, 6 Feb 2023, Larry Dalton via lazarus wrote:
Using lazrus 2.2 ORC1-fpc-3.2.2-win64
error message: Project MyAccessPractice raised exception class
EODBCException with message
'Could not connect with connection string'DRIVER=[Microsoft Access
Driver(*.mdb,*.accdb)];
DBQ=C:\Lazarus_MSAccess\MyAccess.accdb;' ODBC error details:
LastReturnCode:SQL-ERROR;Record1:SqlState:IM4002;NativeError 0;
Message:[Microsoft][ODBC Driver Manager] Data source name not found and no
default driver specified;
Here is the code, copied from internet
unit AccessUnit;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils, odbcconn, SQLDB, DB, Forms, Controls, Graphics,
Dialogs,
DBGrids, StdCtrls;
type
{ TForm1 }
TForm1 = class(TForm)
Button1: TButton;
DataSource1: TDataSource;
DBGrid1: TDBGrid;
Label1: TLabel;
ODBCConnection1: TODBCConnection;
SQLQuery1: TSQLQuery;
SQLTransaction1: TSQLTransaction;
procedure Button1Click(Sender: TObject);
private
public
end;
var
Form1: TForm1;
implementation
{$R *.lfm}
{ TForm1 }
procedure TForm1.Button1Click(Sender: TObject);
begin
ODBCConnection1.Driver:='Microsoft Access Driver (*.mdb,*.accdb)';
ODBCCOnnection1.params.add('DBQ='+ExtractFilePath(Application.ExeName)+'MyAccess.accdb');
This should probably be
ODBCCOnnection1.DatabaseName:=ExtractFilePath(Application.ExeName)+'MyAccess.accdb';
Michael.
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Porting Delphi (2007/XE5) application, how to handle ADODB?
On Mon, 23 Jan 2023, Bo Berglund via lazarus wrote: I have a number of "older" applications developed on Windows using Delphi7-2007-XE5, which use ADODB for database accesses. The database is Microsoft SQLSERVER. Now I no longer have the old Borland software installed (issues with Windows 10 etc) so I want to port the projects to FPC/Lazarus. I have ported some other non-database applications which (with some effort) seems to have worked out OK. Now I am facing the challenge of doing it on an adodb database enabled application and I would like to know if there is some "compatible" way of doing it, which is described somewhere? Yes. You need to use SQLDB, and the TMSSQLConnection. See https://wiki.freepascal.org/SQLdb_Tutorial1 for a simple explanation. The page https://wiki.freepascal.org/SQLdb_Package also contains some explanations for setup. There are some other pages in the wiki. A more in-depth explanation is in the lazarus book. Or you can look at https://www.freepascal.org/~michael/articles/ several articles discuss SQLDB, in particular: https://www.freepascal.org/~michael/articles/lazviddb/lazviddb.pdf That should be enough to get you started. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Debugging the unicode RTL
On Sun, 22 Jan 2023, Martin Frb via lazarus wrote: On 12/01/2023 11:26, Michael Van Canneyt via lazarus wrote: It needs to determine the definition of "string" which will be an array of unicodechar or ansichar. Once it knows that, the rest will follow, since the definition of unicodechar or ansichar will have the correct size. The big issues is still, that dwarf does not make any (official/documented) diff between PChar, string and array of char. Except for internal encoding details Since the PChar/Char types are now an alias, logically the debug info should only have references to AnsiChar/UnicodeChar. But I have no idea how to test this assumption. I don't think this is a very reliable method. In moderately difficult code, half of the time the codetools don't work properly, so relying on them to provide this info is a recipe for disaster. Hence my question... The debugger does and should not relay on codetools. Well, there is a case where codetool helps preparing If you add a watch (or hover for a hint), codetool will determine the boundaries of the expression. So "foo.bar" will not just add bar, but the correct term. Or "foo.bar[x.y]" if you hover on y, will get x.y, but if you hover on "]" will get the full term. And codetool will resolve "with" at that time. But that is it. And it should be it. We are 100% agreed on that, hence my questions. So, if I understand you correctly: The problem is now to see if the debugger can determine from the available debug info/rtti whether the RTL uses AnsiChar or UnicodeChar. Which still leaves the question: What to do if there is no debug info for the system unit ? By default, FPC distributes units without debug info. As far as I know, TObject does not have any RTTI associated with it. Michael.-- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Debugging the unicode RTL
On Sun, 22 Jan 2023, Martin Frb via lazarus wrote:
On 12/01/2023 10:42, Michael Van Canneyt via lazarus wrote:
- Debugging programs works in general quite OK, except for displaying of
some strings. Most notable, the exception message is affected:
only the first character of the exception message is shown.
This is hardcoded, and may be change-able, if debug info is avail.
With a look at the next paragraph below
If
Exception = class end
is available (ideally within the correct unit, so the debugger can
distinguish it from some user declared type), then the debugger could
use this.
Ideally it will by in unit system/sysutils.
Sorry, I don't understand at all what you are saying here.
NOTE:
On Linux, such symbols are referenced cross units. But on Windows they
are repeated in every unit using them. That again makes it harder to
know if it is the correct type (since the user may have its own type by
the name).
?
But for debugging this is not enough: I think the IDE debugger needs
another mechanism to determine using whether a program uses a unicode
RTL or not. The way this happens in code is {$IF SIZEOF(CHAR)=2}
I don't think the debugger should have or need such a "global" flag.
Currently if it looks at a string (and there is dwarf debug info), then
the dwarf contains the size-of-char: 1 or 2.
And the debugger does utf8 or utf16 (the latter may be buggy).
I have meanwhile established that it has some problems:
I have the impression that PChar is hardcoded in some places to mean UTF8.
See below.
Joost even added code to read the hidden encoding field of strings.
Though this relies on being able to detect
PChar <> String <> array of char
which is a PITA.
Important remark: Make it a habit not to use Char any more.
It no longer exists as a type. It is an alias to AnsiChar or Wide/UnicodeChar.
So be specific: use AnsiChar or UnicodeChar (and their pointer variants).
For code that does not care whether it is 1 or 2-byte, you can still use char.
But for such low-level things as a debugger, the use of "char" and "pchar"
is IMO absolutely forbidden.
1/ Should the compiler provide some symbol in - say - the system unit
to deterine
whether the RTL is compiled in unicode mode, or is another mechanism
preferred to do this ?
I don't think that is useful.
Better find the individual places that go wrong, and fix them.
As I said, Exceptions are hardcoded (and IIRC not even in FpDebug, but
in LazDebuggerFp).
They could/should first search for the type "Exception"
That seems prudent, yes :-)
2/ Where can I find the code that extracts the message from an exception
object ? So I can have a shot at trying to fix the display.
unit FpDebugDebugger;
procedure TFpDebugDebugger.HandleSoftwareException
// Get address of object
if not
FDbgController.DefaultContext.ReadUnsignedInt(FDbgController.CurrentProcess.CallParamDefaultLocation(0),
SizeVal(SizeOf(AnExceptionObjectLocation)), AnExceptionObjectLocation)
then
ExceptionMessage :=
ReadAnsiString(AnExceptionObjectLocation+DBGPTRSIZE[FDbgController.CurrentProcess.Mode]);
That currently does not yet have the read of the "encoding" field.
From what I know, a unicode string does not have an encoding field. So this
code will need some changes.
What about:
TSomeClass.Classname
is that utf16 too?
No. It remains shortstring.
Because the debugger reads it for automatic class casting
Any other changes in the RTTI where things switched to 16 bit?
None spring to mind.
Michael.--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Debugging the unicode RTL
On Thu, 12 Jan 2023, Sven Barth via lazarus wrote: Michael Van Canneyt via lazarus schrieb am Do., 12. Jan. 2023, 10:42: 1/ Should the compiler provide some symbol in - say - the system unit to deterine whether the RTL is compiled in unicode mode, or is another mechanism preferred to do this ? "Char" already is such a symbol that the debugger can and must use to determine this. And if no debug information for aliases is created then *that* needs to be fixed instead. In earlier discussions I was told Type Char = UnicodeChar; Var C : Char; means 'replace char with unicodechar'. So in the final binary only the effect of the declaration var C : unicodechar ; will be seen. Which is IMO the only correct behaviour. If you want a different type you need to do Type Char = Type Unicodechar; which creates 2 distinct types which are assignment compatible. This will lead to other problems. I also don't think the debugger needs to be able to determine the definition of "char". It needs to determine the definition of "string" which will be an array of unicodechar or ansichar. Once it knows that, the rest will follow, since the definition of unicodechar or ansichar will have the correct size. But the debugger also needs to be able to determine Unicode vs. ANSI if no debug information for the System unit is available thus it needs to rely on CodeTools then and what *that* provides for Char. I don't think this is a very reliable method. In moderately difficult code, half of the time the codetools don't work properly, so relying on them to provide this info is a recipe for disaster. Hence my question... Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Debugging the unicode RTL
Hello,
As written in other mails, I'm currently working on the Unicode RTL of FPC.
Debugging programs using the unicode RTL is possible, but not comfortable:
I have currently identified 2 problems in Lazarus which make debugging such
programs difficult:
- The IDE does now know the -tSUBTARGET option.
This means that it does not correctly identify the IFDEF paths in source
code, as it didn't correctly parse all config files.
- Debugging programs works in general quite OK, except for displaying of
some strings. Most notable, the exception message is affected:
only the first character of the exception message is shown.
It seems to me obvious that the IDE needs to be aware of the -t option.
But for debugging this is not enough: I think the IDE debugger needs
another mechanism to determine using whether a program uses a unicode RTL or not.
The way this happens in code is
{$IF SIZEOF(CHAR)=2}
// unicode RTL code.
{$ELSE}
// Ansi rtl code.
{$ENDIF}
Obviously, this is of no use in the debugger. The subtarget name is also
not usable, since any subtarget definition can specify that the RTL should
be unicode.
Questions:
1/ Should the compiler provide some symbol in - say - the system unit to
deterine
whether the RTL is compiled in unicode mode, or is another mechanism
preferred to do this ?
2/ Where can I find the code that extracts the message from an exception
object ? So I can have a shot at trying to fix the display.
Michael.
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Unicode RTL for FPC
On Thu, 12 Jan 2023, Rolf Wetjen via lazarus wrote: Hi Michael, I'm interested in this but I expect that I'm not the expert you are looking for. Some time ago ( Lazarus 1.8 or even earlier) I made a directory sync program for my own use for Windows which is aware of Unicode names in the file system. Free Pascal is already aware of these names ? If you use UnicodeString, all file system routines will use the native Windows unicode APIs. You don't need the unicode RTL for that, however you will need to convert the names to UTF8 for display in the lazarus GUI, as it uses UTF8. I tried to follow your instruction but I failed as git is a pain for me: - Update your git clone git pull https://gitlab.com/freepascal.org/lazarus/lazarus.git lazarus. "lazarus" is my target folder. - switch to branch unicodertl git branch --list gives only one branch: main Can you please show in detail what to do? Lazarus itself at this point has not been adapted. The instructions were meant for Free Pascal itself, not lazarus. If you want nonetheless to try FPC: - Create .fpc-unicodertl.cfg as per instructions in my first mail. - update/clone fpc git clone https://gitlab.com/freepascal.org/fpc/source.git fpc - Switch to unicode branch: git switch unicodertl - Create FPC unicode-rtl-capable compiler cd fpc make all - Optionally, install this compiler: make install - Use the compiler to create unicode rtl: cd rtl make clean all SUB_TARGET=unicodertl PP=/path/to/newly/compiled/compiler Do you plan a full Unicode (up to four bytes per codepoint as far as I remember) or a DBCS (double byte character set) version? I don't know what Windows uses and what Delphi does. I'm just leveraging the existing UnicodeString support of FPC, which mimics the Delphi/Windows support. I'm not that much of a unicode expert, but as far as I understand it is UTF16, meaning that up to four bytes per codepoint can be used, which means that a full unicode codepoint can take up to 2 pascal characters: the pascal 'Char' can never specify all unicode codepoints. Michael.-- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Unicode RTL for FPC
Hello, I'm currently working for a company (Tixeo.com) that is preparing to use FPC to recompile their flagship product (written in Delphi) for certain targets. As part of this work, we're striving to make the Free Pascal RTL and Packages more compatible with recent Delphis. That means: - String = UnicodeString, Char=WideChar - Dotted units. Before you all get a heart attack: Because backwards compatibility is important, FPC will of course continue to distribute a backwards-compatible RTL and packages, with single-byte string. All FPC modes will continue to function. To make this possible a feature called 'subtargets' has been implemented. This can be used for other things than the unicode RTL, but will be used for the unicode RTL. The RTL is compiled 'normally' and with subtarget=unicodertl; this will result in 2 separate sets of .o/.ppu files: The normal CPU-OS directory and a CPU-OS-unicodertl directory. The first part of the work has been pushed to gitlab in a branch called unicodertl (NOT the svn/unicodertl branch): - subtarget support is there - The rtl compiles with make SUB_TARGET=unicodertl with the compiler as it is in that branch. Needless to say, this is a major change that will need thorough testing. The earlier testing starts, the better. For those that wish to help in testing: - Update your git clone - switch to branch unicodertl. - in the toplevel FPC directory, do a make all - if that went well, next to your fpc.cfg, create a file fpc-unicodertl.cfg with the following contents: -dUNICODERTL -Municodestrings - to create a Unicode RTL, in the rtl directory do a make clean all SUB_TARGET=unicodertl PP=path/to/the/new/compiler - if that worked, you can try then a make install SUB_TARGET=unicodertl Note that this is NOT ready for production use: - The packages have not yet been converted (working on this now) and will certainly fail... - a private testsuite has been run and gives no failures, but the complete compiler testsuite still needs to be examined. - Dotted names will be created after the unicode transition is deemed complete. if you do wish to test and spot errors in the RTL or compiler, please file a bugreport. You can use a tag 'UnicodeRTL' to report bugs for this. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] SynEdit highlighter for Markdown
On Thu, 5 Jan 2023, Andrew Haines via lazarus wrote: Hi, I attached a highlighter I made for Markdown. I like to use this in my projects to plan things. It seems to work fine with any attribute that only requires a single line. I tried and failed to make multiline fenced code work. I'm sure there is just something I wasn't understanding. ``` multiline code block ``` Indenting works though. Nice start, I will add it to my IDE, awaiting the 'official' addition to lazarus :-) Given the many dialects in markdown (specially for multiline/continuation things), it'll be interesting to see how it reacts on them :) Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Instantsearch package
On Thu, 5 Jan 2023, Marcello via lazarus wrote: Hi, I installed the InstantSearch package, really useful, thanks! Search works and is impressive :) While double clicking on fpc/lazarus sources the link works correctly, same action on my project sources fails with this message Source tree 6A01AF16-603C-4AF5-9193-8CB97726549B not found. Please refresh search results. Any idea to help me fix? I looked at it, it should hopefully be fixed. If not, please give me steps to reproduce... Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Instantsearch package
Hello, As a late Christmas gift (and after some deliberation with Mattias Gaertner who provided many helpful remarks), I've added a package to the lazarus IDE: InstantSearch. It provides as-you-type search possibilities, which is much faster than the current find-in-files. For it to work, it needs to index sources. The sources are organized in source trees, and you can define as much "source trees" as you wish. The RTL, FCL, compiler and LCL are added by default. Projects can be marked as 'indexable' and the current project can be indexed & searched as well. Conceivably, other sources of info can be indexed: WIKI, Help, etc... It currently uses "Manticore Search" as a backend (because it has a simple install and interface), but other engines can be added if so desired. More help can be found here: https://wiki.freepascal.org/Lazarus_InstantSearch Should you experience problems, don't hesitate to reach out. Enjoy ! Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Application GUI does not appear
On Mon, 26 Dec 2022, Koenraad Lelong via lazarus wrote: Hi, It's been a while since I did some development with Lazarus. Now I wanted to update an application I wrote some years ago. At that time the application was written and compiled on and for Linux. Now I want that application to run on Windows 11 64bit. I installed the latest Lazarus (2.2.4 64bit) on a Windows 11 machine and copied my sources to that machine. After some struggling with a missing library (libmysql.dll) I managed to run the original application. But I could not see the GUI. Then I discovered I could not modify the forms, I simply can't see them. Pressing F12 does nothing but greying out the caption of the editor. I can see the form of the datamodule though. I used the "Check LFM-file in editor"-tool and that checks OK for the GUI-forms. I added an msgDialog in the on-show routine of the main form and that does show. But when I click that away, nothing shows anymore, just the icon in the task-bar. I created a minimal application and that does work fine. Any Ideas what is happening ? It could be that the support for High-DPI is messing with your forms. If the messagedialog works, it shows that the form is loaded and being shown. Probably it has size zero. So maybe check the form sizes in the lfm file, also check whether a LCLVersion is being streamed. If so, maybe change its value to 2.2.4.0. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Attn. Don, documentation snapshots via CI
On Thu, 15 Dec 2022, Maxim Ganetsky via lazarus wrote: Hello. As a first step of solving outdated documentation snapshot issue (https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40032 ) I propose to generate it as an artifact of CI job (in `main` branch for now), which then can be uploaded wherever we want. So I have the following questions: 1. FPDoc from which FPC version is preferred (from `main` branch I guess)? main. 2. Where rtl.xct and fcl.xct should be obtained? Should FPC documentation be built first? rtl.xct and fcl.xct are generated when the FPC documentation is built. However, note that the documentation of FPC is only updated after a release. so if you use FPC main to generate documentation, it will not match what FPC publishes. 3. Should we build HTML, CHM or both? If it is for upload, then CHM makes no sense to me, but that's up to the lazarus team, obviously... Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Makefile issues
On Fri, 2 Dec 2022, Mattias Gaertner via lazarus wrote: On Thu, 1 Dec 2022 23:22:38 +0100 (CET) Michael Van Canneyt via lazarus wrote: [...] Well, it turns out that "make useride" also does not work on a fresh checkout. It didn't work when Cleaning is enabled. Fixed. [...] But the point of the 'main targets' is taken, so I filed a feature request in the issue tracker to be able to build the LCL using just the Makefile. basically, I would like something as make lcl to produce the LCL units. make registration lazutils lcl Slightly better is: make -J N registration make -J N lazutils make -J N lcl because the order as specified on the command-line is not guaranteed when you do parallel compilation. Still, it feels strange to me that make lcl is not enough, but OK. The problem is that make is pretty dumb, so it creates only a rudimentary Makefile.compiled file. Makefile.compiled does not even come into play, see below. If you use lazbuild or lazarus to compile a project they might decide to recompile the lcl. That may not happen, because the sources will not be installed on the build machine. It would be safer to compile lazbuild, and then use that to compile the lcl. The projects will be compiled with fpc only in a docker environment. The devops people don't want another build tool. Only make. (which is why I wanted to have make install working - but I had to resort to using find and cp manually) The goal is to have just fpc, its units and the LCL units in compiled form in the docker. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Makefile issues
On Thu, 1 Dec 2022, Mattias Gaertner via lazarus wrote: On Wed, 30 Nov 2022 14:35:24 +0100 (CET) Michael Van Canneyt via lazarus wrote: Hello, The lazarus makefile has some dependency issues. make ide: That's an internal target. See "make help". Am I correct in my understanding that in fact only the "main" targets all, bigide, useride are supposed to work out of the box when you start from a fresh checkout ? Yes. Well, it turns out that "make useride" also does not work on a fresh checkout. At least, I could no longer get it to work. see my comment in https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40024 But the point of the 'main targets' is taken, so I filed a feature request in the issue tracker to be able to build the LCL using just the Makefile. basically, I would like something as make lcl to produce the LCL units. (it can be another 'main' target name if that is needed, obviously) Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Makefile issues
On Wed, 30 Nov 2022, Maxim Ganetsky via lazarus wrote: 30.11.2022 16:35, Michael Van Canneyt via lazarus пишет: Hello, The lazarus makefile has some dependency issues. I would recommend to run `make lazbuild` first and then try to proceed again with your commands. Well, the whole idea of a makefile is that you can give any target and it will first build the dependencies for that target, to free the user of the burden to know or guess the dependencies. If target 'ide' depends on target 'lazbuild', it should say so in the dependencies of 'ide'. That said, I followed your suggestion, and then the error is: (1002) Target OS: Linux for x86-64 (3104) Compiling lazarus.pp /home/michael/projects/lazarus-tst/ide/lazarus.pp(57,3) Fatal: (10022) Can't find unit Interfaces used by Lazarus most likely, the LCL needs to be built first as well. In each case, for the moment I simply produced a full build using the 'make bigide' target. I then try to install the result. This installs the IDE. But I also (in fact, only) need the LCL units. So I did make -C lcl install But the 'make install' in the lcl dir also fails: /bin/install -c -m 644 units/x86_64-linux/alllclunits.ppu units/x86_64-linux/actnlist.ppu units/x86_64-linux/arrow.ppu units/x86_64-linux/avglvltree.ppu units/x86_64-linux/buttons.ppu units/x86_64-linux/calendar.ppu units/x86_64-linux/chart.ppu units/x86_64-linux/checklst.ppu units/x86_64-linux/clipbrd.ppu units/x86_64-linux/clistbox.ppu units/x86_64-linux/comctrls.ppu units/x86_64-linux/controls.ppu units/x86_64-linux/dbactns.ppu units/x86_64-linux/dbctrls.ppu units/x86_64-linux/dbgrids.ppu units/x86_64-linux/dialogs.ppu units/x86_64-linux/dynamicarray.ppu units/x86_64-linux/dynhasharray.ppu units/x86_64-linux/editbtn.ppu units/x86_64-linux/extctrls.ppu units/x86_64-linux/extdlgs.ppu units/x86_64-linux/extendedstrings.ppu units/x86_64-linux/extgraphics.ppu units/x86_64-linux/filectrl.ppu units/x86_64-linux/forms.ppu units/x86_64-linux/fpcadds.ppu units/x86_64-linux/graphics.ppu units/x86_64-linux/graphtype.ppu units/x86_64-linux/grids.ppu units/x86_64-linux/imglist.ppu units/x86_64- linux/inipropstorage.ppu units/x86_64-linux/interfacebase.ppu units/x86_64-linux/lazlinkedlist.ppu units/x86_64-linux/lclintf.ppu units/x86_64-linux/lclmemmanager.ppu units/x86_64-linux/lclproc.ppu units/x86_64-linux/lclrescache.ppu units/x86_64-linux/lclstrconsts.ppu units/x86_64-linux/lcltype.ppu units/x86_64-linux/lclunicodedata.ppu units/x86_64-linux/lconvencoding.ppu units/x86_64-linux/lmessages.ppu units/x86_64-linux/lresources.ppu units/x86_64-linux/maskedit.ppu units/x86_64-linux/menus.ppu units/x86_64-linux/pairsplitter.ppu units/x86_64-linux/popupnotifier.ppu units/x86_64-linux/postscriptprinter.ppu units/x86_64-linux/printers.ppu units/x86_64-linux/propertystorage.ppu units/x86_64-linux/spin.ppu units/x86_64-linux/stdactns.ppu units/x86_64-linux/stdctrls.ppu units/x86_64-linux/stringhashlist.ppu units/x86_64-linux/textstrings.ppu units/x86_64-linux/toolwin.ppu units/x86_64-linux/utrace.ppu units/x86_64-linux/xmlpropstorage.ppu /tmp/me/lib/lcl/units/x86_64-linux /bin/install: cannot stat 'units/x86_64-linux/avglvltree.ppu': No such file or directory /bin/install: cannot stat 'units/x86_64-linux/chart.ppu': No such file or directory /bin/install: cannot stat 'units/x86_64-linux/clistbox.ppu': No such file or directory /bin/install: cannot stat 'units/x86_64-linux/dynamicarray.ppu': No such file or directory /bin/install: cannot stat 'units/x86_64-linux/dynhasharray.ppu': No such file or directory /bin/install: cannot stat 'units/x86_64-linux/extendedstrings.ppu': No such file or directory /bin/install: cannot stat 'units/x86_64-linux/fpcadds.ppu': No such file or directory /bin/install: cannot stat 'units/x86_64-linux/graphtype.ppu': No such file or directory /bin/install: cannot stat 'units/x86_64-linux/lazlinkedlist.ppu': No such file or directory /bin/install: cannot stat 'units/x86_64-linux/lconvencoding.ppu': No such file or directory /bin/install: cannot stat 'units/x86_64-linux/stringhashlist.ppu': No such file or directory /bin/install: cannot stat 'units/x86_64-linux/textstrings.ppu': No such file or directory No wonder, these units are not in the lcl, but have been moved to components. I removed them from the implicit units listed in Makefile.fpc in the LCL dir and regenerated the makefile. Running make install then proceeds further: make -C interfaces install make[1]: Entering directory '/home/michael/projects/lazarus-tst/lcl/interfaces' make -C gtk2 all make[2]: Entering directory '/home/michael/projects/lazarus-tst/lcl/interfaces/gtk2' /bin/rm -f ../../units/x86_64-linux/gtk2/lcl.ppu \ ../../units/x86_64-linux/gtk2/lcl.o /usr/local/bin/ppcx64 -gl -dgtk2 -Sci -Fu../../units/x86_64-linux -Fu../../../packager/units/x86_64-linux -Fu../../../components/lazutils/lib/x86_64-linux -Fu.. -Fu. -Fu/usr/local/lib/fpc/3.3.1/units/x86_64
[Lazarus] Makefile issues
Hello, The lazarus makefile has some dependency issues. make ide: make ide make -C ide ide make[1]: Entering directory '/home/michael/projects/lazarus-tst/ide' /bin/mkdir -p ../units/x86_64-linux/gtk2 make -C ../tools svn2revisioninc OS_TARGET=linux CPU_TARGET=x86_64 OPT='' make[2]: Entering directory '/home/michael/projects/lazarus-tst/tools' Makefile:2956: warning: overriding recipe for target '.' Makefile:2954: warning: ignoring old recipe for target '.' /usr/local/bin/ppcx64 -gl -Fu. -Fu../components/lazutils/lib/x86_64-linux -Fu../lcl/units/x86_64-linux -Fu../lcl/units/x86_64-linux/nogui -Fu/usr/local/lib/fpc/3.3.1/units/x86_64-linux/rtl -FE. -FU. -Cg -Fl/usr/lib/gcc/x86_64-linux-gnu/9 -Flinclude -Fl/etc/ld.so.conf.d/*.conf -dx86_64 svn2revisioninc.pas svn2revisioninc.pas(64,3) Fatal: Can't find unit FileUtil used by Svn2RevisionInc Fatal: Compilation aborted make[2]: *** [Makefile:2967: svn2revisioninc] Error 1 make[2]: Leaving directory '/home/michael/projects/lazarus-tst/tools' make[1]: *** [Makefile:5387: revisioninc] Error 2 make[1]: Leaving directory '/home/michael/projects/lazarus-tst/ide' make: *** [Makefile:3788: ide] Error 2 Based on the output of "make help", in an attempt to create svn2revisioninc I did: make tools make -C tools make[1]: Entering directory '/home/michael/projects/lazarus-tst/tools' Makefile:2956: warning: overriding recipe for target '.' Makefile:2954: warning: ignoring old recipe for target '.' make --assume-new=lazres.pp lazres make[2]: Entering directory '/home/michael/projects/lazarus-tst/tools' Makefile:2956: warning: overriding recipe for target '.' Makefile:2954: warning: ignoring old recipe for target '.' /usr/local/bin/ppcx64 -gl -Fu. -Fu../components/lazutils/lib/x86_64-linux -Fu../lcl/units/x86_64-linux -Fu../lcl/units/x86_64-linux/nogui -Fu/usr/local/lib/fpc/3.3.1/units/x86_64-linux/rtl -FE. -FU. -Cg -Fl/usr/lib/gcc/x86_64-linux-gnu/9 -Flinclude -Fl/etc/ld.so.conf.d/*.conf -dx86_64 lazres.pp lazres.pp(43,22) Fatal: Can't find unit LazLogger used by LazRes Fatal: Compilation aborted make[2]: *** [Makefile:2964: lazres] Error 1 make[2]: Leaving directory '/home/michael/projects/lazarus-tst/tools' make[1]: *** [Makefile:3394: all] Error 2 make[1]: Leaving directory '/home/michael/projects/lazarus-tst/tools' make: *** [Makefile:3784: tools] Error 2 Similar, make basecomponents make -C components/buildintf make[1]: Entering directory '/home/michael/projects/lazarus-tst/components/buildintf' /bin/rm -f units/x86_64-linux/buildintf.ppu /bin/mkdir -p units/x86_64-linux /usr/local/bin/ppcx64 -MObjFPC -Scghi -O1 -g -gl -l -vewnhibq -Fu../../packager/units/x86_64-linux -Fu../lazutils/lib/x86_64-linux -Fu. -Fu/usr/local/lib/fpc/3.3.1/units/x86_64-linux/rtl -FE. -FUunits/x86_64-linux -Cg -Fl/usr/lib/gcc/x86_64-linux-gnu/9 -dx86_64 buildintf.pas Hint: (11030) Start of reading config file /home/michael/.fpc.cfg Hint: (11031) End of reading config file /home/michael/.fpc.cfg Free Pascal Compiler version 3.3.1 [2022/11/05] for x86_64 Copyright (c) 1993-2022 by Florian Klaempfl and others (1002) Target OS: Linux for x86-64 (3104) Compiling buildintf.pas (3104) Compiling baseideintf.pas /home/michael/projects/lazarus-tst/components/buildintf/baseideintf.pas(21,3) Fatal: (10022) Can't find unit LazUTF8 used by BaseIDEIntf fatal: (1018) Compilation aborted After some more failed attempts trying to compile "sub-targets", I gave up. Am I correct in my understanding that in fact only the "main" targets all, bigide, useride are supposed to work out of the box when you start from a fresh checkout ? Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TListView: Column Header Captions and Column Sorting
On Thu, 17 Nov 2022, Aruna Hewapathirane wrote: Hello again, I have column headers and sorting works on a button click . Thank you once again Michael. I am trying to figure out how to sort when a user clicks a column header? Screenshot: https://pasteboard.co/QSf8hNafG0x5.png And I notice the column headers are sort of greyed out. Is it possible to make them bold if we want? And the column width am guessing we can set through code? In the IDE, set a OnColumnClick event handler. Define FLastColumnIndex and FLastSort as form fields, so your form will look like this: TForm1 = Class(TForm) ListView1 : TListView; procedure ListView1ColumnClick(Sender: TObject; Column: TListColumn); private FLastColumnIndex : Integer; FLastSort : TSortDirection; end; You can also set the event handler in code: ListView1.OnColumnClick:=@ListView1ColumnClick; In the OnColumnClick handler, do the following: procedure TForm1.ListView1ColumnClick(Sender: TObject; Column: TListColumn); var SD : TSortDirection; begin SD:=sdAscending; if Column.Index=FLastColumnIndex then if FLastSort=sdAscending then SD:=sdDescending; ListView1.SortColumn:=Column.Index; ListView1.SortDirection:=SD; ListView1.Sort; end; That should sort ascending if the user clicks on the column for the first time, and will toggle between ascending/descending if the user clicks on the same column. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
