Hello again,
while playing with PyEvents with the aim to write very simple wrappers to
mimic the signal/slot qt mechanism, I found a bug in
wxPy(Command)Event.Skip: the call has no effect. This is true for Py
events only, not for the normal ones (and I think it's the reason why it
has not been discovered before).
Fortunately, the patch wasn't hard to write (assuming I wrote it
correctly, of course
Attached are the changes I made to make it work (I patched the .py file
and not the .i because I have no experience at all with SWIG...)
I'm attaching also the very lightweight wrappers I wrote (more as a
test-case than as something interesting.. I'm not even sure the
semantics is right)
Hello again,
while playing with PyEvents with the aim to write very simple wrappers to
mimic the signal/slot qt mechanism, I found a bug in
wxPy(Command)Event.Skip: the call has no effect. This is true for Py
events only, not for the normal ones (and I think it's the reason why it
has not been discovered before).
Thanks, I've just checked in a little different fix for this. Since you are using wx.PostEvent the event object is being cloned. The clone is put on the pending events queue and the original C++ object is normally destroyed when your emit() returns. As part of the cloning process these event types save a reference to themselves and pass this reference along to the clone, so the original object (along with any Python attributes) is preserved. The original object is what it passed to the event handler.
Basically for my fix if the object was cloned I just call the GetSkipped method of the original object and put that value back into the clone. It was all done in helpers.cpp without needing to hack the generated Python code.
Please update and test to make sure I didn't screw something up.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!