Re: [XaraXtreme-dev] Feather slider problem

[Alex Bligh <alex@xxxxxxxxxxx>]

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