Glenn Linderman wrote:
> At this point the control
> has seen a "click" and sends a BTN_CLICK (IIRC) notification to it's
> parent - it's already done all the other processing. You could
> achieve what you are trying here by catching the _MouseDown event, and
> preventing that being delivered to the Button control.
So I changed -onClick to
-onMouseDown => sub { return 0; },
and it helps... but not quite enough... slow, individual clicks no
longer check the box... but a pair of rapid clicks will!
So I added
-onMouseUp => sub { return 0; },
You could instead catch and ignore the _MouseDblClick events. When
clicking on a window/control the event sequence is:
(1) MouseDown
(2) MouseUp
(3) MouseDblClick (if it happens soon enough after (1) and the
window/control's Windows Class has the CS_DBLCLCKS style)
(4) MouseUp
and it helps to the extent that the a pair of rapid clicks makes the
white part of the check box go grey when the mouse is over it... and
also has the extremely surprising side effect that the program no longer
terminates when clicking the close box... even though the handlers are
only on the Checkbox. I have to ^C from the console window to terminate
it! So this is extremely undesirable, and also not understood.
I can explain it now that I've seen it, but wouldn't have predicted it -
it shows the dangers of not passing things to their default handlers :-(
The effect you see is not only that the close button doesn't work, but
that you can't click anywhere in the window, including to move and
resize the window - you can fix this by clicking on another window or
the desktop.
This happens because on a double-click (and click) the buttom does a
SetCapture(), so that it can see the eventual mouse up message even if
you then drag the mouse off the button - so that it can redraw it in
it's un-pushed state (try with a real button rather than a check box,
it's more obvious. If it didn't do this, then it wouldn't know if you
let let the button up outside the button.
In this case you're not letting the button see mouse up messages, so it
never does a ReleaseCapture() - fortunately you can get the system to do
it for you by clicking in another window - the system allows this to
prevent an application taking over the mouse forever (you'd need a
system-wide hook to achieve this :-).
> You could also
> achieve what (I think) you are looking for by creating the control
> with the BS_CHECKBOX style, rather than the default BS_AUTOCHECKBOX.
> Then the control does not re-drw itself, and you have to tell it how
> it should look.
I'm not sure what you mean here... is it that you have to call
Checked(0) or Checked(1), or that you have to supply a user-draw routine
(I hope not!). Some experimentation, below, proves you mean the
former! This technique looks very workable.
Yes, that was what I meant.
Rob.
