Comment by trnglina

4 years ago

Built-in Windows controls, like buttons, scroll bars, etc. are updated with each system release. However, they are relatively inflexible, and no one uses WinApi anyway, so most frameworks and apps build their own components, with varying dedication to emulating the "native" style. Built-in controls also don't perform much in the way of layout (I believe the only way to position child HWNDs remains manual absolute positions?) so while your button might look native, your collection of two buttons won't.

My guess is MacOS's consistency comes from some combination of developer incentives, and UI toolkit design.

3 comments

trnglina

Reply
aasasd  4 years ago

> I believe the only way to position child HWNDs remains manual absolute positions? so while your button might look native, your collection of two buttons won't.

I thought the native APIs provided some kinds of constraints, like ‘these go into corners, and this is next to that’? Such approach is sorta necessary when windows can be resized. And I thought that UI builders like Visual Basic depended on these constraints. However I didn't do much manual UI, so perhaps the programmer indeed has to recalculate everything in pixels when something moves or is resized—like we did back in the day before we knew better.

  • freeone3000  4 years ago

    Which is the "native" API - win32, MFC/ATL, Form builder, WPF, or MAUI? If you're dealing with HWNDs directly, it's either win32 or MFC/ATL, but those haven't been touched in tens of years in favor of the current .NET APIs.