And in case you missed it, yesterday I found an problem with the commit
for "FLEX-34078 fix callouts closing". I'm assuming we want to get all of
these cleaned up before we do 4.12.2? I probably have a few days of
install script work ahead of me to try to checksum downloads and handle
caching in ant.
-Alex
On 5/27/14 3:07 PM, "Alex Harui" <aha...@adobe.com> wrote:
>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Š
>
>-Alex
>
>On 5/27/14 1:26 PM, "Alex Harui" <aha...@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" <labri...@digitalprimates.net>
>>wrote:
>>
>>>>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.
>>>
>>>Mike
>>>
>>
>
