[Chandler-dev] Re: Fwd: Build failed on molokini-osx

[D John Anderson]

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