flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [Mustella] still failing, must fix
Date Tue, 27 May 2014 22:07:29 GMT
And finally:

- The Menu/MenuBar/Tree/DataGrid/MXItemRenderer failures are a result of
the XMLListCollection change.  I looked at MXItemRenderer and it appears
that the test is expecting an updateComplete when an XML node is added to
the collection.  Does this no longer happen because the parent is not
notified?  I haven't looked any deeper.

- The ComboBox failures are due to the change "FLEX-34222 fix selection
reverting to previous typed values when second value (not in list) is
entered". I have not looked into why.

I am now going to return to my regularly scheduled programmingÅ 


On 5/27/14 1:26 PM, "Alex Harui" <aharui@adobe.com> wrote:

>I just looked at another failure (DataGroup).  It also points at this set
>of changes.  It turns out that Sort.fields can be null if you don't have
>any SortFields and only a Sort.compareFunction.  It fails on line 395.
>You'll need a null check there.
>On 5/27/14 1:16 PM, "Michael A. Labriola" <labriola@digitalprimates.net>
>>>You should get an arg count mismatch.  By changing the (!hasFieldName)
>>>test on Sort.as line 413 I got the expected result ("Find criteria must
>>>contain all sort fields")
>>Thanks. I think there may have been a bad merge on my part too as it
>>seems the logic that was checked in is also missing another condition.
>>Will try to get this resolved today.
>>My concern on the change above is only that a custom sort function could
>>be on use a label function or something other than a single field, so we
>>need to ensure that we don't exclusively use the existence of the fields
>>as an indicator. The original bug was also that rows were being inserted
>>in the wrong place when using a custom sort function as it was using the
>>field to determine where, not the function.

View raw message