Menu captions with images are hard to read under Windows 11

[Tom Mueller 5]

Hello

 

I found that the Captions of Delphi's TMainMenu and TPopupMenu are hard to read under Windows 11, if an ImageList is connected to the menu.

Tested with Delphi 10.4 and 11.0.

 

Windows 10 menu without and with images (ok)

 

Windows 11 menu without and with image (hard to read black text on dark-blue background)

 

Can anyone reproduce this behavior?

 

Best regards

Tom

 

[Der schöne Günther 316]

All Windows 11 menus look like this. I have no idea what they were thinking.

[Anders Melander 1782]

18 minutes ago, Der schöne Günther said:

I have no idea what they were thinking.

16 colors ought to be enough for anybody? 🙂

[Tom Mueller 5]

15 hours ago, Der schöne Günther said:

All Windows 11 menus look like this.

Yes, that's something Embarcadero can't change.

 

But it seems that if the menu is connected to an ImageList Embarcadero uses its own draw method. There are no round corners anymore and the text color does not change to white.

 

I found a QP issue for the rounded corner as well and I created one for the text color problem:

• https://quality.embarcadero.com/browse/RSP-34597
• https://quality.embarcadero.com/browse/RSP-35800

Edited October 8, 2021 by Tom Mueller

[David Heffernan 2345]

It has always been a mistake for Embarcadero to owner draw menus when they have images. I modify the rtl to avoid this and let the system drawn the menus, using PARGB32 images. 

 

After about 4 or 5 delphi releases they got their owner draw code to mostly work as well as letting the system draw it, although I think there were still DPI scaling issues. 

 

But it was inevitable that a new version of Windows would mean that owner draw code needed updating. And any applications out in the field would be stuck with this owner draw code that hasn't been tweaked for the new Windows version. 

 

It makes no sense to me that they did this. Surely the entire point of the system theme is that the system draws it. 

[Anders Melander 1782]

3 hours ago, David Heffernan said:

It has always been a mistake for Embarcadero to owner draw menus when they have images.

No, not always. There was a time when Windows didn't handle it properly or at all. The details eludes me though so it was probably pre-Vista.

 

You can't lay all the fault on Delphi. There have been many versions of Windows that didn't handle images in menus properly. For example I know I've had to resort to ownerdrawing menu items in Explorer context menu extensions because some combinations of menu item attributes caused the images not to be drawn or drawn incorrectly.

[Anders Melander 1782]

Just now, Anders Melander said:

I know I've had to resort to ownerdrawing menu items in Explorer context menu extensions

Yup. Found the following comment in the Drag and Drop Component Suite source code:

Quote

Special handling of menu bitmap for top level menu item.
Note: In older versions of the shell, top level popup items didn't support owner draw; If MFT_OWNERDRAW were specified together with MIIM_SUBMENU then the menu item would not be drawn.

Presently there are three methods of getting a top level menu item with a bitmap:

1. Using the MIIM_BITMAP item flag.
   This method has the disadvantage that it changes the apperance of *all* menu items in the menu in order to make room for the menu item bitmap.
   One possible work around of this would be to use SetMenuInfo() API with the MNS_CHECKORBMP flag to alter the whole menu, but I don't think it's wise to alter a system menu in this way.
2. Using the MFT_RADIOCHECK item type.
   This method has the advantage that it it doesn't alter the layout of either the menu or the item. It does however have the disadvantages that the bitmap will be drawn with the dimensions of of a menu checkmark (SM_CXMENUCHECK x SM_CYMENUCHECK) and that selected item is drawn in XOR mode instead of just transparently as would normally be the case. Method #1 also has the latter characteristic.
   At the time of writing, the WinRar and WinZip shell extensions uses this method.
3. Using the MFT_OWNERDRAW item type.
   This method has the disadvantage that we (or rather "I") have to perform all the work ourselves, and that we (or rather "you") risk drawing the item in a way that is inconsistent with what ever style Microsoft may come up with in the future.
   The advantage is that we can position the bitmap and text where ever we please.
   At the time of writing, the TortoiseSVN shell extension use this method.

Drag-drop handler shell extensions (e.g. the TDragDropHandler component) doesn't support method #3.

As of Vista method #1 with a 32 bit premultipled ARGB bitmap appears to be the preferred method.

 

[David Heffernan 2345]

2 hours ago, Anders Melander said:

No, not always

I should have been clearer. I'm talking about the new code they added for themed apps. I agree it is necessary for old pre comctl32 v6 apps. I still do that. For comctl32 v6 I can't understand why they don't use PARGB32 images. 

[Guest]

11 hours ago, Tom Mueller said:

Embarcadero uses its own draw method

The old "OwnerDraw" [not exactly the same as own draw, i know] concept and High DPI is a match made in hell. For High DPI any owner drawing should be avoided because there's always an old pixel calculation hiding somewhere in some of the ancestors. Control and responsibilities are broken. It was cool back in 3.1 but started to give some head aces as long back as W95.

 

HighDPI nudged forward a complete rewrite for me (those should happen anyway and i was like 3 years behind anyway). I have not tried to update the app created using D2007, updated up to XE. It would suck. IAll the OwnerDraw routines and old tweaks to update...

 

But i must say, with or without imagelist the readability decreased, IMHO. And aesthetically i do not like "shrunken" background markings. Looks "toy"-like.

[Achim Kalwa 61]

On 10/7/2021 at 3:14 PM, Tom Mueller said:

Windows 11 menu without and with image (hard to read black text on dark-blue background)

Can anyone reproduce this behavior?

Yes. And I've reported this issue some weeks ago as RSP-35049. The black text is caused by a bug in Vcl.Menus.pas; procedure DoThemedDrawText(): The parameter "Selected" is completely ignored in that code, but should be used to select to correct theme element details. Feel free to vote for it 😉.

 

But even if this will be (hopefully) fixed in some Delphi 11.1 update I'm still looking for a workaround without using a full copy of Vcl.Menus.pas. Something like patching Vcl.Menus at runtime (using Delphi Detours? Or code from Andreas Hausladen's VCLFixPack?) to replace DoThemedDrawText() with a fixed version (see RSP-35049 for the required changes). Any help appreciated.

 

[Attila Kovacs 629]

2 hours ago, Achim Kalwa said:

without using a full copy of Vcl.Menus.pas

It's not that bad if you can throw it away on the next update which is very likely in this case.

[Uwe Raabe 2057]

40 minutes ago, Attila Kovacs said:

It's not that bad if you can throw it away on the next update which is very likely in this case.

Indeed. I also add am IFDEF to error out when compiled with a newer Delphi version. Even if the problem is not fixed yet, the tweaked source is most likely no longer up to date anymore.

[Guest]

3 hours ago, Attila Kovacs said:

It's not that bad if you can throw it away on the next update which is very likely in this case.

On more thing (out of already 1000) to keep track of that can bite. Sucks.

I had an issue with /n software, they fixed it but "it did not make it to the next update".

I did not know that (i was not informed) and it was an edge case thing, so i updated, deployed. Ouch! That bitted*!

 

* "To bite" in past tense? Bote? Bitted! Erh... Butt? Butted?

[David Heffernan 2345]

I just keep a document with every change I make, and then on a new release go and reply them one by one if they are still needed. A few hours work. 

[Vincent Parrett 750]

I use runtime packages (the application is mostly plugins) so just taking a copy of the unit doesn't work. I use delphi detours where I can (it's not always doable) and like Uwe I have it error out if the compiler version changes so I know I need to look at it again. 

[Nigel Thomas 35]

5 hours ago, Dany Marmur said:

* "To bite" in past tense? Bote? Bitted! Erh... Butt? Butted?

"Ouch! - that bit!"

[Lars Fosdal 1792]

 

On 10/10/2021 at 2:49 AM, Nigel Thomas said:

On 10/9/2021 at 9:35 PM, Dany Marmur said:

* "To bite" in past tense? Bote? Bitted! Erh... Butt? Butted?

"Ouch! - that bit!"

Eight bits = 1 byte here as well?
/disappearing backwards into the hedge

[Guest]

The bits byte!

[ventiseis 2]

Just noticed that TPopupActionBar (using Delphi 10.2) does seem to use the correct font color.

Anyways, I find the look of the classic menus not very readable.

Edited December 2, 2021 by ventiseis
added delphi version

[Achim Kalwa 61]

Embarcadero has fixed the menu font color problem in V11 update 2.

I really would like to know why Microsoft discarded the well-looking menu colors from Windows 10 and now uses the Windows-2000-colors for menus. And the selection bar height is 2 pixel too small on Windows 11, which makes font decenders difficult to see.

At least Microsoft has "fixed" the bar height on recent Windows 11 builds.