• ChooseColor, CC_ENABLEHOOK - moving controls around doesn't give th

    From R.Wieser@21:1/5 to All on Mon Apr 12 19:14:40 2021
    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)
  • From JJ@21:1/5 to R.Wieser on Mon Apr 12 23:51:45 2021
    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)
  • From JJ@21:1/5 to R.Wieser on Tue Apr 13 16:13:03 2021
    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)
  • From R.Wieser@21:1/5 to All on Tue Apr 13 13:32:48 2021
    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)
  • From JJ@21:1/5 to R.Wieser on Wed Apr 14 18:27:15 2021
    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)
  • From R.Wieser@21:1/5 to All on Wed Apr 14 13:55:49 2021
    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)
  • From R.Wieser@21:1/5 to All on Wed Apr 14 18:39:06 2021
    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)
  • From JJ@21:1/5 to R.Wieser on Thu Apr 15 12:34:36 2021
    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)
  • From R.Wieser@21:1/5 to All on Thu Apr 15 09:23:12 2021
    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)