RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v18]

[Alexey Ivanov]

On Fri, 14 Mar 2025 16:27:39 GMT, Phil Race <prr at openjdk.org> wrote:

>> @prrace I dont see checkmark/radio bullet with imageicon in WinGDI...
>> CheckMenuRadioItem is there in win32 API but is not called in our windows native. It does not have provision of having image icon passed to it.
>> In JDK, I can only see DrawFrameControl with DFCS_BUTTONCHECK/DFCS_BUTTONRADIO which is called from awt.
>> AWT spec has only CheckboxMenuItem and no RadioMenuItem and CheckboxMenuItem also does not have provision of drawing image icon, 
>> so it seems to be only Swing provision to have image icon alongside radio bullet/checkmark and getting Part.MP_POPUPCHECKBACKGROUND skin to show the background around icon/checkmark/bullet is not working in Windows11 as it was doing in WIndows10..
>> If we are not supposed to follow WIndows FileExplorer, not sure how to represent selection of the radiobutton/check menuitem
>
>>  CheckMenuRadioItem is there in win32 API
> 
> Ok.
>  > but is not called in our windows native.
>> It does not have provision of having image icon passed to it. 
> 
> I don't see how either of these matters.
> I'm sure there are lots of windows controls we don't use in AWT. Swing is much richer.
> For an extreme example, how would you compare the GDI table component to Swing's ?
> As I said off-line, you just need to write a small native program to verify how it should render.
> 
> And if there's no provision for an image icon, then the Swing Windows L&F doesn't need to support it either
> We don't (shouldn't) chase what Windows File Explorer does. That's not representative. It is a prominent
> app and likely heavily customised in its drawing.

> @prrace I dont see checkmark/radio bullet with imageicon in WinGDI...\
> CheckMenuRadioItem is there in win32 API but is not called in our windows native. It does not have provision of having image icon passed to it.

The check-mark displayed next to a menu item can be customised by using `hbmpChecked` and `hbmpUnchecked` of [`MENUITEMINFO`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-menuiteminfow) structure.

Yet there's no way in Win32 to display a check-mark (or radio-bullet) _and_ an icon, to the best of my knowledge.

AWT supports displaying a check-mark in a menu item but it does not support displaying a radio-bullet to indicate a set of mutually exclusive options which are usually represented with radio buttons in the interface.

> For an extreme example, how would you compare the GDI table component to Swing's ?\
> As I said off-line, you just need to write a small native program to verify how it should render.

I wanted to play around with native Win32 menus to explore the features it supports.

> And if there's no provision for an image icon

Win32 API allows adding an icon, or rather a bitmap in Win32 terms, to a menu item using `hbmpItem` member of `MENUITEMINFO` and setting `MIIM_BITMAP` flag in `fMask`.

The usage of this member can be seen in window menu, the one displayed by right-clicking a title bar of a window, for *Restore*, *Minimise*, *Maximise*, and *Close* commands.

> then the Swing Windows L&F doesn't need to support it either

Yet, as I said previously, I don't think it's possible to display both a custom icon _and_ a check-mark or radio-bullet mark at the same time.

> We don't (shouldn't) chase what Windows File Explorer does. That's not representative. It is a prominent
app and likely heavily customised in its drawing.

I agree that File Explorer in Windows 11 isn't representative. File Explorer uses many features provided by newer set of APIs. I also agree the *View* menu in File Explorer is likely custom-drawn even if Win32 menu API is used.

---

Windows 11 has changed the skin that corresponds to `Part.MP_POPUPCHECKBACKGROUND` so that it's no longer different for a selected check-mark. Other Win32 apps which use the same approach to display an icon for a menu item that can be selected should also be affected.

Shall we do nothing and just close the bug as *Not an Issue*?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2725574600