Jump to content
Tom Mueller

Menu captions with images are hard to read under Windows 11

Recommended Posts

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.

 

Menu_Win10.png.a3b50c4a66976ad56f25f0eac39dfac1.png

Windows 10 menu without and with images (ok)

 

Menu_Win11.png.50bc9eb13a100efca10244921932aaf8.png

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

 

Can anyone reproduce this behavior?

 

Best regards

Tom

 

Share this post


Link to post
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? 🙂

  • Haha 4

Share this post


Link to post
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.

Menu_Win11.png.39bded0c10c78335f0ef4298c7b2f84a.png

 

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

Edited by Tom Mueller

Share this post


Link to post

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. 

  • Like 1

Share this post


Link to post
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.

Share this post


Link to post
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.

 

Share this post


Link to post
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. 

  • Like 2

Share this post


Link to post
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.

Share this post


Link to post
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.

 

  • Like 4
  • Thanks 2

Share this post


Link to post
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.

Share this post


Link to post
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.

  • Like 1

Share this post


Link to post
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?

Share this post


Link to post

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. 

Share this post


Link to post

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. 

Share this post


Link to post
5 hours ago, Dany Marmur said:

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

"Ouch! - that bit!"

Share this post


Link to post

 

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

Share this post


Link to post

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.

Example.png

Edited by ventiseis
added delphi version

Share this post


Link to post

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.

  • Like 1

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×