4 ms·

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

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.

hgs3 3y ago
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.
- dataflow 3y ago
  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.
  - toast0 3y ago
    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.
    - toast0 3y ago
      Also, it's nice to have clear documentation when you want to evaluate one of these things to see if it does what it should.
  - PaulDavisThe1st 3y ago
    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)
ack_complete 3y ago
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.
- PinkSheep 3y ago
  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.
canucker2016 3y ago
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.

hgs3 3y ago

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.

dataflow 3y ago
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.
- toast0 3y ago
  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.
  - toast0 3y ago
    Also, it's nice to have clear documentation when you want to evaluate one of these things to see if it does what it should.
- PaulDavisThe1st 3y ago
  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)

ack_complete 3y ago

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.

PinkSheep 3y ago
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.

canucker2016 3y ago

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.