Forum > Lazarus

We are planning the release of Lazarus 2.2

<< < (5/10) > >>

dbannon:
So, I need to point out that fixes_2_2 (downloaded this morning) has this bug, https://bugs.freepascal.org/view.php?id=38922

It affects windows developers who are using HiPDI screens and making binaries that will be used on normal screens OR developers using normal DPI and the binaries may possibly be used on a HiDPI system.  Important to note that the developer testing the code on his/her working system will not pickup this problem !

What happens is that forms that are not shown at startup, are having their FormShow event called during startup. The form is not actually shown, I guess its not ready at that stage. So, in some cases that does not matter but in other cases, code in the FormShow method depends other things having happened and a crash results. Personally, I would greatly prefer to have FormShow called when the form is being shown !

As many median priced laptops these days have hiDPI screens, we should see quite a lot systems being affected. 

Very easy to demonstrate, on (eg) a normal DPI screen system, make the usual default main form, add a second form, Unit2 and in its OnShow event, put "showmessage('Unit 2 FormShow'); "

Take the binary to a HiDPI system and run it.  Or take the project there and compile and run it (being careful not to make unit2.lfm rewrite).

The difference in DPI relates to a line in the lfm file, DesignTimePPI = 144

The bug report identifies the revision that the problem first appeared in trunk and also mentions a later fix that has subsequently been reversed .......

Davo
 

wp:

--- Quote from: ssawgift on June 22, 2021, 06:08:57 am ---Is Windows 2000 still supported?

--- End quote ---
I still have a VM with Win2000, pulled myself a Laz-trunk and built it on the basis of FPC3.2.2. "make bigide" resulted in an IDE which did not start. But "make all" made it work. I removed all the packages that I do not need, and then added TAChart, TurboPower, DateTimeCtrls, and DbfLaz - still working. Compiled and ran some of my applications, they all work.

So the message is: there is a good chance that you may be able to build your application with Laz 2.2/FPC3.2.2 on Win 2000. Of course - no guarantee...

Martin_fr:

--- Quote from: ssawgift on June 22, 2021, 06:08:57 am ---Is Windows 2000 still supported? The reason I ask this is that I see that the latest svn trunk build has a dependency on DebugBreakProcess which is not available on Windows 2000.

--- End quote ---

I don't have W2000 for testing. But if that is the reference in fpdebug, I think that can be dynamically loaded. I have to look into this.

Strange though. I thought 2.0.x had fpdebug included too. So that should have had the same issue?

trev:

--- Quote from: PascalDragon on June 22, 2021, 08:51:36 am ---
--- Quote from: mattias on June 21, 2021, 03:02:28 pm ---
--- Quote from: mrmaxmusterman on June 21, 2021, 01:50:03 pm ---Will there be a native apple silicon (M1) version available for download with the release of Lazarus 2.2?

--- End quote ---

I don't have a M1, so I can't test and build there. Maybe there is a volunteer?

--- End quote ---

Maybe trev can help since he's doing nightly builds for that platform anyway?

--- End quote ---

There's a small complication: the M1 operating system (Big Sur) will not execute unsigned code. The code can be signed with an ad hoc signature (ie without an Apple developer Certificate) but it is only valid for the machine on which it was signed. For those who want it to be "out of the box", every executable in the Lazarus distribution would need to be signed with an Apple Developer Certificate. Whether Lazarus recompilations would be ok, is unknown. The Apple linker will sign anything linked on an M1 with an ad hoc signature by default which may be ok.

The executables in the daily snapshots I do, need to be ad hoc signed by the enduser which I don't see as a big issue because anyone installing daily development (trunk) snapshot versions should possess the knowledge to do so (or at least be able to follow the explanation to do so which I added to the Wiki and link to).

I've been meaning to add signing and possibly notarizing of the executables with my (personal) Apple Developer Certificate, but as I haven't had any feedback since automating the daily build processes as launchctl daemons, I didn't pursue it.

Really, I think the easiest thing to do may be to simply provide a script to build Lazarus from the release source on M1 machines. It takes about 9 minutes on my base model M1 Mac mini including syncing the source repository.

Wallaby:

--- Quote from: trev on June 22, 2021, 12:17:16 pm ---Really, I think the easiest thing to do may be to simply provide a script to build Lazarus from the release source on M1 machines. It takes about 9 minutes on my base model M1 Mac mini including syncing the source repository.

--- End quote ---

Another way might be creating a simple shell script that checks if there is a signature on the Lazarus bundle and ad-hoc code-signs it if not. Then launches the Lazarus executable.

This script would be used to start Lazarus by user.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version