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:[email protected]] Envoyé : mardi 15 octobre 2013 20:53 À : [email protected] 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 <[email protected]> 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:[email protected]] Envoyé : mardi 15 > octobre 2013 20:14 À : [email protected] 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 <[email protected]> wrote: >> >> >> On 10/15/13 9:52 AM, "Maurice Amsellem" <[email protected]> >> 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
