[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
Re: [XaraXtreme-dev] Feather slider problem
- From: Alex Bligh <alex@xxxxxxxxxxx>
- Date: Wed, 05 Apr 2006 20:56:57 +0100
- Subject: Re: [XaraXtreme-dev] Feather slider problem
--On 05 April 2006 20:35 +0100 Phil Martin <phil@xxxxxxxx> wrote:
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
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.
I am not really worried about the above two cases. I am worried about what
happens if the selection changes whilst the slider is being dragged. For
instance if someone uses a key shortcut (e.g. "escape" or CTRL-U to
ungroup, or CTRL-A to select all) whilst dragging the slider. Even in a
perfectly deterministic world as far as message ordering is concerned, it
seems to me that would upset the feathering code (though I'm prepared to be
shown I'm wrong). I think this only works on windows because the
custom slider seems to eat all keypresses (see beeping when you
The reason DialogManager has to reinsert things into the message
queue is because sadly on wx you get the "thing changing" message
/before/ the thing has changed (so you can avoid calling event.skip()
and stop the underlying thing changing). This means that kernel
calls which call back into dialogmanager to do (e.g.) GetGadgetValue()
don't work as expected (they return the value before the change, not
after the change). On Windows, that's not how it (seems to) work.
Note that the message queue is strictly ordered, so I don't think
there's actually any difference here.