4 ms·

Fun fact: the old colour picker is literally unchanged since Windows 95 (https://guidebookgallery.org/pics/gui/interface/dialogs/colourselector/win95.png https:

by einr 7y ago

Fun fact: the old colour picker is literally unchanged since Windows 95 (https://guidebookgallery.org/pics/gui/interface/dialogs/colourselector/win95.png https://guidebookgallery.org/pics/gui/interface/dialogs/colo...), complete with the really awkward use of a pipe character as separator between "color" and "solid" (which was used for the closest non-dithered colour match back when we had 4- and 8-bit displays) And to this day, 24 years later, adding custom colours is bugged. It does not "add" colours, it overwrites the first colour in the list. EDIT: to clarify, the above is only true if you exit the dialog and then return to it. It has no concept of previously defined custom colors, it just overwrites whatever you had before, instead of appending to the list. All that having been said, yes, it does appear to be better and more functional than the new proposal.

Jaruzel 7y ago
> It does not "add" colours, it overwrites the first colour in the list. It's not bugged. It's just non-obvious. Select the empty custom colour first, then select from the colour box the colour you want to add, then select 'add to custom colours'. Simple really. /s
- einr 7y ago
  It's actually somewhat more complicated than that even: clicking an "empty" custom colour (I put "empty" in quotes because it actually has no concept of empty, they're just white -- it keeps track of how many colours you've added since opening the dialog but it does not know if the colors you're overwriting are "empty" or not) selects the starting point where you want to start overwriting the list. So clicking multiple times will keep overwriting your colors, you just get to choose your starting point. So there is kind of a way to use it but it is non-intuitive and backwards as all heck. What the "add" button does, then: 1. overwrite colors step by step in the list (with no undo), 2. in order from top to bottom and then left to right, 3. starting at the most recently clicked custom color, 4. or at the first color in the list if no custom color has been clicked since opening the dialog Easy! :)
- machinecoffee 7y ago
  I cannot tell you how long I've spent frustratingly re-discovering this fact over the years and different Windows versions.
pedrow 7y ago
That wasn't a great leap from Windows 3.0, either (https://guidebookgallery.org/pics/gui/interface/dialogs/colourselector/win30.png https://guidebookgallery.org/pics/gui/interface/dialogs/colo...)
- dfox 7y ago
  This screenshot shows only the right part of the color selector dialog, which is otherwise exactly same as the W95+ version. CHOOSECOLOR.Flags has few bits that determine which variant is shown, and this particular variant is not documented in current winapi docs. I believe that this version is only used by Windows 3.x Color control panel applet. [Edit: and as this dialog is present in Windows 3.0 it almost certainly isn't implemented by same code as Color Dialog from Common Dialog library, because Common Dialogs were introduced in Windows 3.1] [Edit2: when I think about it probably the only common dialog that actually changed since W3.1 is Print Dialog. Other changes to the library were implemented as adding new dialog types. Notably the ComCtl/COM based W95 file/folder dialogs, which actually aren’t API compatible with previous versions, because they deal in shell objects (ie. ItemIDLists) and not in filenames. (This is also probably the reason why various parts of Windows Setup use really weird looking directory selection dialog)]

by einr 7y ago

Jaruzel 7y ago

> It does not "add" colours, it overwrites the first colour in the list. It's not bugged. It's just non-obvious. Select the empty custom colour first, then select from the colour box the colour you want to add, then select 'add to custom colours'. Simple really. /s

einr 7y ago
It's actually somewhat more complicated than that even: clicking an "empty" custom colour (I put "empty" in quotes because it actually has no concept of empty, they're just white -- it keeps track of how many colours you've added since opening the dialog but it does not know if the colors you're overwriting are "empty" or not) selects the starting point where you want to start overwriting the list. So clicking multiple times will keep overwriting your colors, you just get to choose your starting point. So there is kind of a way to use it but it is non-intuitive and backwards as all heck. What the "add" button does, then: 1. overwrite colors step by step in the list (with no undo), 2. in order from top to bottom and then left to right, 3. starting at the most recently clicked custom color, 4. or at the first color in the list if no custom color has been clicked since opening the dialog Easy! :)
machinecoffee 7y ago
I cannot tell you how long I've spent frustratingly re-discovering this fact over the years and different Windows versions.

pedrow 7y ago

That wasn't a great leap from Windows 3.0, either (https://guidebookgallery.org/pics/gui/interface/dialogs/colourselector/win30.png https://guidebookgallery.org/pics/gui/interface/dialogs/colo...)

dfox 7y ago
This screenshot shows only the right part of the color selector dialog, which is otherwise exactly same as the W95+ version. CHOOSECOLOR.Flags has few bits that determine which variant is shown, and this particular variant is not documented in current winapi docs. I believe that this version is only used by Windows 3.x Color control panel applet. [Edit: and as this dialog is present in Windows 3.0 it almost certainly isn't implemented by same code as Color Dialog from Common Dialog library, because Common Dialogs were introduced in Windows 3.1] [Edit2: when I think about it probably the only common dialog that actually changed since W3.1 is Print Dialog. Other changes to the library were implemented as adding new dialog types. Notably the ComCtl/COM based W95 file/folder dialogs, which actually aren’t API compatible with previous versions, because they deal in shell objects (ie. ItemIDLists) and not in filenames. (This is also probably the reason why various parts of Windows Setup use really weird looking directory selection dialog)]