> From: Peter Cleaveland
>
> I'm a big fan of a complete event model when I can get it. At
> first I was
> surprised to see the mouseMove() event, which was not present in
> HyperCard. But I assume it's there because wxWindows provides it, and I
> can see utility. In HC I used to do Drag handlers in a loop on
> mouseDown(), but it would be more natural to use mouseMove(), so
> as not to
> block the thread.
There is a 'mouseDrag' event which occurs instead of 'mouseMove' if the
mouse button is down. The resourceEditor sample uses it. The event system
underlying wxPython doesn't support the type of 'on mouseDown' loop used in
HyperCard for the reason you mentioned, which is that it blocks the thread,
so neither does PythonCard. The main difference is that you need to make
sure that you set up your initialization and cleanup code correctly and then
don't block during each 'mouseMove' or 'mouseDrag' event.
Another thing that is different is that 'mouseDrag', 'mouseEnter' and
'mouseLeave' behave a bit differently than you might expect when you're
doing a drag that takes the cursor outside the rect of the widget. There is
a bug in wxWindows/wxPython that causes mouseEnter/mouseLeave events to fire
repeatedly which each drag. There are some related bugs, but we'll have to
wait until wxPython 2.3.2 comes out to see how it works in the new version.
> I'm in favor of keeping KeyDown and KeyUp. Some applications (especially
> games) can't be done without these events. Of course, if they slow down
> the event loop too much, I might wish for a way to turn them off. If
> performance became as issue, perhaps a set of flags could enable/disable
> each event type, with less common events turned off by default.
IIRC, when Rowland and I initially discussed how this would work I was in
favor of binding all events, all the time, but Rowland only wanted to bind
the ones being used. So, in Rowland's system no events would be generated
unless there was a corresponding handler to respond to the event such as
'on_button1_mouseClick'. wxPython would still be doing some events behind
the scenes, but they wouldn't go through the overhead of our event system,
be reported in the Message Watcher, etc.
It turned out that it was much easier to implement the event system by
binding all the events, but only dispatching if there was a handler
available. If you're learning or debugging, it is very helpful to see all
the messages, even the 'unused' ones. In addition, the system we currently
have in place means that theoretically you should be able to create a new
handler when the program is running and have it bind correctly, but I
haven't got it working yet.
Anyway, we can probably support both systems so that no binding is ever done
unless a handler exists to support an event when the programmer wants a more
static, efficient event flow. We'll need to revisit that idea later on, I
don't think it is appropriate to refactor right now.
ka
|
