Hi Robin,
Kevin Ollivier wrote:
OK, folks, here are my notes after doing a quick test of wxPythonOSX 2.5.1.4:
- XML Resource Subclass is failing, with the following traceback:
Traceback (most recent call last):
File "/Volumes/wxPythonOSX-2.5.1.4-panther-Py2.3/Samples/demo/ XmlResourceSubclass.py", line 50, in OnSize
w, h = self.t.GetTextExtent(self.t.GetLabel())
AttributeError: 'MyCustomPanel' object has no attribute 't'
Interesting... the first EVT_SIZE is happening before EVT_WINDOW_CREATE.
I remember there some sizing code in MacPostCreateControl, I think it was done so that controls adjust their size to whatever is needed by the native control, and then report that size. However, I don't see why wxPanel would be doing it...
- wxGrid first example is crashing the demo, no traceback unfortunately
Does it crash when the window opens? (It doesn't here) otherwise, what do you do to make it crash?
Hmm... Good thing you pointed this out. I just did a bit more testing and this crash has nothing to do with wxGrid at all! It crashes on wxGrid just because that's the first time after the *real* problem occurs that the demo window loses focus; the actual crash occurs when the window restores focus. Give the following a try to see if I'm not going crazy:
- Click on wxCheckListBox and select a couple items
- Click on wxChoice (or any other demo)
- Select another window in the Dock to cause wxPyDemo to lose focus
- Select wxPyDemo again
If I am not going crazy, you should get a crash. I am seeing this reproducably, I've actually tried it 3-4 different times and get the exact same results. Why that should happen is beyond me...
What is REALLY odd is that it seems the that only by clicking on both wxCheckListBox and wxChoice (in that order) causes the crash. (Though it could be wxCheckListBox and any other demo.) This problem is gone in CVS HEAD (although wxCheckListBox isn't quite working right, though it could , and it will only be triggered by a certain sequence of events, so it may not be worth it for the moment.
- wxMimeTypesManager is failing with an assert:
Traceback (most recent call last):
File "/Volumes/wxPythonOSX-2.5.1.4-panther-Py2.3/Samples/demo/Main.py", line 677, in OnSelChanged
self.RunDemo(itemText)
File "/Volumes/wxPythonOSX-2.5.1.4-panther-Py2.3/Samples/demo/Main.py", line 714, in RunDemo
self.window = module.runTest(self, self.nb, self) ###
File "/Volumes/wxPythonOSX-2.5.1.4-panther-Py2.3/Samples/demo/ MimeTypesManager.py", line 309, in runTest
win = MimeTypesDemoPanel(nb, log)
File "/Volumes/wxPythonOSX-2.5.1.4-panther-Py2.3/Samples/demo/ MimeTypesManager.py", line 198, in __init__
mtypes = wx.TheMimeTypesManager.EnumAllFileTypes()
File "//Library/Python/2.3/wx/misc.py", line 2283, in EnumAllFileTypes
return _misc.MimeTypesManager_EnumAllFileTypes(*args, **kwargs)
wx.core.PyAssertionError: C++ assertion "wxAssertFailure" failed in ../src/mac/mimetmac.cpp(210): wxMimeTypesManagerImpl::EnumAllFileTypes() not yet implemented
Okay.
- Strange problem in the sizer demo with wxButtons drawing multiple times (Kevin Altis has shown this in a sample), but I'm not sure if it's really worth fixing at this point.
Yeah, I've been intending to change it to use something besides a wx.Button because it can look weird with some gtk themes too. Guess it's time to do that.
Thanks!
- Threading gives me an assertion when I try to close the window:
Unhandled exception in thread started by
Traceback (most recent call last):
File "/Volumes/wxPythonOSX-2.5.1.4-panther-Py2.3/Samples/demo/Threads.py", line 35, in Run
evt = UpdateBarEvent(barNum = self.barNum, value = int(self.val))
File "//Library/Python/2.3/wx/lib/newevent.py", line 17, in __init__
wx.PyEvent.__init__(self)
File "//Library/Python/2.3/wx/core.py", line 4387, in __init__
newobj = _core.new_PyEvent(*args, **kwargs)
wx.core.PyAssertionError: C++ assertion "wxAssertFailure" failed in ../src/common/dynarray.cpp(424): bad index in wxArray::RemoveAt
I've seen that but I thought I had fixed it. In fact I can't duplicate it here any more. Are you sure you are not using an old version of the binaries? (Have DYLD_LIBRARY_PATH set perhaps?)
Hmmm... I'm not seeing this anymore. I know there wasn't any DYLD_LIBRARY_PATH issues when the problem occurred - I double-clicked on it from the finder and I don't have DYLD_LIB_PATH permanently set in my environment. But in light of what happened above, I may not be crazy in saying that it was something about the order of events that caused it to happen. 
In any case, this one I can't reproduce so no point in worrying about this one further.
BTW, thanks for the notes on updating to the latest CVS. I only had about half of those items on the list I had made from reading the cvs checkin messages and such.
Sure, after a couple more days of Stefan hammering on it, you might want to really give it a look. I am really starting to think it may be worth at least an interim release, within a week or two at least. I don't think we should wait until 2.5.2 to get some wider testing of this codebase. By 2.5.2 we'll already have some new things to start testing. ^_-
And I finally realized why we all felt that wxButtons were so big when Stefan changed their size - all the controls in the 2.5.1.4 demo (and previous releases) are small size! Once they go to the bigger default size, everything looks more normal. It seems a bit big at first, but after a few seconds you realize that most other Mac apps use this size so it actually looks more natural now. =)
Thanks,
Kevin
···
On Mar 31, 2004, at 7:55 PM, Robin Dunn wrote: