tElMainMenu scaling problems

Arthur Hoornweg

Hello LMD team,

I find that tElMainmenu does not scale its top-level items properly when the font size is changed in code (I'm trying to support DPI-awareness).  The problem is easy to reproduce: 

procedure TMyForm.FormCreate(Sender: TObject);

begin

  elmainmenu1.font.size:=16;

  elmainmenu1.selecteditemfont.size:=16;

end;

I would be grateful for a fix or workaround.

Kind regards,

Arthur Hoornweg

Eugene Balabuev (LMD)

Hi,

Did you set SystemFont property to False?

Arthur Hoornweg

Yes!  

The font size is changed but the top-level menu items are cut off, the space isn't calculated correctly. 

Eugene Balabuev (LMD)

After some research I found that the height of a menu bar cannot be changed at all. Microsoft suggests to use system menu font, and, actually, system font setting should be DPI aware.

Arthur Hoornweg

Hi Eugene,

the height is more or less OK, it is the *width* that is the problem. The text is much wider than the container.

I'm trying to attach an example (test case) here.

Eugene Balabuev (LMD)

Ok. I'll look. In my tests, the height was a problem.

Eugene Balabuev (LMD)

Items width measuring is fixed. Items height - impossible as already noted.

Arthur Hoornweg

Super!

Thanks for your efforts - I have renewed my suscription today. 

Kind regards,

Arthur

Arthur Hoornweg

The mainmenu item height scales perfectly fine for me (i use a trick for that).  See attached screenshots (one is at 96 dpi, the other at 175% under Windows 10).  

I develop under Delphi XE and I use a few tricks to make my applications per-monitor DPI-Aware since Delphi's own method is fundamentally broken. The trick is to disable Delphi's scaling by forcibly creating all forms at 96 dpi and then re-scale them manually before they become visible and also whenever Windows sends a WM_Dpichanged message.

- My applications have a per-monitor DPI-aware manifest.

- My forms respond to the WM_NCCREATE message and call EnableNonClientDPIScaling() in the message handler, this tells Windows 10 to scale the non-client area which also fixes the menu height problem ...

- My forms forcibly set screen.dpi to 96 in their overridden Constructor, then call the inherited Constructor, then restore screen.dpi to its original value.

- In an overridden AfterConstruction I find out what the real DPI number of the form's monitor is, and if it is unequal to 96, I calculate the optimal new size for the form and do a "Perform( WM_Dpichanged,...).

- The form needs a WM_Dpichanged message handler. In there, I temporarily set screen.dpi to 96, move and re-scale the form according to the parameters of the message, then I set form.PixelsPerinch to the new value and restore "screen.dpi" to its original value.   

This works brilliantly.  Some details need attention. It's optically pleasing to maintain resources in a higher resolution and to scale these down (Lanczos3) to the desired resolution on the fly.  The only items that don't scale at all are toolbuttons and speedbuttons, I'm still working on that. Maybe maintaining separate image lists for various resolutions is an idea.