[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]

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.

Phil

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 combination of the scroll messages and the back compatibility update message, which
is wrong.

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
message.

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
processed.

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.

Alex