View Issue Details

IDProjectCategoryView StatusLast Update
0038922LazarusLCLpublic2021-07-18 10:04
ReporterDavid Assigned ToMichl  
Status closedResolutionfixed 
Product Version2.1 (SVN) 
Target Version2.4Fixed in Version2.4 
Summary0038922: FormShow call at wrong time
Sorry, this is a poor bug report. I cannot determine whats happening but can say conclusively that it relates to r64986, if I roll back to before that revision, mid April, it goes away. That revision seems to have quite a history ....

Its a windows only problem and I cannot replicate it in a simple app.

My app has several forms, only mainform is shown at startup. Post Lazarus r64986, formshow is being called on one of the non-mainforms during startup. if I revert back one revision, it behaves normally. With r64986 and beyond, some time after, one of the other auto created but not shown forms will have its formshow called (for no apparent reason), when it tries to do things with its components, typically, ending with TCustomForm.setfocus (line 375), an exception (EInvalidOperation) is raised and the app crashes.

I am sorry I cannot be more specific than that, I know this is a very poor bug report !
Steps To ReproduceDownload my app (!!&!) from use Lazarus trunk on windows, add kcontrols via online package manager.

Build and run.

Roll back to before 13th May and the problem goes away. At startup, the only FormShow called is for mainform.
TagsNo tags attached.
Fixed in Revisionr65213, r65303
Attached Files


related to 0036127 resolvedJuha Manninen [Patch] TForm's bounds and restored bounds are inconsistent 
related to 0037647 closedJuha Manninen It does not raise an OnShow event if the form is maximized and ... - since rev 63577 (changed from 62892) 
related to 0039046 assignedMichl GTK3: FormShow event fired at FormCreate 



2021-05-22 11:44

reporter   ~0130999

Relates to issue 0036127

Juha Manninen

2021-05-22 11:57

developer   ~0131000

If you cannot replicate in a simple app, it means your tomboy app does something differently which triggers the event.
Please debug and study the backtrace.


2021-05-22 12:51

reporter   ~0131003

I have spent much of today doing just that.
Did you pick up what I said about rolling back to an earlier version of lazarus trunk fixing the problem ?

Juha Manninen

2021-05-22 15:42

developer   ~0131008

Yes sure. r64986 has only a small change for LCL-win32. More changes are in the common
I guess debugging is necessary for understanding the issue. I will not do it because I don't have a Windows machine around here now.

jamie philbrook

2021-05-22 16:07

reporter   ~0131009

Last edited: 2021-05-22 16:08

View 3 revisions


   I can only theorize of what you are doing that breaks your app but you need to actually create a demo not using KControls to show It..
   I am a long time Windows Vet on coding the lower bowls of windows and from Delphi's hacks that appeared over the years. There Is one item I can share with you and that is, you don't do any GUI/GDI modifications within the OnShow event that warrants a retrigger or a Repaint, Refresh of the GUI. And mostly, you don't use Application.ProcessMessages there..

  It's possible KControls is doing such hacks, if so then shame on the authors.
  The form has BeginUpdate and things like it to help stop that blatant activity..

  So Please provide a demo using LCL code without the need of installing Kcontrols to show the problem..

 If you can't provide that as you stated early then its obvious some hack you are doing that is time relevant to a schedule update of the form.


2021-05-23 02:50

reporter   ~0131015

Yeah, makes sense. I will try and 'prune down' the app and see if I can isolate the issue. KControls will be easy to eliminate, right now, the problem happens before any KControls forms are created (I create them dynamically). Trouble is I am not a windows users, and yesterday has reinforced that feeling ! So I am feeling my way. But I will start stripping stuff out and see at what point the problem stops.

First, I will roll back to a working version of Lazarus and get a release candidate out, so if you don't hear from me, don't think I have given up !



2021-05-24 12:06

reporter   ~0131026

OK, attached is a test app. It requires Trunk on Win64, It has three auto created forms, only one of which is shown. However, at startup, the other two form's FormShow() method is called.

As much of the actions have been removed from the second and third units, they don't cause a crash anymore but I do a ShowMessage() so you can see its happened.

To make this test app, I took my app, developed on Linux, and stripped out things until I got it down to a minimal start. During this process, occasionally Lazarus would decide to add a line to the current units lfm file -


and scale all position/sizes accordingly. When this happens, the problem with this unit (having its FormShow called incorrectly) goes away. I have not worked out just what triggers that rewrite of the lfm file.

The bad behaviour can be restored by removing that DesignTimePPI line from the lfm file for that unit. Likely to mess with scaling but we don't see it anyway ! (31,151 bytes)


2021-05-26 06:20

reporter   ~0131038

Here is an even simple demo of the problem. I have included a pre-prepared project and a ready to run binary, but here are the instructions in case you want to build from scratch.

On (eg) Linux, New Project, make three forms, put a label on the first one to make it distinctive. On the other two, in their FormShow methods, put a showmessage mentioning the form name.

Run it, on Linux it works as expected, it shows only the first form. Move the project to windows and recompile (or cross compile from Linux). In windows, drop a button or whatever on Form 3. Save and remove the button. That will trigger a rewrite of that units lfm file.

OK, build and run it. You may see one or the other ShowMessages, depending on your DPI. Obviously, you should see neither.

Again, the only difference between Form2 and Form3 is that one has the DesignTimePPI = 144 line (and changed position and size numbers). That extra line appears to fix the problem on a Hi DPI screen and introduce the problem on a low DPI. AT RUN TIME ???

Davo (109,049 bytes) (965,096 bytes)

Zeljan Rikalo

2021-05-27 12:33

developer   ~0131050

I can confirm such bug with Qt5 under linux 64bit, BUT ONLY when eg my laptop is connected to the HD TV with big resolution, usually on laptop or connected monitor it does not trigger.
Anyway, this was ok cca 2 months ago, so don't know what could cause such problem.

Joeny Ang

2021-05-28 03:06

reporter   ~0131059

Hi, see issue 0036127 for fix.


2021-05-28 06:53

reporter   ~0131063

(as noted in 0036127, I understand closed tickets dont get seen !)

OK, nice work Joeny !

I confirm it fixes this problem. I have further tested it it in Win10 Hi DPI, Windows 10 normal DPI, Windows Vista (yep, I still have a Vister box to test on).

I have also superficially tested on Linux, GTK2 and Qt5

Please consider !


2021-06-01 00:40

reporter   ~0131106

Is there something else I can do to help facilitate this ? Run some more specific tests or what ever ?

Joeny's patch does fix it, does not seem to do any harm and the problem is IMHO quite serious affecting a windows binary displayed on a hi DPI screen. Many laptops today do have these hi DPI screens ....

Juha Manninen

2021-06-01 05:17

developer   ~0131108

Zeljko, can you please test and apply the patch. I am stuck in a cottage for a while after my car broke. I only have a tablet computer here. No applying patches.

Juha Manninen

2021-06-11 06:18

developer   ~0131239

I am back and applied the patch. Thanks.

CudaText man

2021-06-11 06:30

reporter   ~0131241

@Joeny Ang,
can you look at the issue ?
It affects CudaText with a theme.


2021-06-13 12:17

reporter   ~0131285

yep Juha, that all seems to test OK.
(and thanks to Joeny for the patch !)
closing .....

Juha Manninen

2021-06-14 07:53

developer   ~0131300

I reverted r65213 in r65228 because of a regression and reopen this issue.


2021-06-15 10:11

reporter   ~0131315

OK, I can confirm that bad things happen with Windows again. Please try the very, very simple demonstration, the second example above.

Just to reiterate, it relates to the IDE deciding to stamp a "DesignTimePPI=144" into a .lfm file. I presume that only happens on a developer's system that is HiDPI. The problem does not show up in Linux but does on windows, it does not matter if the build machine is hi dpi or not. What matters is the machine the binary is run on.

So, a developer can compile, test, package and send out an application and it will crash on a percentage of the end user's machines.

I emphasis that the demo app has no fancy components, almost no (developer) code. Its just that you have, perhaps, resized a form on a hi dpi machine.


Vojtech Cihak

2021-06-17 02:21

reporter   ~0131349

I'm attaching simple demo that crashes with Lazarus 2.3.0 r65248M FPC 3.3.1 x86_64-linux-qt. I'm sure that code like this didn't crash in past (although I didn't test this demo with pre r64986).

Note that Form2 is autocreated in *.lpr and its property Visible=False. Setting Width of invisible form (Form2.Width:=640;) triggers DoShow. Demo doesn't crash when that line is commented.

#0 fpc_raiseexception at :0
0000001 RAISECANNOTFOCUS(0x7fffffffe220) at include/
0000002 SETFOCUS(0x7fffed5094b0) at include/
0000003 FOCUSCONTROL(0x7fffed5094b0, 0x7fffed509d50) at include/
0000004 SETFOCUS(0x7fffed509d50) at include/
0000005 FORMSHOW(0x7fffed5094b0, 0x7fffed5094b0) at unit2.pas:34
0000006 DOSHOW(0x7fffed5094b0) at include/
0000007 DELAYEDEVENT(0x7fffed5094b0, 0) at include/
0000008 PROCESSASYNCCALLQUEUE(0x7fffed4da250) at include/
0000009 IDLE(0x7fffed4da250, true) at include/
0000010 HANDLEMESSAGE(0x7fffed4da250) at include/
0000011 RUNLOOP(0x7fffed4da250) at include/
0000012 APPRUN(0x7fffed4da770, {Proc = {procedure (POINTER)} 0x7fffffffe580, Self = 0x7fffed4da250}) at qt/
0000013 RUN(0x7fffed4da250) at include/
0000014 main at project1.lpr:24 (109,835 bytes)

Zeljan Rikalo

2021-06-17 10:45

developer   ~0131352

@Vojtech , that's same bug as I've noted above. Non visible forms trigger DoShow() , and that's real problem.


2021-06-17 12:35

reporter   ~0131353

Last edited: 2021-06-17 13:00

View 2 revisions

> and thats a real problem.

Sure is, and it some how relates to hiDPI, I can turn it on and off reliably by removing or restoring the line -
DesignTimePPI = 144
in the lfm file in the simple demo project I uploaded.
And the scary thing is it also seems to depend on the DPI at run time, you can ship a binary that you have tested OK and it will crash an end user system.
EDIT: Vojtech's project uses Qt widgetset, won't build in Lazarus Trunk, I suggest my demo of a few days ago is a better one to work with. But its the same issue, 'something' is calling FormShow when it should not. The crash is about things being called from the OnShow event before its appropriate.

Zeljan Rikalo

2021-06-20 08:11

developer   ~0131404

I've fixed Qt in trunk.


2021-06-22 12:03

reporter   ~0131416

Zeljan, is that a QT specific fix ? This problem exists in the Fixes_2_2 that has just reached Release Candidate status, with this bug, its a not a great RC !


2021-06-25 09:03

developer   ~0131485

I've reverted revision 63847, see related issue

For me it fixed this problem and the related issue shouldn't be affected as the reason of the problem (r63577) already was reverted in r63882.

Please test and close if OK.

Chris Rorden

2021-06-26 10:44

reporter   ~0131497

While this patch fixes the premature FormShow call, it causes some GTK3 forms that to crash when they are shown (issue 37647). So this fix changes the behavior of GTK3 from eliciting premature FormShow to crashing.


2021-06-26 12:39

developer   ~0131500

Thank you for the hint, I'll look a this, if I can see what happens.


2021-06-27 06:29

reporter   ~0131514

Last edited: 2021-06-27 06:31

View 2 revisions

Yep, I can confirm that has fixed the ShowFom call issue on both Windows and GTK3. And I cannot replicate Chris's issue with a crash. As well as my test apps, I build my real app (~20K lines) on Windows, GTK2 and GTK3. No crashes. (I am impressed with the progress that been made recently in GTK3 by the way ! )

I did note that on Windows, I could not run my app or my little test apps in the IDE under the debugger, I expect thats a different issue however. It ran fine without the debugger.

Now, maybe this patch needs to find its way into the Release Candidate ?? I reported this bug there in the forum but it did not get a reply.

Thanks Michl, a really great step forward !

edit: Hmm, I think I should close this ? Its gt quite a long history. And maybe Chris needs to open a new one about the crash he sees in GTK3 ?



2021-06-27 10:54

developer   ~0131521

> Now, maybe this patch needs to find its way into the Release Candidate ??

It's already in there, see

> Hmm, I think I should close this ? Its gt quite a long history. And maybe Chris needs to open a new one about the crash he sees in GTK3 ?

Yes, this is the way to go. If this bug is fixed and tested, then this ticket can be closed. For GTK3, there are open questions, if they aren't answered, not much can be done there.


2021-06-27 11:52

reporter   ~0131524

Oh, great ! (sorry, I really struggle with SVN)

Closing this ticket !

Issue History

Date Modified Username Field Change
2021-05-22 11:42 David New Issue
2021-05-22 11:44 David Note Added: 0130999
2021-05-22 11:49 Juha Manninen Relationship added related to 0036127
2021-05-22 11:57 Juha Manninen Note Added: 0131000
2021-05-22 12:51 David Note Added: 0131003
2021-05-22 15:42 Juha Manninen Note Added: 0131008
2021-05-22 16:07 jamie philbrook Note Added: 0131009
2021-05-22 16:08 jamie philbrook Note Edited: 0131009 View Revisions
2021-05-22 16:08 jamie philbrook Note Edited: 0131009 View Revisions
2021-05-23 02:50 David Note Added: 0131015
2021-05-24 12:06 David Note Added: 0131026
2021-05-24 12:06 David File Added:
2021-05-26 06:20 David Note Added: 0131038
2021-05-26 06:20 David File Added:
2021-05-26 06:20 David File Added:
2021-05-27 12:33 Zeljan Rikalo Note Added: 0131050
2021-05-28 03:06 Joeny Ang Note Added: 0131059
2021-05-28 06:53 David Note Added: 0131063
2021-06-01 00:40 David Note Added: 0131106
2021-06-01 05:13 Juha Manninen Assigned To => Zeljan Rikalo
2021-06-01 05:13 Juha Manninen Status new => assigned
2021-06-01 05:17 Juha Manninen Note Added: 0131108
2021-06-11 04:27 Juha Manninen Assigned To Zeljan Rikalo => Juha Manninen
2021-06-11 06:18 Juha Manninen Status assigned => resolved
2021-06-11 06:18 Juha Manninen Resolution open => fixed
2021-06-11 06:18 Juha Manninen Fixed in Revision => r65213
2021-06-11 06:18 Juha Manninen LazTarget => -
2021-06-11 06:18 Juha Manninen Widgetset Win32/Win64 => Win32/Win64
2021-06-11 06:19 Juha Manninen Note Added: 0131239
2021-06-11 06:30 CudaText man Note Added: 0131241
2021-06-13 12:17 David Status resolved => closed
2021-06-13 12:17 David Note Added: 0131285
2021-06-14 07:53 Juha Manninen Status closed => assigned
2021-06-14 07:53 Juha Manninen Resolution fixed => open
2021-06-14 07:53 Juha Manninen Note Added: 0131300
2021-06-15 10:11 David Note Added: 0131315
2021-06-17 02:21 Vojtech Cihak Note Added: 0131349
2021-06-17 02:21 Vojtech Cihak File Added:
2021-06-17 10:45 Zeljan Rikalo Note Added: 0131352
2021-06-17 12:35 David Note Added: 0131353
2021-06-17 13:00 David Note Edited: 0131353 View Revisions
2021-06-20 08:11 Zeljan Rikalo Note Added: 0131404
2021-06-22 12:03 David Note Added: 0131416
2021-06-23 07:15 Juha Manninen Relationship added related to 0039046
2021-06-25 08:46 Michl Assigned To Juha Manninen => Michl
2021-06-25 08:46 Michl Relationship added related to 0037647
2021-06-25 09:03 Michl Status assigned => resolved
2021-06-25 09:03 Michl Resolution open => fixed
2021-06-25 09:03 Michl Fixed in Version => 2.3 (SVN)
2021-06-25 09:03 Michl Fixed in Revision r65213 => r65213, r65303
2021-06-25 09:03 Michl Widgetset Win32/Win64 => Win32/Win64
2021-06-25 09:03 Michl Note Added: 0131485
2021-06-26 10:44 Chris Rorden Note Added: 0131497
2021-06-26 12:39 Michl Note Added: 0131500
2021-06-27 06:29 David Note Added: 0131514
2021-06-27 06:31 David Note Edited: 0131514 View Revisions
2021-06-27 10:54 Michl Note Added: 0131521
2021-06-27 11:52 David Status resolved => closed
2021-06-27 11:52 David Note Added: 0131524
2021-07-18 10:03 Martin Friebe Target Version => 2.4
2021-07-18 10:03 Martin Friebe LazTarget - => 2.4
2021-07-18 10:04 Martin Friebe Fixed in Version 2.3 (SVN) => 2.4