Need Help Fixing Compile Error

While I'm making great progress in understanding and applying wxPython, I
have other python hurdles to overcome by learning. This morning, I've been
trying to understand just what is the appropriate syntax to fix this error:

[rshepard@salmo]$ python eikos.py Traceback (most recent call last):
   File "eikos.py", line 25, in ?
     main()
   File "eikos.py", line 21, in main
     application = BoaApp(0)
   File "/usr/lib/python2.4/site-packages/wx-2.6-gtk2-ansi/wx/_core.py", line 7473, in __init__
     self._BootstrapApp()
   File "/usr/lib/python2.4/site-packages/wx-2.6-gtk2-ansi/wx/_core.py", line 7125, in _BootstrapApp
     return _core_.PyApp__BootstrapApp(*args, **kwargs)
   File "eikos.py", line 15, in OnInit
     self.main = eikosFrame1.create(None)
   File "/mnt/usr2/fuzzy/eikos/ui/eikosFrame1.py", line 10, in create
     return Frame1(parent)
   File "/mnt/usr2/fuzzy/eikos/ui/eikosFrame1.py", line 257, in __init__
     self._init_ctrls(parent)
   File "/mnt/usr2/fuzzy/eikos/ui/eikosFrame1.py", line 235, in _init_ctrls
     self.framepanel1.SetBestFittingSize(wx.Size(750, 500))
   File "/usr/lib/python2.4/site-packages/wx-2.6-gtk2-ansi/wx/_core.py", line 8089, in SetBestFittingSize
     return _core_.Window_SetBestFittingSize(*args, **kwargs)
TypeError: argument number 1: a 'wxWindow *' is expected, 'modModel' is received.

   The file, eikosFrame1.py, was done in Boa; the file modModel.py written in
emacs. Despite my thrashing around, I have not identified just what window
object is needed in line 235 of the first listed file.

   I'm trying to put the contents of modModel on the first page of the
notebook in eikosFrame1. If there's a better way to do this, please clue me
in so I can do the other five notebook pages properly.

TIA,

Rich

shepard.tgz (5.67 KB)

···

--
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

Rich Shepard wrote:

TypeError: argument number 1: a 'wxWindow *' is expected, 'modModel' is received.

FWIW, I get these errors whenever I try to call certain functions on the object before it's passed through the entire creation process. IOW, put such calls after the __init__() is over, or at least after pre.Create() has completed.

···

--
Paul McNett
http://paulmcnett.com
http://dabodev.com

Paul,

   So, in my case, where do you suggest it go? Just before the event handlers?
When I try this, I'm still not sufficiently clued to know what parent should
be referenced in that assignment.

Thanks,

Rich

···

On Mon, 21 Nov 2005, Paul McNett wrote:

FWIW, I get these errors whenever I try to call certain functions on the
object before it's passed through the entire creation process. IOW, put
such calls after the __init__() is over, or at least after pre.Create() has
completed.

--
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

Rich,

It strikes me that most of your difficulties stem from trying to mix Boa-generated code and hand-written code. This is challenging!

If Boa can meet your needs, use it. If not, you might as well do it all by hand. If you really want a GUI GUI-Builder, use one that is designed from the beginning to be used with sizers, and with hand-written code:

wxGlade, wxDesigner, xrced or DialogBlocks.

-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

It strikes me that most of your difficulties stem from trying to mix
Boa-generated code and hand-written code. This is challenging!

   Yup.

If Boa can meet your needs, use it. If not, you might as well do it all by
hand. If you really want a GUI GUI-Builder, use one that is designed from
the beginning to be used with sizers, and with hand-written code:

   I'm rather a CLI bigot. I prefer emacs to using the trackball.

   Can you offer suggestions how to convert the Boa-generated eikosFrame1.py
to plain python? I think that's the only file that needs converting as I'm
doing modPolicy.py now, and eikos.py should be OK.

Thanks,

Rich

···

On Mon, 21 Nov 2005, Chris Barker 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

Rich Shepard wrote:

  So, in my case, where do you suggest it go? Just before the event handlers?
When I try this, I'm still not sufficiently clued to know what parent should
be referenced in that assignment.

Well, your modModel has two __init__ functions defined, which means it is the second one that will fire. The second one doesn't call wx.Panel.__init__(), so wx.Panel is never __init__'d.

Didn't someone else already tell you about this problem? I swear I saw something like this recently, but I'm sure I could be wrong.

Before anyone can help you, you have to look at the two __init__ functions in modModel.py, and figure out which one to keep or how to merge what they do into one __init__. And that __init__ needs to call wx.Panel.__init__() in order to initialize wx.Panel.

I've never done MVC before, but I was surprised to see a wx.Panel as your model. I thought that models were supposed to be simple objects that only describe your data/structure or whatever, and that the view is what actually displays it to the user and lets them edit. If I'm way off base here, please forgive me.

···

--
Paul McNett
http://paulmcnett.com
http://dabodev.com

Well, your modModel has two __init__ functions defined, which means it is
the second one that will fire. The second one doesn't call
wx.Panel.__init__(), so wx.Panel is never __init__'d.

   Sigh. Boa vs. hand written. Thanks.

Didn't someone else already tell you about this problem? I swear I saw
something like this recently, but I'm sure I could be wrong.

   I did fix it in that file but didn't see it here.

I've never done MVC before,

   What's MVC? I don't think I've ever done one either.

... but I was surprised to see a wx.Panel as your model.

   Perhaps you're confusing an application type with some sort of key word.
My application is an approximate reasoning model. Hence, I refer to
components of the model using that moniker. I'm using wx.Panel as a place to
put widgets into a notebook page.

Thanks,

Rich

···

On Mon, 21 Nov 2005, Paul McNett 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

Rich Shepard wrote:

  Perhaps you're confusing an application type with some sort of key word.
My application is an approximate reasoning model. Hence, I refer to
components of the model using that moniker. I'm using wx.Panel as a place to
put widgets into a notebook page.

Okay, my bad! :slight_smile:

···

--
Paul McNett
http://paulmcnett.com
http://dabodev.com

Rich Shepard wrote:

  What's MVC? I don't think I've ever done one either.

A design pattern called "Model-View-Controller". For a decent starting point, check out http://www.phpwact.org/pattern/model_view_controller. My only quibble with the article is the comment near the end: " Implementing MVC is complex and difficult." I'd say rather that there's a defnite learning curve, but once you've grokked it, it's not bad at all.

For me, a prime benefit of it is that the Model can be developed first, and tested out conveniently using test-driven development with Python's unittest module. Having the model tested and reliable simplifies the development of the V and C considerably.

I like to think about MVC this way:

    * The View is connected to the user's eyes;
    * the Controller is connected to the user's hands;
    * and the Model is connected to the user's mind.

I wouldn't push the image too far, but it soimetimes helps me to sort out design issues.

Don Dwiggins
Advanced Publishing Technology

Thank you, Don.

Rich

···

On Mon, 21 Nov 2005, Don Dwiggins wrote:

A design pattern called "Model-View-Controller". For a decent starting
point, check out http://www.phpwact.org/pattern/model_view_controller. My
only quibble with the article is the comment near the end: " Implementing
MVC is complex and difficult." I'd say rather that there's a defnite
learning curve, but once you've grokked it, it's not bad at all.

--
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

Patterns are not an easy thing to grok BUT they do prove usefull and once you "get them" the quality of your code starts to improve, at least I like to believe I'm a better coder aftere reading Gamma &friends.

For user interfaces rather than MVC.... I would recomand going one step further and using MVP (Model-View-Presenter) better yet use the PresenterFirst approach BUT to be honest, for a begginer, any kind of sepparation between what an application looks like (View) and what it is (Model) is good.

Peter.

···

On Tue, 22 Nov 2005 01:00:27 +0200, Don Dwiggins <ddwiggins@advpubtech.com> wrote:

Rich Shepard wrote:

  What's MVC? I don't think I've ever done one either.

A design pattern called "Model-View-Controller". For a decent starting point, check out http://www.phpwact.org/pattern/model_view_controller. My only quibble with the article is the comment near the end: " Implementing MVC is complex and difficult." I'd say rather that there's a defnite learning curve, but once you've grokked it, it's not bad at all.

For me, a prime benefit of it is that the Model can be developed first, and tested out conveniently using test-driven development with Python's unittest module. Having the model tested and reliable simplifies the development of the V and C considerably.

I like to think about MVC this way:

    * The View is connected to the user's eyes;
    * the Controller is connected to the user's hands;
    * and the Model is connected to the user's mind.

I wouldn't push the image too far, but it soimetimes helps me to sort out design issues.

Peter Damoc wrote:

for a begginer, any kind of sepparation between what an application
looks like (View) and what it is (Model) is good.

Microsoft call this Doc/View (Document and View architecture) in MFC, and
while I don't use it myself it is usually enough of a separation. [I'm sure
you already know this Peter; I'm just adding it to the conversation for
completeness].

Regards,

Steven

Doc/View framework is another bunch of patterns :slight_smile:

to be honest I never used it :slight_smile: I know we have it in wxPython, kudos to Peter Yared, but... I didn't feel the need for it.
I guess I didn't use it because I've come to wxPython from Java not MFC :wink:

Peter.

···

On Tue, 22 Nov 2005 06:56:36 +0200, Steven Reddie <smr@essemer.com.au> wrote:

Peter Damoc wrote:

for a begginer, any kind of sepparation between what an application
looks like (View) and what it is (Model) is good.

Microsoft call this Doc/View (Document and View architecture) in MFC, and
while I don't use it myself it is usually enough of a separation. [I'm sure
you already know this Peter; I'm just adding it to the conversation for
completeness].

Rich Shepard wrote:

  I'm rather a CLI bigot. I prefer emacs to using the trackball.

me too, which is why I've never used Boa. Well, that and the fact that it only recently used sizers.

  Can you offer suggestions how to convert the Boa-generated eikosFrame1.py
to plain python?

Toss the Boa code, and re-write it. It appears you've put far more effort into trying to figure out the Boa code than you have figuring out wxPython!

As a rule, machine-generated code is not to be messed with...a good reason not to use machine-generated code. However, I suppose there were once machine language jockies that said the same thing about compilers!

-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