View Issue Details

IDProjectCategoryView StatusLast Update
0038922LazarusLCLpublic2021-06-15 10:11
ReporterDavid Assigned ToJuha Manninen  
Status assignedResolutionopen 
Product Version2.1 (SVN) 
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
Attached Files


related to 0036127 resolvedJuha Manninen [Patch] TForm's bounds and restored bounds are inconsistent 



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.


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