#354 r4182 error message at IDE start

[Peter Panettone]

Downloaded r4182 today and built it in Delphi 12:
When starting the IDE, this error message popped up several times:

Is this a known bug?
Why is there no error information?

[Thomas Mueller]

Not a known bug, it doesn't happen here. Delphi 12 starts without any hitch.
Could you please try to run it in the debugger? Maybe that gives some insight.

[Otto]

I can reproduce this bug. FScaler is not assigned in TfmMacroLibrary.CheckLvMacrosHeight

[Karlheinz Jansen]

If I start RAD Studio 12 and the newest Gexpert compiled by source (build 4191) I receive
4 times an error messages during start. All the messages are
Access violation at address 577B507E read from 00000024

During the message MMX Code Explorer build 2580 ist already loaded.

[Karlheinz Jansen]

Also playing with the EXPERT Manager and stopping the other experts for the IDE start does not help, also moving Gexpert to the beginning or end of the list does not help.
If I remove GExpert everything is fine.

[Sergio Barbery]

I can confirm same here. Win 11, Delphi 12.
4 times an error messages during start. All the messages are
Access violation at address 577B507E read from 00000024

This worked some time ago but then it stopped.

Tried removing Registry settings as well. Didn't help.
Also tried to checkout older revisions down to Nov 2023, but the same error occurs.

Could it be related to some windows changes (may be recent updates)?
How can I debug this to see the place where it fails in source ?

[Sergio Barbery]

FScaler is not defined in GX_MacroLibrary.pas.

procedure TfmMacroLibrary.CheckLvMacrosHeight;
var
  LvMinHeight: Integer;
begin
  LvMinHeight := FScaler.Calc(5 * DEFAULT_GRID_ROWHEIGHT);
  if lvMacros.Height < LvMinHeight then begin
    pnlDescription.Height := ClientHeight - Toolbar.Height - LvMinHeight;
  end;
end;

Related to DpiScaling.
Also many forms now use too big font when 175% scaling is used in Windows.

Please see attached files.

[Achim Kalwa]

I'll look at this when I am back home.

[Achim Kalwa]

The access violation is thrown in procedure TfmMacroLibrary.CheckLvMacrosHeight(): FScaler is not yet initialized when this methode is called for the first time by FormResize(), caused by Form.BoundsRect := R in TGExpertsSettings.LoadForm().
Fixed in Rev. #4196

[Thomas Mueller]

Thanks Achim!

The question that remains is: Why did this not happen on my computer?
I'm running the current Windows 10 release with the latest updates.
Does this maybe only happen in Windows 11?
Or is this somehow related to the macro library form being docked vs. not docked? (Mine isn't docked.)
Fixing the problem for this one form might not prevent the problem from occurring in another form.

[Achim Kalwa]

This problem exists since Rev. 4147; where you modified u_dzDpiScaleUtils.pas to call ApplyDpi() at the end of TFormDpiScaler.Create(). I believe it only happens if Windows scaling is active.

[Thomas Mueller]

It's not that simple either. I just managed to reproduce it in a VM with the following conditions:

• Windows 11
• Scaling set to 125
• Macro Library fom docked and saved to the startup desktop

It didn't happen in my normal development environment which has the following conditions:

• Windows 10
• Scaling set to 125
• Macro Library form not docked

I'll look into it further this weekend. Work is calling.

[Thomas Mueller]

Now I also got it to happen in a VM under Windows 10. But still not on my development computer. The difference between the VMs and the dev computer is that the latter has got two monitors with different scaling (125 and 100) while the VMs have only one with scaling set to 125. But the IDE on the dev computer is set to open on the monitor with 125 scaling. Usually that results in all sorts of oddities happening rather than a bug not occurring. But I guess If I set scaling to 125 on both monitors that bug will occur.
Edit: Yes, now it does.

[Sergio Barbery]

@akalwahome Should I open a separate ticket for fixing big font size on scaled display as shown in my attached screenshots above? Thanks!

[Thomas Mueller]

Yes please. Keep bug reports as simple as possible. Mixing several issues in the same report makes it very difficult to keep track on what has been fixed and what still needs attention.

[Thomas Mueller]

Fixed in a different way in revision #4197 which should prevent similar errors to occur in other forms at a later time.