Is there a repository somewhere that documents these nuanced interactions? What annoys me when I'm developing native UI is I'm never sure my custom controls are capturing these nuanced behaviors. I shouldn't have to reverse engineer them through trial and error. There are Human Interface Guidelines provided by Microsoft, Apple, GNOME, etc. but they do not document these little behaviors.
Not that I'm aware of, but the underlying point here is you shouldn't be creating custom controls to begin with, if you can at all help it. Not only do you miss our on stuff like this that's currently handled, but you miss out on future improvements you couldn't possibly know about beforehand.
Ideally yes, but sometimes you need custom controls that are similar to existing ones. Example: Notepad++ is famously a vanilla win32 app, but uses the Scintilla code edit control rather than subclassing the native win32 edit control. Code edit controls might implement features, like multi-cursor editing, which are foundationally incompatible with the assumptions the native control made. These subtle design differences can impact core assumptions, like the implementation of undo/redo, so subclassing isn't always an option.
I'm well aware of that, but what I think you're missing is that if you need a large text editor, you'd just... use Scintilla, or one of the handful of alternatives. You wouldn't reinvent the wheel from scratch. The number of people who develop new controls from scratch exceeds the number who actually need to do so by orders of magnitude, in my anecdotal experience.
Sure, but someone wrote Scintilla and the alternatives, including the native control. Would be nice if they had some clear documentation on what they're supposed to do.
I'm well aware of that, but what I think you're missing is that if you need a large text editor, you'd just... use Emacs, or one of the handful of alternatives.
(this is not Emacs boosterism. I could have used any other text editor there)
It was much easier to subclass a control and modify its behaviour by altering the handling of certain messages for that control than creating a brand new control and trying to mimic every behaviour to every Windows message sent.
The Spy (or was it Spy++) app from the Windows SDK was very useful to figure out the best place to subclass the control, along with logging Windows messages and params sent to your subclassed control's WndProc.
That was more viable back when the Win32 common controls were being maintained, but they have basically been out of support and on bare maintenance mode for several years. There are no future improvements and they don't even support currently expected functionality like dark mode, much less basic flexible layout. All OS UI toolkit development moved over to UWP and is currently a mess with the WinUI 2 vs 3 split.
It's worse than bare maintenance, MS may have entered the stage of "clueless breaking" probably for the same reasons outlined above (newcomers don't understand what came before them).
The following is an account as an end-user. It is an old Win32 program from the 90s. Remember the theme styling controls from Desktop->Properties etc? For example you could change the white Control background to something else. Even if it never worked well enough everywhere, it was supported by native Controls. And in this application too. Recently the developer must have migrated the app to a new SDK (I guess). Not only did the clickable buttons lose all their borders, making them harder to eye-track, but all those native Controls? Lost their legacy theming support. Changing the background color no longer applies in the new version, it remains white.
And that's unlikely developer's own work. I assume the SDK adheres to newer guidelines itself.
I've seen projects trying to document a few of these UI patterns for the web, including how to build controls that are also accessible. I don't have any links on me at the moment though. It would be really nice if someone took all of these details and documented them carefully in a single Wiki-style site.
