Re: wx.Sizer Issue [UPDATE]

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: wx.Sizer Issue [UPDATE]

Rich Shepard
On Mon, 7 Jul 2014, Rich Shepard wrote:

   Fixed this (see below) but have another syntax error I haven't fixed.

>    self.SetSizer(self.outerBox)
      self.SetSizer(outerBox)  # fixes original problem

   The following is throwing the error, but it is the same as on the tutorial
page:
>    self.sizer.Fit(self)

   Traceback (most recent call last):
   File "./pw.py", line 92, in <module>
     frame = MainFrame(None, "PermitWatch")
   File "./pw.py", line 65, in __init__
     self.sizer.Fit(self)
AttributeError: 'MainFrame' object has no attribute 'sizer'

   Please correct my syntax error.

Rich

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: wx.Sizer Issue [UPDATE]

Nathan McCorkle
sizers don't have a Fit method... a panel or frame does though (because they inherit from wx.Window)... just remove the sizer from your call so it's like:
self.Fit(self)

see:
http://www.wxpython.org/docs/api/wx.Window-class.html#Fit

P.S. I think it's better netiquette to update the original post, rather than creating a new thread with UPDATE in the name. It destroys the linked-list/parent-child history of messages that are connected to each other.

On Monday, July 7, 2014 2:44:02 PM UTC-7, fuzzydoc wrote:
On Mon, 7 Jul 2014, Rich Shepard wrote:

   Fixed this (see below) but have another syntax error I haven't fixed.

>    self.SetSizer(self.outerBox)
      self.SetSizer(outerBox)  # fixes original problem

   The following is throwing the error, but it is the same as on the tutorial
page:
>    self.sizer.Fit(self)

   Traceback (most recent call last):
   File "./pw.py", line 92, in <module>
     frame = MainFrame(None, "PermitWatch")
   File "./pw.py", line 65, in __init__
     self.sizer.Fit(self)
AttributeError: 'MainFrame' object has no attribute 'sizer'

   Please correct my syntax error.

Rich

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: wx.Sizer Issue [UPDATE]

Tim Roberts
In reply to this post by Rich Shepard
Rich Shepard wrote:

> On Mon, 7 Jul 2014, Rich Shepard wrote:
>
>    Fixed this (see below) but have another syntax error I haven't fixed.
>
>>    self.SetSizer(self.outerBox)
>       self.SetSizer(outerBox)  # fixes original problem
>
>    The following is throwing the error, but it is the same as on the tutorial
> page:
>>    self.sizer.Fit(self)

Yes, but in the tutorial, he stored his outermost sizer in self.sizer:
    self.sizer = wx.BoxSizer(wx.VERTICAL)

You have stored your outermost sizer in the local name outerBox, so you
need:
    outerBox.Fit(self)

There's no need to have the sizer be a member (self.outerBox) if you
don't refer to it elsewhere.

--
Tim Roberts, [hidden email]
Providenza & Boekelheide, Inc.

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: wx.Sizer Issue [UPDATE]

Tim Roberts
In reply to this post by Nathan McCorkle
Nathan McCorkle wrote:
> sizers don't have a Fit method...

Yes, they do.

--
Tim Roberts, [hidden email]
Providenza & Boekelheide, Inc.

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: wx.Sizer Issue [UPDATE]

Rich Shepard
In reply to this post by Nathan McCorkle
On Mon, 7 Jul 2014, Nathan McCorkle wrote:

> sizers don't have a Fit method... a panel or frame does though (because
> they inherit from wx.Window)... just remove the sizer from your call so
> it's like:
> self.Fit(self)
>
> see:
> http://www.wxpython.org/docs/api/wx.Window-class.html#Fit

   OK. That makes sense.

> P.S. I think it's better netiquette to update the original post, rather
> than creating a new thread with UPDATE in the name. It destroys the
> linked-list/parent-child history of messages that are connected to each
> other.

   I was updating the original post. Does adding [UPDATE] to the subject
create a new thread? Haven't seen that on mailman-managed lists. Will leave
out subject line suffix from now on.

Thanks,

Rich



--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: wx.Sizer Issue [UPDATE]

Rich Shepard
In reply to this post by Tim Roberts
On Mon, 7 Jul 2014, Tim Roberts wrote:

> Yes, but in the tutorial, he stored his outermost sizer in self.sizer:
>    self.sizer = wx.BoxSizer(wx.VERTICAL)
>
> You have stored your outermost sizer in the local name outerBox, so you
> need:
>    outerBox.Fit(self)
>
> There's no need to have the sizer be a member (self.outerBox) if you
> don't refer to it elsewhere.

   Thanks, Tim. That really makes it clear.

Rich

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
C M
Reply | Threaded
Open this post in threaded view
|

Re: wx.Sizer Issue [UPDATE]

C M
In reply to this post by Rich Shepard



On Mon, Jul 7, 2014 at 5:43 PM, Rich Shepard <[hidden email]> wrote:
On Mon, 7 Jul 2014, Rich Shepard wrote:

  Fixed this (see below) but have another syntax error I haven't fixed.

   self.SetSizer(self.outerBox)
     self.SetSizer(outerBox)  # fixes original problem

  The following is throwing the error, but it is the same as on the tutorial
page:
   self.sizer.Fit(self)

  Traceback (most recent call last):
  File "./pw.py", line 92, in <module>
    frame = MainFrame(None, "PermitWatch")
  File "./pw.py", line 65, in __init__
    self.sizer.Fit(self)
AttributeError: 'MainFrame' object has no attribute 'sizer'

Since you had this sort of error twice now, may I chip in a quasi-philosophical and Python-relevant point, Rich?  The good news is that, at least to me, the AttributeError is often the easiest one to hunt down the problem, but it requires that you "really believe" the error message.  That is, if it says that MainFrame does not have some object named "sizer", then that means that you somewhere have "self.sizer" being used (since "self" refers to the instance of, in your case, the "MainFrame" class) but you never defined what "self.sizer" is anywhere, so the interpreter is thinking, "What does he mean, self.sizer?  Where did he say self has this thing called sizer?"

I know when I was earlier in programming in Python/wxPython these sorts of errors confused me, but now I am sort of relieved, because I know I merely forgot to put a self.sizer = ..... somewhere and it's an easy bug to fix.

 

  Please correct my syntax error.

Rich

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: wx.Sizer Issue [UPDATE]

Marc Tompkins
On Mon, Jul 7, 2014 at 4:32 PM, C M <[hidden email]> wrote:
The good news is that, at least to me, the AttributeError is often the easiest one to hunt down the problem, but it requires that you "really believe" the error message.  That is, if it says that MainFrame does not have some object named "sizer", then that means that you somewhere have "self.sizer" being used (since "self" refers to the instance of, in your case, the "MainFrame" class) but you never defined what "self.sizer" is anywhere, so the interpreter is thinking, "What does he mean, self.sizer?  Where did he say self has this thing called sizer?"

If I may chip in - I also was confused by AttributeErrors early on (mostly because Python was the first language where I actually "got" what object orientation is all about!), but now I almost welcome them because... well, if I'm going to make a mistake, at least it's an easy one to catch, right?  ;)

More to the point, though, this question seems to me like an excellent demonstration of why generic-sounding variable names are a terrible idea.  I realize that you're working from someone else's code, but if he could hear I would tell him too: DON'T name your sizers "sizer".  Call them MySizer, or Edger, or OuterBound, or... well, just  about _anything_ that doesn't make them sound like a built-in, generic property.  This sort of confusion - where a user-created attribute gets confused with a generic property - happens all too often.  The interpreter doesn't care at all what you name your variables - so make them easy to identify, understand, and remember.

(One option I've occasionally used - I'm not recommending it as standard practice, but it has worked for me - is to use a foreign language for my variable names.  If a variable has a clear meaning, by all means name it appropriately - GrandTotal, for example - but I might call a generic sizer "self.calibreur", just to make sure I won't

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: wx.Sizer Issue [UPDATE]

Marc Tompkins
On Mon, Jul 7, 2014 at 4:53 PM, Marc Tompkins <[hidden email]> wrote: 
>  a load of codswallop.

Sorry - I was re-editing and had just decided to cancel it instead; unfortunately I hit Send instead of Delete.

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
C M
Reply | Threaded
Open this post in threaded view
|

Re: wx.Sizer Issue [UPDATE]

C M
In reply to this post by Marc Tompkins



On Mon, Jul 7, 2014 at 7:53 PM, Marc Tompkins <[hidden email]> wrote:
On Mon, Jul 7, 2014 at 4:32 PM, C M <[hidden email]> wrote:
The good news is that, at least to me, the AttributeError is often the easiest one to hunt down the problem, but it requires that you "really believe" the error message.  That is, if it says that MainFrame does not have some object named "sizer", then that means that you somewhere have "self.sizer" being used (since "self" refers to the instance of, in your case, the "MainFrame" class) but you never defined what "self.sizer" is anywhere, so the interpreter is thinking, "What does he mean, self.sizer?  Where did he say self has this thing called sizer?"

If I may chip in - I also was confused by AttributeErrors early on (mostly because Python was the first language where I actually "got" what object orientation is all about!), but now I almost welcome them because... well, if I'm going to make a mistake, at least it's an easy one to catch, right?  ;)

More to the point, though, this question seems to me like an excellent demonstration of why generic-sounding variable names are a terrible idea.  I realize that you're working from someone else's code, but if he could hear I would tell him too: DON'T name your sizers "sizer".  Call them MySizer, or Edger, or OuterBound, or... well, just  about _anything_ that doesn't make them sound like a built-in, generic property.  This sort of confusion - where a user-created attribute gets confused with a generic property - happens all too often.  The interpreter doesn't care at all what you name your variables - so make them easy to identify, understand, and remember.

That's an excellent point, Marc!  Naming a sizer "sizer" is just asking for trouble, particularly as a beginner, for exactly the reasons you give. 

I am unashamedly a user of long inelegant object names, even to the point of backgroundSizerForMainFrame or textCtrlForTheUsersCookieRecipe.  You are just not going to have an instant's confusion when debugging as to what those objects are. (The less confused instants I have, the better.  There are still many, though :\ ).


--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: wx.Sizer Issue [UPDATE]

Rich Shepard
In reply to this post by Marc Tompkins
On Mon, 7 Jul 2014, Marc Tompkins wrote:

> More to the point, though, this question seems to me like an excellent
> demonstration of why generic-sounding variable names are a terrible idea.
> I realize that you're working from someone else's code, but if he could
> hear I would tell him too: DON'T name your sizers "sizer".

Marc,

   I was confused by the tutorial scripts use of the name 'sizer;' there are
several such variable names in the scripts.

   After moving from FORTRAN to C in the 1980s I learned to make variable
names meaningful to _me_. The compilers don't care. That's why, in the
fragments I posted, I use names such as:

     # Sizers
     outerBox = wx.BoxSizer(wx.VERTICAL)    # main container
     welcomeBox = wx.BoxSizer(wx.VERTICAL)  # logo and message
     unameBox = wx.BoxSizer(wx.HORIZONTAL)  # username container
     passwdBox = wx.BoxSizer(wx.HORIZONTAL) # password container
     buttonBox = wx.BoxSizer(wx.HORIZONTAL) # OK and Cancel buttons

so I know what they do. When there are multiple layers of controls/widgets
within sizers within panels within a notebook within a frame my simple mind
likes to see variable names that are descriptive.

Thanks for your thoughts,

Rich

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: wx.Sizer Issue [UPDATE]

Marc Tompkins



On Mon, Jul 7, 2014 at 5:09 PM, Rich Shepard <[hidden email]> wrote:
On Mon, 7 Jul 2014, Marc Tompkins wrote:

More to the point, though, this question seems to me like an excellent
demonstration of why generic-sounding variable names are a terrible idea.
I realize that you're working from someone else's code, but if he could
hear I would tell him too: DON'T name your sizers "sizer".

Marc,

  I was confused by the tutorial scripts use of the name 'sizer;' there are
several such variable names in the scripts.

  After moving from FORTRAN to C in the 1980s I learned to make variable
names meaningful to _me_. The compilers don't care. That's why, in the
fragments I posted, I use names such as:

    # Sizers
    outerBox = wx.BoxSizer(wx.VERTICAL)    # main container
    welcomeBox = wx.BoxSizer(wx.VERTICAL)  # logo and message
    unameBox = wx.BoxSizer(wx.HORIZONTAL)  # username container
    passwdBox = wx.BoxSizer(wx.HORIZONTAL) # password container
    buttonBox = wx.BoxSizer(wx.HORIZONTAL) # OK and Cancel buttons

so I know what they do. When there are multiple layers of controls/widgets
within sizers within panels within a notebook within a frame my simple mind
likes to see variable names that are descriptive.


That's _half_ of what I was getting at... the other half is that sometimes you need to write a generic helper function that works with (whatever sort of object; a sizer in this case).  It has to work with sizers from all over your project - or projects in the future - so what do you call it?  In cases like that, my imagination sometimes fails me, and that's where whimsical synonyms come in.  I have several functions in my toolkit that operate on a generic object... which I named "thingy".  In the case of a generic sizer, I have used "self.calibreur" on more than one occasion.

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: wx.Sizer Issue [UPDATE]

Rufus V. Smith
In reply to this post by C M


On Monday, July 7, 2014 7:59:10 PM UTC-4, Che M wrote:

On Mon, Jul 7, 2014 at 7:53 PM, Marc Tompkins <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="iaMPEK-8iB4J" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">marc.t...@...> wrote:
More to the point, though, this question seems to me like an excellent demonstration of why generic-sounding variable names are a terrible idea.  I realize that you're working from someone else's code, but if he could hear I would tell him too: DON'T name your sizers "sizer".  Call them MySizer, or Edger, or OuterBound, or... well, just  about _anything_ that doesn't make them sound like a built-in, generic property.  This sort of confusion - where a user-created attribute gets confused with a generic property - happens all too often.  The interpreter doesn't care at all what you name your variables - so make them easy to identify, understand, and remember.

That's an excellent point, Marc!  Naming a sizer "sizer" is just asking for trouble, particularly as a beginner, for exactly the reasons you give. 

I am unashamedly a user of long inelegant object names, even to the point of backgroundSizerForMainFrame or textCtrlForTheUsersCookieRecipe.  You are just not going to have an instant's confusion when debugging as to what those objects are. (The less confused instants I have, the better.  There are still many, though :\ ).

 
I am a fan of long variable names normally, but often with frames, panels, sizers, buttons, etc, that only last for about 4 lines of code, I may call them frm, pnl, szr, btn respectively.   When the mood strikes me, I'll use pseudo-Hungarian notation like Visual Basic programmers are known to use, e.g. szrOuter,  btnUp, btnCloseFile, etc...

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: wx.Sizer Issue [UPDATE]

Marc Tompkins
On Tue, Jul 8, 2014 at 2:29 PM, Rufus <[hidden email]> wrote:
 
I am a fan of long variable names normally, but often with frames, panels, sizers, buttons, etc, that only last for about 4 lines of code, I may call them frm, pnl, szr, btn respectively.   When the mood strikes me, I'll use pseudo-Hungarian notation like Visual Basic programmers are known to use, e.g. szrOuter,  btnUp, btnCloseFile, etc...

"szr", "pnl", etc. - excellent idea.  It's still clear what sort of object is referenced, but there's no danger of confusing it with a generic attribute (as can happen with "sizer").

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
C M
Reply | Threaded
Open this post in threaded view
|

Re: wx.Sizer Issue [UPDATE]

C M
In reply to this post by Rufus V. Smith



On Tue, Jul 8, 2014 at 5:29 PM, Rufus <[hidden email]> wrote:


On Monday, July 7, 2014 7:59:10 PM UTC-4, Che M wrote:

On Mon, Jul 7, 2014 at 7:53 PM, Marc Tompkins <[hidden email]> wrote:
More to the point, though, this question seems to me like an excellent demonstration of why generic-sounding variable names are a terrible idea.  I realize that you're working from someone else's code, but if he could hear I would tell him too: DON'T name your sizers "sizer".  Call them MySizer, or Edger, or OuterBound, or... well, just  about _anything_ that doesn't make them sound like a built-in, generic property.  This sort of confusion - where a user-created attribute gets confused with a generic property - happens all too often.  The interpreter doesn't care at all what you name your variables - so make them easy to identify, understand, and remember.

That's an excellent point, Marc!  Naming a sizer "sizer" is just asking for trouble, particularly as a beginner, for exactly the reasons you give. 

I am unashamedly a user of long inelegant object names, even to the point of backgroundSizerForMainFrame or textCtrlForTheUsersCookieRecipe.  You are just not going to have an instant's confusion when debugging as to what those objects are. (The less confused instants I have, the better.  There are still many, though :\ ).

 
I am a fan of long variable names normally, but often with frames, panels, sizers, buttons, etc, that only last for about 4 lines of code, I may call them frm, pnl, szr, btn respectively.   When the mood strikes me, I'll use pseudo-Hungarian notation like Visual Basic programmers are known to use, e.g. szrOuter,  btnUp, btnCloseFile, etc...

This is a great example of the point I was making before... if the object is only really manipulated *within that function*, then calling it pnl might be fine (although I would still call it "panel"; abbreviations make me twitchy), but if you have to access it from other functions or anywhere elsewhere within the class, then the need to have clearer names is more. At least IMHO.


--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.