info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
ChooseColor, CC_ENABLEHOOK - moving controls around doesn't give the desired result.
5 views
Skip to first unread message
R.Wieser
Apr 12, 2021, 11:33:01 AM4/12/21
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
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
Apr 12, 2021, 12:52:14 PM4/12/21
to
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
Apr 12, 2021, 1:14:49 PM4/12/21
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
> Try specifying the CC_FULLOPEN flag.
> 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.
have to wait until the swapping works.
> If you create the dialog from scratch
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
Apr 13, 2021, 5:13:35 AM4/13/21
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.
>
> I've not even thought of that. Though testing it (what effect it has) will
> have to wait until the swapping works.
R.Wieser
Apr 13, 2021, 7:33:07 AM4/13/21
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
>> 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.
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.
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
Apr 14, 2021, 7:27:57 AM4/14/21
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
button? It should be hidden, IMO - as it's irrelevant.
>
> .... 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"
>
> 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. :-)
button? It should be hidden, IMO - as it's irrelevant.
R.Wieser
Apr 14, 2021, 7:56:00 AM4/14/21
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
> 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.
/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
Apr 14, 2021, 12:39:18 PM4/14/21
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. :-)
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
Apr 15, 2021, 1:35:23 AM4/15/21
to
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
Apr 15, 2021, 3:23:26 AM4/15/21
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
>> 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. :-|
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.
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.
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
0 new messages