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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 12 Apr 2021 17:32:50 +0200, R.Wieser wrote:

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 ?

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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. :-)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 14 Apr 2021 18:39:06 +0200, R.Wieser wrote:

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. :-)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)