OK, sounds good to me. Thanks for sticking with it. -Alex
On 10/15/13 1:18 PM, "Maurice Amsellem" <maurice.amsel...@systar.com> wrote: >Alex, some good news : > >I found some time to run/debug the tests again and discovered that the >way we handled updateCaretForDataProviderChange was not good. >The way it's done now is the following: >- setting a flag and calling invalidateDisplayList() >- in updateDisplayList call caretRowIndex update in case the flag >changes. > >The problem with that code is that caretRowIndex setter will call in turn >invalidateProperties and invalidateList(), which IMO, should not happen >in UDL. > >So I tried my initial fix intention, which was to do that through >flag+invalidateProperties / commitProperties. > >And all the failing tests are successful now. > >Do you validate ? > >Maurice > >-----Message d'origine----- >De : Erik de Bruin [mailto:e...@ixsoftware.nl] >Envoyé : mardi 15 octobre 2013 20:53 >À : dev@flex.apache.org >Objet : Re: Build failed in Jenkins: flex-sdk_mustella #470 > >Ok, just thought I'd mention it ;-) > >EdB > > > >On Tue, Oct 15, 2013 at 8:50 PM, Maurice Amsellem ><maurice.amsel...@systar.com> wrote: >> Erik, >> >> The tests are passing because I have undone one the fixes that have >>broken them. >> >> (FLEX-33813 (DataGrid goes blank when scrolled and dataProvider is >> changed ) >> >> We are currently trying to make that fix again in a different way that >>does not break the tests again, possibly fixing also the tests. >> >> (At least, this is my understanding) >> >> Maurice >> >> -----Message d'origine----- >> De : Erik de Bruin [mailto:e...@ixsoftware.nl] Envoyé : mardi 15 >> octobre 2013 20:14 À : dev@flex.apache.org Objet : Re: Build failed in >> Jenkins: flex-sdk_mustella #470 >> >> Build 471 passed all tests... is this player version related, or are >>you chasing ghosts? >> >> EdB >> >> >> >> On Tue, Oct 15, 2013 at 7:09 PM, Alex Harui <aha...@adobe.com> wrote: >>> >>> >>> On 10/15/13 9:52 AM, "Maurice Amsellem" <maurice.amsel...@systar.com> >>> wrote: >>> >>>>>I will try to generate and check in png.xml files for the two >>>>>failing tests >>>> >>>>Not sure to understand what png.xml files are ? the baseline pngs ? >>> A png.xml file is an XML description of the display list. We use >>> them when different player versions or mac-vs-win give slightly >>> different bitmaps. There are only a few checked in right now. >>> CompareBitmap first compares the .png file and then if it fails it >>> looks for the png.xml and compares the display list. The theory is >>> that Flex code really only manipulates display list properties so if >>> a component is at x=4.5 we don't truly care what pixel colors the >>> player chooses for pixel 4 and 5, we just want our code to set that >>>component at x=4.5. >>> >>> Now if the test still fails you can compare the png.xml output and >>> see where the proposed code did change some display list property. >>> So far, that's found a few subtle bugs in our code. >>> >>> I'm still trying to get the repo back to where those tests pass so I >>> can generate the right png.xml files, so I'm not ready to check them >>> in just yet. >>> >>> -Alex >>> >> >> >> >> -- >> Ix Multimedia Software >> >> Jan Luykenstraat 27 >> 3521 VB Utrecht >> >> T. 06-51952295 >> I. www.ixsoftware.nl > > > >-- >Ix Multimedia Software > >Jan Luykenstraat 27 >3521 VB Utrecht > >T. 06-51952295 >I. www.ixsoftware.nl