ChooseColor, CC_ENABLEHOOK - moving controls around doesn't give the desired result.

2 views
Skip to first unread message

R.Wieser

unread,
Apr 12, 2021, 11:33:01 AMApr 12
to
Hello all,

I've got a standard 'ChooseColor' running, but would like to have it act as
a /single/ color picker. So, I thought I would (on the fully opened
dialog) just swap pretty-much all of the left and right side controls and
just use the default opening, only showing the left half, now with that big
colorfull box on it.

Well, it ain't working. :-(

Although I can see that the /controls/ are swapped, those seem to be just
placeholders - with the actual stuff drawn smack on the dialog itself.

tl;dr:
Can I, on a 'ChooseColor' dialog change its appearance (move controls
around), and if so how ?

Regards,
Rudy Wieser


JJ

unread,
Apr 12, 2021, 12:52:14 PMApr 12
to
The controls of the custom color chooser (i.e. the right side RGB part) may
be ignored by the default handler if it's not shown. Try specifying the
CC_FULLOPEN flag. Otherwise, your code must manually click the "Define
custom color" button when the dialog is initialized.

If you create the dialog from scratch, make sure the control IDs are
correct. i.e. assigned to control IDs of Windows built in color chooser
dialog.

The left part of the color chooser may be ommitted, hidden, or be placed
outside of the dialog's client area - whichever is applicable.

R.Wieser

unread,
Apr 12, 2021, 1:14:49 PMApr 12
to
JJ,

> Try specifying the CC_FULLOPEN flag.

Thats, for testing purposes, what I currently have.

> The controls of the custom color chooser (i.e. the right side RGB
> part) may be ignored by the default handler if it's not shown.

I've not even thought of that. Though testing it (what effect it has) will
have to wait until the swapping works.

> If you create the dialog from scratch

Nope. I use the bog-standard 'ChooseColor' dialog and just iterate thru
and move the controls around in the WM_INITDIALOG event. Thats all.

... But if I cannot actually change the appearance of that dialog I might
just try an do that. :-)

Regards,
Rudy Wieser


JJ

unread,
Apr 13, 2021, 5:13:35 AMApr 13
to
On Mon, 12 Apr 2021 19:14:40 +0200, R.Wieser wrote:
>
> I've not even thought of that. Though testing it (what effect it has) will
> have to wait until the swapping works.

Then you may end up waiting for a deadlock.

R.Wieser

unread,
Apr 13, 2021, 7:33:07 AMApr 13
to
JJ,

>> I've not even thought of that. Though testing it (what effect it
>> has) will have to wait until the swapping works.
>
> Then you may end up waiting for a deadlock.

Luckily it has not come that far. :-)

This morning I found the CC_ENABLETEMPLATE flag, and after some more
"googeling" to find the actual dialogs template and (having to) extracting
the Dialog IDs of the controls using my earlier experiment I was able to
create a dialog-template with the left and right side swapped.

... but which, after removing the CC_FULLOPEN flag, gave me the problem you
already mentioned :

>>> The controls of the custom color chooser (i.e. the right side
>>> RGB part) may be ignored by the default handler if it's not
>>> shown.

*even though* the "right side RGB part" is now on the left side ... <huh?>

Luckily that was easy enough to fix by keeping the CC_FULLOPEN flag and, in
the WM_INITDIALOG, resizing the dialog to half its width. :-)

... but which (the CC_FULLOPEN flag) created a new problem, being that the
COLOR_MIX ("define custom colors") button is now disabled.

Re-enabeling that button gives an unexpected effect : clicking it makes the
dialog disappear. :-\ Oh well, I just have to do some more "fighting the
system" I suppose. :-)

Funny how this ChooseColor dialog is, at first glance, as flexible as you
can get them - to have to discover that it only is as long as you do not do
anything outof the ordinary with it .... :-D :-(

Regards,
Rudy Wieser


JJ

unread,
Apr 14, 2021, 7:27:57 AMApr 14
to
On Tue, 13 Apr 2021 13:32:48 +0200, R.Wieser wrote:
>
> .... but which (the CC_FULLOPEN flag) created a new problem, being that the
> COLOR_MIX ("define custom colors") button is now disabled.
>
> Re-enabeling that button gives an unexpected effect : clicking it makes the
> dialog disappear. :-\ Oh well, I just have to do some more "fighting the
> system" I suppose. :-)

If you only need the RGB part, why would you need the "Define custom color"
button? It should be hidden, IMO - as it's irrelevant.

R.Wieser

unread,
Apr 14, 2021, 7:56:00 AMApr 14
to
JJ,

> If you only need the RGB part, why would you need the "Define
> custom color" button? It should be hidden, IMO - as it's irrelevant.

True. But I was thinking of keeping it [1], as a small button, as a
/possibility/ to open up the custom color part. Who knows, somewhere in the
future I could be writing something that has use for it.

[1] possibly in a similar way the "help" button is currently hidden by
default.

And to be honest, I assumed the button would "open" as well as "close"
(toggle) the right-side pane - and it being grayed-out being a result of me
having used the CC_FULLOPEN flag. Only after I used it bog-standard I
noticed that I could open the right-side pane, but not close it again (as
the associated button gets disabled) ...

IOW, if I want to open and close the right side pane I have to create my own
solution for it regardless.

Regards,
Rudy Wieser


R.Wieser

unread,
Apr 14, 2021, 12:39:18 PMApr 14
to
JJ,

Some more stuff I bumped into:

The "Add to Custom Colors" button also advances the "Custom Colors" to the
next entry ) - in a zig-zag way - without giving any indication what the new
entry actually is (the focus rectangle doesn't move).

There is no way to select one of the 16 "Custom colors" as a /target/ (for
the above mentioned button) without the contained color overwriting the
"freeform color selector" stuff on the right. :-|

Well, thats easy enough to fix : we just grab the mouses right-click on any
of those 16 "Custom colors" and see if we can use it to select one of them
as a target, right ?

Wrong, as neither the "Custom colors" nor the "Basic colors" controls above
it generate any kind of WM_ messages (command or otherwise) - and thus there
is nothing to catch. :-(

As I said before, that 'ChooseColor' dialog *looks* to be way-over-flexible,
but in reality it absolutily isn't. :-((

Regards,
Rudy Wieser

P.s.
The open / close button (to "open" / "close" the right-side pane) was easily
added. Than again, that one I created and wrote code for myself. :-)


JJ

unread,
Apr 15, 2021, 1:35:23 AMApr 15
to
Yes, not every common dialog controls are fully customizable unfortunately.
Some of the controls are custom controls, such as the color dialog Custom
Colors entries, and the some of printing related dialog controls. They're
managed internally by their respective dialog handlers.

Though, common dialogs are just standard-issue dialogs which happens to be
(partially) customizable. They're not all purpose solutions. e.g. no alpha
channel support, no OTF font filtering, non customizable image of print
preview, etc.

Mind you, at least the color chooser, find text, replace text, and print
related dialogs are remnants of Windows v2.x, and there hasn't been any
significant changes. The reason why there's no alpha channel and OTF font
filtering support in the first place.

R.Wieser

unread,
Apr 15, 2021, 3:23:26 AMApr 15
to
JJ,

>> There is no way to select one of the 16 "Custom colors" as a /target/
>> (for the above mentioned button) without the contained color overwriting
>> the "freeform color selector" stuff on the right. :-|

First off, I was a bit quick on the draw :-\ There actually is a way to
select the target - as long as you have no problem dropping the mouse and
using the keyboard (alt-C, cursor keys). Also, I realized afterwards that I
could try to subclass that 'Custom color" control (though it would need a
lot of debugging to figure out whats going on inside them / how those 16
colors are addressed).

> Mind you, at least the color chooser, find text, replace text, and
> print related dialogs are remnants of Windows v2.x, and there
> hasn't been any significant changes.

In other words : way-back-when they didn't quite think of what they wrote
was /actually/ reusable (even though it seems they wanted it to be), and as
"it works" there is no reason to revisit it - even though they have changed
multiple aspects of the GUI, and that multiple times. :-)

> The reason why there's no alpha channel and OTF font filtering
> support in the first place.

I had to look "OTF fonts" up. First thought was "On The Fly fonts",
thoughI couldn't imagine anything to that ... :-) But a google later and
I think its about OpenType (auto-scaling) vector fonts. I assume it would
be handly to use only those when when you want to blow up prints.

As for the alpha channel ? Yes, I also noticed its absense. Possibly
related to the way-back-when you mentioned (when it effectivily didn't exist
on Windows yet ?). I stored a thought about adding after I got the rest
to work. Currently I'm not so sure if I should even try ...

Thanks for the feedback, appreciate it.

Regards,
Rudy Wieser



Reply all
Reply to author
Forward
0 new messages