I attach a zip file containing the code that with these
problems: (a) unhandled exception (b) incorrect size aui.notebook with VERTICAL sizer.
Run the cAps.py file. This is the ‘controller’ that runs
other necessary files. A window with a
notebook containing 2 pages will appear.
First page of the notebook is titled ‘Group 1’ and second page, ‘Group
2’.
---------- Error (a) Unhandled Exception:
This is an intermittent but fairly frequent error. To see the error, try this:
Click on ‘Group 2’
page of the notebook. Click on
appointment labeled ‘Giant Step’ in column ‘2 Decibel’, in the row (from 9:00 to 10:00). The appointment will be highlighted with
yellow border. Click on ‘Shift’ button at the top of the window (just above the
Group 2 page title). Then click on any
empty timeslot e.g. column ‘2 Decibel’, for time from 8:00 to 9:00. The empty destination timeslot will be
highlighted with red border. Click on the destination timeslot again to confirm shift. The appointment time will then be changed
from [9 to 10] to [8 to 9]. The change is successful and the screen will update
correctly.
Most of the time, after this shift is completed successfully, this error will be shown:
‘Unhandled Exception’.
If you click on ‘Ignore’, the program will usually continue normally, apparently
none the worse.
Sometimes, but rarely, when this shift is done, the entire
wx program just shuts down without any message at all. At other times, the shift will be executed
successfully without any errors, but for the shift of this particular appointment,
it will fail 4 in 5 times.
If there is no error, simply try shifting this appointment
again, or shifting other appointments. It is almost guaranteed to fail within 5
attempts. But the failure rate is also intermittent – I have experienced times
when it doesn’t fail at all; sometimes after a seemingly unrelated and minor
change to the code. Shift for Group 2 appointments seems to be more likely to
fail then Group 1’s. Group 1 and Group
2 windows are created from the same Class: CalendarPanel.
I have tried changing the code so that the shift requires
only 1 step (i.e. the second confirmation click is not required) and this
seems to prevent the ‘unhandled exception’. However, it it not clear
why. I have gone through the difference
in the code, and there doesn’t seem to be any difference that could account
for the crash when the shift is
executed in the second click compared to when done in the first.
Currently, the code only allows for shifts of appointments
that are of 1 hour duration, i.e. same as the empty slots.
---------- Error (b) incorrect size of panel in
aui.notebook.
The code as it is, shows aui notebook as correctly sized
i.e. fills expands to fill most of its containing panel (self.op) based on the
add to a VERTICAL sizer with proportion 1 and wx.EXPAND flag. However, this is
only when the panels of the appointment windows are incorrectly created with
the outer panel as the parent instead of the AuiNotebook. The ‘outer panel’, self.op, contains the auiNotebook. If
the appointment windows are created with the AuiNotebook as the parent, the
AuiNotebook becomes tiny – occupying only 100*80 pixels. A similar size problem is seen when
wx.Notebook is used – one difference is that, in the first place, wx.Notebook
does not allow the 2 pages to be added if their parents are not wx.Notebook.
The relevant lines of codes are in vAps.py:
Line 263:
self.nb =
wx.aui.AuiNotebook(self.op)
Lines 429 to 435:
self.calG1Panel =
CalendarPanel(self.op)
self.calG1Panel.name = ‘G1’
self.nb.AddPage(self.calG1Panel,
“Group 1”)
self.calG2Panel =
CalendarPanel(self.op)
self.calG2Panel.name = ‘G2’
self.nb.AddPage(self.calG2Panel, “Group 2”)
(*** Changing the parents for the 2 CalendarPanels to self.nb
in Lines 429 and 433 will cause the size of the notebook will become tiny)
Lines 441 to 445:
sizer = wx.BoxSizer(wx.VERTICAL)
self.sizer=sizer
sizer.Add(spSizer, 0, wx.EXPAND)
sizer.Add(wx.StaticLine(self.op), 0, wx.EXPAND | wx.LEFT |
wx.TOP | wx.BOTTOM, 8)
sizer.Add(self.nb, 1, wx.EXPAND)
------ Apologies for large number of files and amount of
code —
I tried to start of by creating a single minimalist file
that can demonstrate the error, but had a hard time, and after spending hours,
gave up. I then decided to work backward by starting with the code I had and
cutting it down. I didn’t cut down the
number of files by much, but I have deleted most of the code that has no
bearing on the error e.g. functions for adding and deleting appointments; and
cleaned it up as best as I could.
There is still a lot of code, but having spent another few hours on this
second effort, I hope it is sufficient to provide some ideas on the cause of
the problems. If you look at the code, and also, consider the intermittent nature of the problem,
you will probably know why both efforts was so time consuming and
difficult. Not my finest moment.
One major suspect is the way I created the ‘scrolling’
appointment schedule with ‘frozen’ row and column titles. This was by manually controlling the
scrollbars and shuffling appointment windows in a GridBagSizer. Not the most elegant way and required a ton
of coding - and may be the cause of both problems; but currently is the only
way I have to solve the problem. I
suspect I have to abandon this awkward design or have to radically relook at
the entire approach to meeting this requirement.
Well, any feedback and suggestions is welcome.
Thanks.
Sam
cAps.zip (12.9 KB)
···
2009/7/29 Sam23 qm0023@gmail.com
This error is sometimes shown when I try to redraw a screen with many
sizers after changing many of the controls (mostly wx.panels):
Unhandled exception
An unhandled exception occurred. Press ‘Abort’ to terminate the
program, ‘Retry’ to Exit the program normally and ‘Ignore’ to try to
continue.
No python line numbers or error details are shown. If I click Ignore,
the program continues, apparently none the worse. The screen is drawn
with correct results. If I click Abort, everything ends. I have
encased the offending method in try/except block, but it doesn’t catch
anything. The error seems to be outside python. My python print
statements appear right to the last line of expected execution.
The error is intermittent… maybe occurs once out of 4 tries… No
apparent reason… The same exact same sequence, starting the program
from fresh, can be fine or can crash.
How do I get started with troubleshooting this?