[wxPython] problem with EVT_ macros

[wxPython 2.2.2, Python 2.0, Win2K]

I just upgraded to Python 2.0 (and the corresponding versions of everything else) and now I am seeing some strange behavior from the EVT_ macros. Before describing the problem, I'll say that I am about 90% sure that this did not occur with wxPython 2.2.2 under Python 1.5.2.

I regularly use the EVT_ calls to change registered event handlers. For example, I may have a class like this:
class TempFrame(wxFrame):
   def OnClose(self,event):
     print 'oc1'
     self.Destroy()
   def OnHide(self,event):
     print 'hide1'
     self.Show(0)

   def __init__(self, parent, ID, title):
     wxFrame.__init__(self, parent, ID, title, wxDefaultPosition,
                      (300,300))
     EVT_CLOSE(self,self.OnClose)

Where, by default, I want the close box to actually destroy the frame. Sometimes though I want the same class to just hide the frame so that I can redisplay it later without having to rebuild everything. With this TempFrame class, I'd do something like:
EVT_CLOSE(tempFrameObject,tempFrameObject.OnHide)
this worked just fine with wxPython 2.2.2 under Python 1.5.2. Now, however, that second EVT_CLOSE call does nothing at all. In fact, after a bit of playing around, I've discovered that once you make an EVT_ call under Python 2.0, you are stuck for all time with that handler you installed. There appears to be no way of getting rid of it.

I've attached a file to this message which demonstrates the problems. On my machine closing each of the frames results in the following calls:
frame1 -> OnClose (should be OnHide)
frame2 -> OnHide (should be OnClose)
frame3 -> OnHide (this is okay, I used Connect and Disconnect).

I need to know if this is the correct behavior. I have a lot of code which depends upon changing event handlers and if I can't rely upon being able to do this using the EVT_ macros I'm going to have to go back and make a lot of changes.

(of course, I'm doing a big demo in a week and half, so I'll either have to switch back to python 1.5.2 or make those changes anyway)

cheers,
-greg

test.py (1.47 KB)

Where, by default, I want the close box to actually destroy the
frame. Sometimes though I want the same class to just hide the frame so
that I can redisplay it later without having to rebuild everything. With
this TempFrame class, I'd do something like:
EVT_CLOSE(tempFrameObject,tempFrameObject.OnHide)
this worked just fine with wxPython 2.2.2 under Python 1.5.2. Now,
however, that second EVT_CLOSE call does nothing at all. In fact, after a
bit of playing around, I've discovered that once you make an EVT_ call
under Python 2.0, you are stuck for all time with that handler you
installed.

Well the version of Python should have nothing to do with this, but it may
have just been an accident that it worked for you before. If you look at
the implementation of the EVT_* functions they all wrap the win.Connect
method. This *adds* an entry to a dynamic event dispatch table without
checking if it's already there. So if you call some EVT_* function 1000
times with the same info then you'll have 1000 entries in this table, and if
the event handler calls event.Skip() then it will be called 1000 times when
the event happens.

There appears to be no way of getting rid of it.

Call win.Disconnect(). (Hint: you can pass -1 for the id's to act as
wildcards.)

···

--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters?
http://wxPython.org Relax with wxPython!

_______________________________________________
wxPython-users mailing list
wxPython-users@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/wxpython-users

Well the version of Python should have nothing to do with this, but it may
have just been an accident that it worked for you before. If you look at
the implementation of the EVT_* functions they all wrap the win.Connect
method. This *adds* an entry to a dynamic event dispatch table without
checking if it's already there. So if you call some EVT_* function 1000
times with the same info then you'll have 1000 entries in this table, and if
the event handler calls event.Skip() then it will be called 1000 times when
the event happens.

I had looked into this. Is it possible that, at some point, the order in which things are added to the dispatch table was changed? The behavior I see is consistent with the build I have for Python 1.5.2 adding new entries to the beginning of the table (so only the new handler is called so long as not event.Skip() is called) and the build for Python 2.0 adding to the end (so the new handler is never reached unless event.Skip() is called).

> There appears to be no way of getting rid of it.

Call win.Disconnect(). (Hint: you can pass -1 for the id's to act as
wildcards.)

Thanks for this tip.

-greg

···

At 12:11 PM 2/7/2001, you wrote:

----
greg Landrum (greglandrum@earthlink.net)
Software Carpenter/Computational Chemist

_______________________________________________
wxPython-users mailing list
wxPython-users@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/wxpython-users

I had looked into this. Is it possible that, at some point, the order in
which things are added to the dispatch table was changed?

It's possible, but it would have nothing to do with the version of Python,
only the version of wxWindows. You said you're using 2.2.2 for each, right?

···

--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters?
http://wxPython.org Relax with wxPython!

_______________________________________________
wxPython-users mailing list
wxPython-users@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/wxpython-users

yep, which is why I'm really confused.

-greg

···

At 12:35 PM 2/7/2001, you wrote:

> I had looked into this. Is it possible that, at some point, the order in
> which things are added to the dispatch table was changed?

It's possible, but it would have nothing to do with the version of Python,
only the version of wxWindows. You said you're using 2.2.2 for each, right?

----
greg Landrum (greglandrum@earthlink.net)
Software Carpenter/Computational Chemist

_______________________________________________
wxPython-users mailing list
wxPython-users@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/wxpython-users