Russell Keith-Magee wrote:
>
> It looks like the SEL_CHANGED event is not emitted until control returns
> to the main event polling loop.
Yes, this is a common thing to do, especially on the GTK port.
Deferring the processing of some things until all the pending events
have been processed allows the update of the display to be optimized.
Makes sense - however, does this imply that there are differences in the
behaviour associated with processing of events between platforms? e.g.,
Are there any differences in:
- which events are emitted?
- the order in which events are emitted?
- the point at which events are emitted in relation to the execution of
user code?
> 1) Is there a means by which I can force processing of outstanding
> events before my call to testMethod() (i.e., duplicate a small part of
> the main event polling loop to flush and process the SEL_CHANGED event)?
Calling wx.Yield() (or wx.GetApp().Yield) will probably do it, but
yielding is not recommended unless you *really* need it as it's possible
to get into a recursive event handling situation, etc.
>
> 2) Is there any other way I can get access to the updated selection in
> testMethod()?
You could just defer the call to testMethod using wx.CallAfter(testMethod)
Thanks; The wx.Yield() approach worked; wx.CallAfter() didn't.
wx.Yield() pulled all the selection events off the event queue and
processed them, no problems. I read up a little bit on Yield() - I don't
think the problems the wxWidgets docs refer to will affect me right at
the moment, but it looks like something that could come back to bite me
later on, so I would like to avoid this approach if I can.
wx.CallAfter() successfully deferred the call to testMethod(), but
didn't defer for long enough :-). The deferral still came before the
processing of the selection events. Given your earlier comment (vis GTK
event processing), I think I understand the problem, though. My method
(which now looks like):
def doDelete():
selection = tree.GetSelection()
tree.Delete(selection)
wx.CallAfter(testMethod)
is itself called as a result of being bound to an event (e.g., press a
button, delete the current tree selection). The tree.Delete() call emits
some events immediately, and causes some tree selection events to be
postponed; the CallAfter defers the call to testMethod(). The doDelete()
event callback returns, and because of the display update optimisation,
the CallAfter call gets scheduled before the selection event calls.
Have I got this right? Is there a way to work around this, other than to
use Yield()?
As a more general question (and I suspect not a wxPython specific one),
is there a reason that the SEL_CHANGED event occurs after the
DELETE_ITEM? It strikes me that the way they are is the wrong way
around, for precisely the reason I am having a problem with; the
selection is invalid during the DELETE callback.
Thanks again,
Russ Magee
···
On Tue, 2005-01-11 at 02:22, Robin Dunn wrote: