Debugging Help Needed

wxPython Users
1

When I try to run my application (just a frame with a menu, status bar, and
notebook so far) I keep getting this error:

   File "eikos.py", line 246, in ?
     frame_1 = MyFrame(None, -1, "")
   File "eikos.py", line 86, in __init__
     self.Bind(wx.EVT_MENU, self.OnFileOpen, id=101)
AttributeError: 'MyFrame' object has no attribute 'OnFileOpen'

   The referenced line reads:

     self.Bind(wx.EVT_MENU, self.OnFileOpen, id=101)

and the same code (minus some menu items) runs in another application.

   Running the application under the debugger ('python -m pdb eikos.py') does
not give me any more insight. I've spent several hours looking and cannot see
what's different between the two applications, or just why this one will not
run. The file is 9104 bytes.

   I'd really appreciate someone pointing out to me why this error occurs.
That way I can learn to do it right and correct similar errors in the same
file.

TIA,

Rich

···

--
Richard B. Shepard, Ph.D. | Author of "Quantifying Environmental
Applied Ecosystem Services, Inc. (TM) | Impact Assessments Using Fuzzy Logic"
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

2

Let's try the obvious first: are you sure that there is a method named 'OnFileOpen' in your MyFrame class? Make sure that the capitalization matches.

-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com

···

On Nov 22, 2005, at 6:09 PM, Rich Shepard wrote:

AttributeError: 'MyFrame' object has no attribute 'OnFileOpen'

3

Ed,

   That's the first thing I checked. Here's the method as copied from the
source file:

    def OnFileOpen(self, event):
         dlg = wx.FileDialog(self, "Choose a file", ".", "", "*.*", wx.OPEN)
         try:
             if dlg.ShowModal() == wx.ID_OK:
                 filename = dlg.GetPath()
                 self.model.LoadFile(filename)
                 self.FileName = filename
                 self.SetTitle(('Eikos - %s') % filename)
         finally:
             dlg.Destroy()

Thanks for the quick response,

Rich

···

On Tue, 22 Nov 2005, Ed Leafe wrote:

AttributeError: 'MyFrame' object has no attribute 'OnFileOpen'

  Let's try the obvious first: are you sure that there is a method named
'OnFileOpen' in your MyFrame class? Make sure that the capitalization
matches.

--
Richard B. Shepard, Ph.D. | Author of "Quantifying Environmental
Applied Ecosystem Services, Inc. (TM) | Impact Assessments Using Fuzzy Logic"
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

4

Ed,

   I've also checked that the punctuation is correct (commas and not periods),
that the indentation is consistent, and that there are no typographic errors.

Rich

···

On Tue, 22 Nov 2005, Ed Leafe wrote:

  Let's try the obvious first: are you sure that there is a method named
'OnFileOpen' in your MyFrame class? Make sure that the capitalization
matches.

--
Richard B. Shepard, Ph.D. | Author of "Quantifying Environmental
Applied Ecosystem Services, Inc. (TM) | Impact Assessments Using Fuzzy Logic"
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

5

Ed,

   Continuing with the obvious, I found indentation errors. When I fixed that,
this error was resolved. Now I have another one, but that is almost certainly
another syntactical error on my part:

     self.Bind(wx.EVT_MENU, self.OnPolicyRem, 203)
   File "/usr/lib/python2.4/site-packages/wx-2.6-gtk2-ansi/wx/_core.py", line 3435, in Bind
     id = source.GetId()
AttributeError: 'int' object has no attribute 'GetId'

   So, I'm carefully reviewing the code to determine just what typo caused
this.

Thanks,

Rich

···

On Tue, 22 Nov 2005, Ed Leafe wrote:

AttributeError: 'MyFrame' object has no attribute 'OnFileOpen'

--
Richard B. Shepard, Ph.D. | Author of "Quantifying Environmental
Applied Ecosystem Services, Inc. (TM) | Impact Assessments Using Fuzzy Logic"
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

6

Rich Shepard wrote:

that the indentation is consistent

Actually, you missed that one. See my personal note to you.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

7

     self.Bind(wx.EVT_MENU, self.OnPolicyRem, 203)
   File "/usr/lib/python2.4/site-packages/wx-2.6-gtk2-ansi/wx/_core.py", line 3435, in Bind
     id = source.GetId()
AttributeError: 'int' object has no attribute 'GetId'

   So, I'm carefully reviewing the code to determine just what typo caused
this.

In this case, you are using .Bind() incorrectly.

Let's see what wxPython has to say about .Bind():

import wx
help(wx.Frame.Bind)

Bind(self, event, handler, source=None, id=-1, id2=-1) unbound
wx._windows.Frame method
    Bind an event to an event handler.
[...]

You are passing the integer 203 as the source parameter. python help
has more to say about the source parameter:

    :param source: Sometimes the event originates from a
                  different window than self, but you still
                  want to catch it in self. (For example, a
                  button event delivered to a frame.) By
                  passing the source of the event, the event
                  handling system is able to differentiate
                  between the same event type from different
                  controls.

So, wxPython is expecting a window (a wx.Button or a wx.Frame or
something) but you are giving it an integer.

Personally, I don't see much use for the source parameter. If, say,
you've just constructed a button:

btn = wx.Button(self, label='My Button')

then it makes much more sense to me to do:

btn.Bind(wx.EVT_BUTTON, self.OnMyButton)

than to do:

self.Bind(wx.EVT_BUTTON, self.OnMyButton, btn)

But YMMV, etc..
[and you do need to do it that was in the case of menus, because
wx.MenuItem instances don't have a .Bind method)]

HTH!

···

On 23/11/05, Rich Shepard <rshepard@appl-ecosys.com> wrote:

--
John.

8

Chris,

   Yeah, I finally saw that ... and fixed it. I also found the source of the
next error about the 'int' not having a value.

   I'm getting a better search image for what needs to be checked.

Rich

···

On Tue, 22 Nov 2005, Chris Barker wrote:

Actually, you missed that one. See my personal note to you.

--
Richard B. Shepard, Ph.D. | Author of "Quantifying Environmental
Applied Ecosystem Services, Inc. (TM) | Impact Assessments Using Fuzzy Logic"
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

9

  Continuing with the obvious, I found indentation errors. When I fixed that,
this error was resolved.

     Glad to hear that!

Now I have another one, but that is almost certainly
another syntactical error on my part:

    self.Bind(wx.EVT_MENU, self.OnPolicyRem, 203)
  File "/usr/lib/python2.4/site-packages/wx-2.6-gtk2-ansi/wx/_core.py", line 3435, in Bind
    id = source.GetId()
AttributeError: 'int' object has no attribute 'GetId'

  So, I'm carefully reviewing the code to determine just what typo caused
this.

     I assume that the 203 in the Bind call is the ID? If so, try specifying "id=203" instead (without the quotes). Most likely the next parameter in the Bind definition is named 'source', based on the error message.

     I hate to always sound like a cheerleader for Dabo, but looking at what you have to go through in raw wxPython makes me glad I don't have to code like that anymore! In Dabo, you can pass a function to the call to create a menu item, and the framework handles all this stuff for you. After all, how often do you create a menu item without binding a function to it?

-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com

···

On Nov 22, 2005, at 7:08 PM, Rich Shepard wrote:

10

  I assume that the 203 in the Bind call is the ID? If so, try specifying
"id=203" instead (without the quotes). Most likely the next parameter in
the Bind definition is named 'source', based on the error message.

Ed,

   That's exactly what it was. I had done some changes but hadn't finished
until it popped up again.

  I hate to always sound like a cheerleader for Dabo, but looking at what
you have to go through in raw wxPython makes me glad I don't have to code
like that anymore! In Dabo, you can pass a function to the call to create a
menu item, and the framework handles all this stuff for you. After all, how
often do you create a menu item without binding a function to it?

   I agree that short-cuts and automation are tremendous productivity tools
... once you really know what you're doing. As I'm just now learning python
and wxPython, doing it all by hand is teaching me a lot more than if I used a
tool that hid me from the details.

   An analogy is the use of LyX (the GUI front end) instead of writing LaTeX
in Emacs. Or, worse yet, raw TeX. But, to use LyX effectively one still needs
to know all about LaTeX. And knowing PSTricks helps, too, for producing
graphics. However, after a half-dozen plus years of using LaTeX I can be much
more productive with LyX. (Until it's time to produce a book index, of
course.)

   Once I know python/wxPython well I'll probably use a tool like Dabo, Boa,
or the like. In the meantime, it takes me a lot longer, but I understand
more.

Many thanks for your patient help,

Rich

···

On Tue, 22 Nov 2005, Ed Leafe wrote:

--
Richard B. Shepard, Ph.D. | Author of "Quantifying Environmental
Applied Ecosystem Services, Inc. (TM) | Impact Assessments Using Fuzzy Logic"
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

11

Well, wxPython hides you from a lot of the details of dealing with the C++ code used in wxWidgets. I don't know about you, but I'm satisfied not having to deal with those messy internals. wxPython at least provides a somewhat Pythonic experience when creating a UI.

     Dabo simply wraps wxPython, and hides even more of its C++ roots. It's style is even more Pythonic, and removes the inconsistencies and needless complexities that wxPython inherited from wxWidgets. I honestly don't think that working with Dabo "hides" you from anything you need to know.

-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com

···

On Nov 22, 2005, at 9:26 PM, Rich Shepard wrote:

  I agree that short-cuts and automation are tremendous productivity tools
... once you really know what you're doing. As I'm just now learning python
and wxPython, doing it all by hand is teaching me a lot more than if I used a
tool that hid me from the details.

12

Ed,

   I'm sure that Dabo is an outstanding productivity tool, and I will be
taking a very close look at it in the not-too-distant future. Now, however,
I'm very much in learning mode.

   I know C++ only superficially, having used C for the applications I've
coded since the late 1980s. Python is my OO language of choice and it will
take me a bit to get up to speed with it.

Rich

···

On Tue, 22 Nov 2005, Ed Leafe wrote:

  Dabo simply wraps wxPython, and hides even more of its C++ roots. It's
style is even more Pythonic, and removes the inconsistencies and needless
complexities that wxPython inherited from wxWidgets. I honestly don't think
that working with Dabo "hides" you from anything you need to know.

--
Richard B. Shepard, Ph.D. | Author of "Quantifying Environmental
Applied Ecosystem Services, Inc. (TM) | Impact Assessments Using Fuzzy Logic"
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

13

Cool - I just didn't want you to get the impression that using Dabo instead of raw wxPython is like learning to ride a bike by using training wheels, and that at some point you're going to have to lose the training wheels if you want to get serious.

-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com

···

On Nov 23, 2005, at 12:18 PM, Rich Shepard wrote:

  I'm sure that Dabo is an outstanding productivity tool, and I will be
taking a very close look at it in the not-too-distant future. Now, however,
I'm very much in learning mode.

14

Ed Leafe wrote:

    Cool - I just didn't want you to get the impression that using Dabo instead of raw wxPython is like learning to ride a bike by using training wheels, and that at some point you're going to have to lose the training wheels if you want to get serious.

Well, no, it doesn't look like that at all, but it's also not complete, and on some level may never be complete. What this means is that if you use it now, you may very well need to do something that you can't do with Dabo, and you'll need to to write a little "raw" wxPython code to do it (ideally contributing that functionality in the process). given that, there is probably a need to learn a little raw wxPython at some point.

You may not need to take off the training wheels, but you may need to fix the bike, or add an accessory.

This is the same situation as wxPython vs. C++ wx, except that by using automatically generated "thin" wrappers, Robin has managed to get almost all of wx wrapped, so it's rare to need C++.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

15

Perhaps, but instead of turning to wxPython, you could write to us and explain what it is you want to do. One of the ways that open source projects grow is by people expressing a need that has to be filled. I recently implemented the drawing layer in dabo.ui based upon a request to access the whole wx.DC system. While we haven't included *everything* that is possible to do with wx.DC, we've made the whole thing object-oriented, and these drawn objects persist without having to write code to constantly redraw them in Paint events. They have properties, too, so you can alter them as you wish. So you can think about these drawn items as you would any other UI element, and can safely ignore wx.DC altogether! And if there are any other DC-related functions that someone needs, just ask, and I'll be glad to implement those, too.

-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com

···

On Nov 23, 2005, at 2:41 PM, Chris Barker wrote:

Well, no, it doesn't look like that at all, but it's also not complete, and on some level may never be complete. What this means is that if you use it now, you may very well need to do something that you can't do with Dabo, and you'll need to to write a little "raw" wxPython code to do it (ideally contributing that functionality in the process). given that, there is probably a need to learn a little raw wxPython at some point.

16

Ed Leafe wrote:

I recently implemented the drawing layer in dabo.ui based upon a request to access the whole wx.DC system. While we haven't included *everything* that is possible to do with wx.DC, we've made the whole thing object-oriented, and these drawn objects persist without having to write code to constantly redraw them in Paint events. They have properties, too, so you can alter them as you wish.

Very cool! Did you look at wx.lib.FloatCanvas?, it does many of the same things, isolating people from DCs and paint events being two of them. I wonder if I should look at what you've done for ideas.

You folks are moving very fast with Dabo development. I'm quite impressed.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov