3 ms·

And there is nothing more awkward than trying to manipulate file ACL's in those tiny dialogues that you can't resize. I would think that it would be easy to fix

And there is nothing more awkward than trying to manipulate file ACL's in those tiny dialogues that you can't resize. I would think that it would be easy to fix the resize problem, but its almost as if they had some compelling reason keep them at a fixed size.

douche 11y ago
I've never understood that either. Those are just Win32 windows, right? So you change a window-style flag, and it should become resizable, right? I'm tempted to go mess around and see if I can hook into those windows with COM somehow and twiddle some bits... Maybe the rest of the dialog controls are all fixed dimensions and non-autosizable. Still, that seems like the kind of thing you could unleash a platoon of interns on and modernize, though.
- ygra 11y ago
  > Maybe the rest of the dialog controls are all fixed dimensions and non-autosizable. That's exactly the problem. Raw Win32 doesn't really have provisions for layouting containers and auto-resize behaviour. So you'd essentially have to handle WM_SIZE and reposition/resize all controls in the dialog. Such code is cumbersome to write, awkward to change and annoying to debug/test (e.g. you still need to check that you don't change something to negative sizes and/or constrain the window dimensions appropriately). And in the end you have a few hundred lines of code that are intricately linked to the current dialog layout and, in part, even replicate the layout. So you cannot even easily change the layout anymore. This is quite a bit of a cost associated with that. Inventing layout containers on the Win32 side seems a pointless idea as well, considering that nearly no one except Microsoft actually uses the API at that level, so improvements here have little benefit for lots of work. Most people most likely use wrappers around it that offer such things (e.g. Windows Forms), or things that take care of their own rendering and offer layout containers (WPF, Swing, GTK, Qt, ...). So I guess if MS offered the usual layout mechanisms in Win32 people would just shrug and ask »Why? I already have those things in the toolkit I use. Can't they devote development resources to actually important things?«.

douche 11y ago

I've never understood that either. Those are just Win32 windows, right? So you change a window-style flag, and it should become resizable, right? I'm tempted to go mess around and see if I can hook into those windows with COM somehow and twiddle some bits... Maybe the rest of the dialog controls are all fixed dimensions and non-autosizable. Still, that seems like the kind of thing you could unleash a platoon of interns on and modernize, though.

ygra 11y ago
> Maybe the rest of the dialog controls are all fixed dimensions and non-autosizable. That's exactly the problem. Raw Win32 doesn't really have provisions for layouting containers and auto-resize behaviour. So you'd essentially have to handle WM_SIZE and reposition/resize all controls in the dialog. Such code is cumbersome to write, awkward to change and annoying to debug/test (e.g. you still need to check that you don't change something to negative sizes and/or constrain the window dimensions appropriately). And in the end you have a few hundred lines of code that are intricately linked to the current dialog layout and, in part, even replicate the layout. So you cannot even easily change the layout anymore. This is quite a bit of a cost associated with that. Inventing layout containers on the Win32 side seems a pointless idea as well, considering that nearly no one except Microsoft actually uses the API at that level, so improvements here have little benefit for lots of work. Most people most likely use wrappers around it that offer such things (e.g. Windows Forms), or things that take care of their own rendering and offer layout containers (WPF, Swing, GTK, Qt, ...). So I guess if MS offered the usual layout mechanisms in Win32 people would just shrug and ask »Why? I already have those things in the toolkit I use. Can't they devote development resources to actually important things?«.