Hi Robin:
It looks like the tests are still failing on Tiger -- but in different
ways. Some of them look like a selection in a TextCtrl is getting lost
or set incorrectly. Do you think wx is still responsible for these
failures?
John
On Dec 7, 2007, at 10:17 AM, Robin Dunn wrote:
[ redirecting to chandler-dev]
Robin Dunn wrote:
D John Anderson wrote:
It looks like RenameAndNewEvent is finding a new bug on the non-
leopard tinderboxes:
AssertionError: event 110 -- widget CalendarLocationAEEditControl
value, "locationt" doesn´t match the value when the script was
recorded: "t"
Here's what's happening: The calendar location field is shown in
the detail view just below the title in a calendar event. When you
begin editing it, it's normally selected and displays the text
"location". So typically when you type a character, e.g. "t", it
should replace the text "location" with "t". In this case it
doesn't, after the character is typed it displays "locationt"
instead of "t".
I suspect that the recent wx is the most likely thing that might
cause this bug. I don't have a non-leopard MacOS to test on so I'm
not going to be able to easily track down the problem.
Here is a workaround. I still haven't narrowed down the wx change
that might have an effect like this.
[...old patch cut...]
That fix actually caused a different test to fail, so I've now got a
better workaround/fix that I'll check-in after I am able to run the
tests on Leopard.
Basically the wx change that caused this problem was that the old
way that focus events were handled in wx could cause a crash on
Leopard in certain situations, so Stefan changed it to use a new
notification added to Leopard, and it ended up being better anyway
since it works more like focus events on wxMac and wxGTK do. Since
pre-Leopard systems don't have this new notification Stefan added
code to emulate it for those systems. He says that there are likely
minor differences in sequence of events between Leopard and pre-
Leopard, and I think that this test case is probably falling into
that crack. So using a CallAfter works around that difference by
delaying the setting of the selection until everything else is done.
There is another bit of functionality here that can sometimes get in
the way, and may also be part of this particular problem. The
native widget used for the wx.TextCtrl on Mac does not maintain its
selection when it doesn't have the focus, so wxMac does it itself,
and restores the old selection (if any) when the widget gets the
focus. Since the Chandler code is optionally doing a SelectAll in
the click or focus events it may be that wxMac comes back around
after that point and resets the selection to the previous values
(nothing selected.)
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
