I am having troubles with wxListBox::SetSelection(int n, const bool select = TRUE).
I have defined my ListBox to have an event and I'm using the function call EVT_LISTBOX.
In another part of my code I am setting my ListBox with selected values (e.g., set_list_box).
The first time I call my function set_list_box with the "SetSelection" function, the event function
is not called (as expected). By definition the "SetSelection" does not cause EVT_LISTBOX events
to get emitted.
The second time through the set_list_box function, the "SetSelection" function causes the
EVT_LISTBOX event function to be called.
How can I stop the "SetSelection" function from executing the EVT_LISTBOX function?
How can I stop the "SetSelection" function from executing the
EVT_LISTBOX function?
Sometimes the platform emits events when wxWindows isn't expecting them, for
example different versions of the MS Common Controls will behave very
differently in some areas. Unfortunately that means that the docs sometimes
lie about things like this...
On way to get around it is to just guard against it in your handler:
def OnListBox(self, event):
if not self.in_set_list_box:
## do other stuff
You can also disconnect the event handler using wxEvtHandler.Disconnect, and
then reconnect it with EVT_LISTBOX or the .Connect method, but I think the
above is easier and it works just fine.
def OnListBox(self, event):
if not self.in_set_list_box:
## do other stuff
You can also disconnect the event handler using wxEvtHandler.Disconnect, and
then reconnect it with EVT_LISTBOX or the .Connect method, but I think the
above is easier and it works just fine.
···
--
Robin Dunn
Well, that solution is exactly what we tried and it didn't work either. We
speculated that somehow the events were getting queued up somewhere and not
arriving until we had set the flag back. Maybe we are just unclear on the
concept.
Robin wrote, about a SetSelection that seems to trigger events:
One way to get around it is to just guard against it in your handler:
[...]
Well, that solution is exactly what we tried and it didn't work either. We
speculated that somehow the events were getting queued up somewhere and
not
arriving until we had set the flag back. Maybe we are just unclear on the
concept.
Hmm... let me guess, this is on wxGTK, right? wxGTK postpones a number of
things to happen in idle time, (to avoid certain race conditions, reduce
unnecesary traffic to the X server, etc.) and although this is not one of
the places I would have expected it, a quick check of the code shows that
when the callback happens the event is put in the pending queue rather than
being processed immediately...
On the other hand, in wxListBox::SetSelection the code that updates the
gtk_list is surrounded by calls to GtkDisableEvents() and GtkEnableEvents(),
so it looks like the events should not be happening, as expected.
I've just tried to duplicate this and I can't. What version of gtk+ do you
have? (Mine is 1.2.8)
I suspect that wxPython/GTK is postponing [all] events until a later time.
Is there a way to FLUSH the event immediately? This may solve a lot of my
problems. From the Xlib environment, I used XFlush to send all queued
requests to the server immediately; or XSync to flush the request buffer and
wait for all events and errors to be processed by the server. From the Motif
environment, I used XmUpdateDisplay to cause all pending events to be processed
immediately instead of having them remain in the queue.
How can I do a similar thing in wxPython. I think if I can force the queue to
flush, then I can solve this problem and others that I am having.
Thanks for your help.
Best regards,
Dean
···
> Robin wrote, about a SetSelection that seems to trigger events:
>
> One way to get around it is to just guard against it in your handler:
>
[...]
> Well, that solution is exactly what we tried and it didn't work either. We
> speculated that somehow the events were getting queued up somewhere and
not
> arriving until we had set the flag back. Maybe we are just unclear on the
> concept.
Hmm... let me guess, this is on wxGTK, right? wxGTK postpones a number of
things to happen in idle time, (to avoid certain race conditions, reduce
unnecesary traffic to the X server, etc.) and although this is not one of
the places I would have expected it, a quick check of the code shows that
when the callback happens the event is put in the pending queue rather than
being processed immediately...
On the other hand, in wxListBox::SetSelection the code that updates the
gtk_list is surrounded by calls to GtkDisableEvents() and GtkEnableEvents(),
so it looks like the events should not be happening, as expected.
I've just tried to duplicate this and I can't. What version of gtk+ do you
have? (Mine is 1.2.8)
--
Dean N. Williams
Computer Scientist/Computation Group Leader o
Lawrence Livermore National Laboratory --
Livermore, California 94550 `\< *
Phone: (925) 423-0145 FAX: (925) 422-7675 / \ http://www-pcmdi.llnl.gov williams13@llnl.gov
I suspect that wxPython/GTK is postponing [all] events until a later
time.
Is there a way to FLUSH the event immediately? This may solve a lot of
my
problems. From the Xlib environment, I used XFlush to send all queued
requests to the server immediately; or XSync to flush the request
buffer and
wait for all events and errors to be processed by the server. From the
Motif
environment, I used XmUpdateDisplay to cause all pending events to be
processed
immediately instead of having them remain in the queue.
How can I do a similar thing in wxPython. I think if I can force the
queue to
flush, then I can solve this problem and others that I am having.
It's not quite the same thing, but a call to wxYield should do it for you.
It will process any pending events from the platform and will also process
IDLE events so anything that wxGTK has postponed until idle time should
happen before wxYield returns.