You tried to get too many features working all at once. That is
deadly unless you already know exactly what you are doing. I
commented out those features that had nothing to do with the layout.
You really need to read the documentation for each wx control.
Several controls were missing critical arguments. Google is your
friend - use it. E.g.:
wxpython textctrl
Giving a control's ID of -1 tells wx to give the control a unique
ID, but that you never want to reference that control by that ID.
This is very handy and often used.
See the attached file.
It's best/easiest that each frame (a subclass of wx.Window) panel
have both a vertical and a horizontal sizer. Which one goes into the
other depends on how you want to arrange the controls on the page. I
added a couple of wx.StaticText for demonstration purposes to show
one (arbitrary) way.
Unfortunately, sizer [ flag ] options are specified all in one
argument despite the fact that they affect totlayy different aspects
of how their control is laid out. In the statement:
vertSizer.Add( panel_statText, 0, wx.LEFT | wx.RIGHT |
wx.CENTER, padding )
The parameters [ wx.LEFT ] and [ wx.RIGHT ] are associated with the
padding (border space) value argument. However, [ wx.CENTER ]
affects how that control is placed on the page within its sizer.
Placement uses the padding flags’ value. Otherwise, control padding
and control placement have nothing else to do with each other. It is
very unfortunate that wx requires all the flags to be lumped
together. The flags [ wx.CENTER ], [ wx.CENTRE ] and [
wx.ALIGN_CENTRE ] are all synonymous. This is also very unfortunate
and needlessly confusing, too. It’s no wonder at all that wx
beginners get so confused !
Even a short example like this one really need more descriptive
names. Modifying someone else’s example is a great way (the very
best way ?) to learn, but often the variable names are too
ignorantly generic to be easily understood for exactly what
purpose that object is going to be used. As you read an example
program and figure out what a particular widget is for, globally
change the name in the program to something that is more descriptive
for you. Chances are very good that to whatever you rename
something, it will be easier for anyone/everyone else reading you
program to understand it, too. Poor naming conventions is a
widespread and totally preventable disease in all types of
programming.
Until you learn for what wx.ID_ANY is supposed to be used,
substitute either [ -1 ] or [wx.NewId() in every widget’s
definition. E.g.:
Bug_Working.py (3.54 KB)
SENDING_STDOUT_TO_A _WX-TEXTCTRL.PY (2.89 KB)
···
class ManFrame( ... ) :
....
self.delayAfterLastResizeTimerID = wx.NewId() #
timer handler needs to sort out IDs
self.delayAfterLastResizeTimer = wx.Timer( self,
id=self.delayAfterLastResizeTimerID )
self.Bind( wx.EVT_TIMER, self.OnTimers )
self.frameResizeTimerID = wx.NewId() #
timer handler needs to sort out IDs
self.frameResizeTimer = wx.Timer( self,
id=self.frameResizeTimerID )
self.Bind( wx.EVT_TIMER, self.OnTimers ) # single binding
for all timers
....
#end MainFrame class
def OnTimers( self, event ):
"""Sort out the 2 timers' completely independent events. """
if ( event.GetId() == self.frameResizeTimerID ) :
{ do this }
elif ( event.GetId() == self.delayAfterLastResizeTimerID
) :
{ do that }
#end if
#end OnTimers def
--------------------------------------------
If you have only 1 timer, then there is no reason to define and test
for its ID value.
Also attached is one nice way to redirect output from [ stdout ] to
a multi-line wx.TextCtrl.
Keep reading more examples. Like everything else, in time all will
become apparent. Even wx.
Ray Pasco