Oh, fair enough, I thought it was working
fine after I changed the mouse capture to go via the main frame. In that case I
presume it has something to do with if the button up happens before the button
down has been processed and the mouse has been captured then the button up gets
sent to the window the pointer is in rather than the window that has
(subsequently) captured the mouse. Whether the problem lies in wxWidgets or
inside GTK itself I don’t know but I’ll report it on the wx-dev
mailing list and see what they say... Gerry From:
owner-dev@xxxxxxxxxxxxxxxx [mailto:owner-dev@xxxxxxxxxxxxxxxx] On Behalf Of Neil Howe Yes, but this isn’t a new problem.
It’s always been like that since the color line was added for 0.3. I
don’t think it’s any better or worse now. Which reminds me I don’t think this
is logged in Bugzilla so I’ll add it, though there is another mouse-up
drag issue which may be related. Neil From:
owner-dev@xxxxxxxxxxxxxxxx [mailto:owner-dev@xxxxxxxxxxxxxxxx] On Behalf Of On my working copy colour drags appear to be broken in that
a quick click on the colour line doesn’t apply the colour but leaves a
button up drag in progress until you click again. A slightly slower click
works as expected and drags also work correctly. I’ve made a lot of
changes in my working copy (some are in the area of colour dragging but I
can’t see any obvious culprits) so could someone else confirm that they
see the same thing on a very fast click? Thanks, Gerry |