Harry Bego

Just a hunch, following Remy's suggestion: is the form auto created? If auto, and if you also create a dynamic instance, you could be looking at another form than you think.

I’m finding that under Windows 11 unstyled checkboxes and radio buttons have a solid blue color when checked = true. Is there a way to prevent this and have them look the same as in Windows 10? Using C++Builder 10.4.2. Thanks for any hints!

Ok so in Windows 11 the only way to get rid of the solid blue and get decent looking checkboxes and radio buttons is to use styles. I have been using customized styles a lot but not for checkboxes and radio buttons since these didn’t look good at high dpi. But I now find that the new high DPI styles work great and the “Sky” style has nice checkboxes. Also, you can choose a style per control so I can use Sky just for the checkboxes and radio buttons. Problem solved. Thanks for all responses.

Here's a screenshot from the preferences dialog in Paint Shop Pro: C++Builder itself and MS Word have the same checkboxes as in Windows 10. So looks like these use styles/skins.

The issue is unrelated to themes. It’s the same in all themes. Looks like it is a similar thing to what we saw initially in listviews in Windows 10: selected items had a solid blue background.

I've attached two images so you can see the difference. The left one is from Windows 11, the right one from Windows 10:

I have a TListView, report style, with MultiSelect == true; after selecting multiple items, pressing VK_DOWN does not correctly clear the selection. It visually unselects the items, and unsets their Selected properties. However, pressing Shift + Click includes the 'old' items in the selection. Clicking an item does correctly clear the selection. The listview is subclassed, but the default procedure is called correctly (I think). I've tried various ways to clear the selection but somehow the listview remembers. The only way I can make it forget is to clear and reload it. Am I missing something? Thank you for any clues!

Solved! It turned out that one of the cases in a switch statement processing arrow keys did not call the default proc where it should, so the Selected property was not unset. Moral of story: if a subclassed window procedure shows incorrect default behavior, you're probably not calling the default procedure.

Thank you. I did test with a basic TListView and that works fine. There's a lot going on. It uses a home-brewn virtual list; I'm afraid it may be the subclassing. But I'm also using an TApplicationEventsShortCut to dispatch keyboard events. I still hope it is something simple. Rebuilding it from the ground up will take two months.