[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
Re: [XaraXtreme-dev] Feather slider problem
- From: Phil Martin <phil@xxxxxxxx>
- Date: Wed, 5 Apr 2006 20:35:28 +0100
- Subject: Re: [XaraXtreme-dev] Feather slider problem
In Windows slider events are generated in a deterministic fashion
with no possibility of any selection change event happening between
UPDATE and SET. The code was written in that environment and so if
we're now living in a world where the selection can change while the
user is dragging something then, yes, the code is "brittle".
This has just not been an issue before - and it possibly only becomes
an issue now because of the way the DialogManager posts message back
into the queue.
We might be able to make Camelot's slider handling more robust to
things happening out of sequence but there's no good reason for
things to happen out of sequence. Specifically: a slider should not
send "moving" events once it has sent an "end " event.
On 5 Apr 2006, at 20:16, Alex Bligh wrote:
Phil Martin wrote:
The trouble is caused by wxWidgets trying to be helpful and back-
compatible - any message it doesn't understand gets turned into a
SLIDER_UPDATED but it adds no extra information to distinguish
between these "fake" events and real SLIDER_UPDATED events.
Of course, we supplied the patch to make sliders send
THUMB_RELEASE events so it's probably only us who use them and
worry about the details of message order surrounding them. So this
new patch shouldn't adversely affect anyone else.
Actually I think what wxWidgets is doing is right. It's sending the
back compatibility message, and we are trying to hang off a
of the scroll messages and the back compatibility update message,
I have now fixed the slider message order by ONLY hanging off the
wxEVT_SCROLL messages. I think this fixes the symptom - could you
check, Phil? Essentially I am relying on the fact that
wxEVT_SCROLL_CHANGED is always last (and is generated on thumb
release too), and I am translating any of the mechanisms of
change (including keyboard shortcuts) into a /prior/ update
However, I remain concerned that we are only fixing the symptom
here. What seems to upset feathering is the following
message sequence being sent to it:
1. DIM_SLIDER_SET (from the end of a drag)
2. DIM_SLIDER_UPDATE (spurious)
3. Change of selection before another DIM_SLIDER_SET
4. (possibly) another DIM_SLIDER_UPDATE
Now this can in theory happen ANYWAY if someone manages to
change the selection between the deferred messages being
Isn't the /real/ fix here that a selection change should cancel
any "real-time" feather that hasn't yet made it into the undo
record? Or failing cancelling it, apply it?
Whilst I /think/ it's working now, it seems to be pretty brittle.