Re: [XaraXtreme-dev] Feather slider problem

[Phil Martin <phil@xxxxxxxx>]

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