Debug into the dataProvider setter. It looks like resetDP assigns the same instance so if there is a change check in the setter then it won't call the invalidation methods. Also check the invalidation flags to see if they are being set or not. I would expect all of those addItem calls to invalidate something.
And is that RunCode the 3rd step or could this be from a different RunCode? On 10/14/13 5:10 PM, "Maurice Amsellem" <maurice.amsel...@systar.com> wrote: >I changed to following: ><RunCode code="FlexGlobals.topLevelApplication.dataGrid.resetDP()" >waitEvent="updateComplete" waitTarget="dataGrid" /> > >Instead of : > <RunCode code="FlexGlobals.topLevelApplication.dataGrid.resetDP()" >waitEvent="enterFrame" waitTarget="stage"/> > >DataGrid_comp3.resetDP() is actually re-assigning the dataProvider, so >this SHOULD eventually trigger an updateComplete event. > >Unfortunately, the test fails with : > >Failed RunCode(body:step 3) Timeout waiting for updateComplete from >dataGrid > >Any idea ? > >Maurice > >-----Message d'origine----- >De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] >Envoyé : mardi 15 octobre 2013 02:00 >À : dev@flex.apache.org >Objet : RE: Build failed in Jenkins: flex-sdk_mustella #470 > >>Worth trying. But can you set a breakpoint on updateDisplayList to make >>sure it doesn't get called twice? We want to make sure the deferred >>work doesn't force another round >of validation. > >I remember I did that already when manually testing the fix: I did >several changes to the dataProvider, but only one UDL was executed. > >Maurice > >-----Message d'origine----- >De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 15 octobre 2013 >01:55 À : dev@flex.apache.org Objet : Re: Build failed in Jenkins: >flex-sdk_mustella #470 > >Worth trying. But can you set a breakpoint on updateDisplayList to make >sure it doesn't get called twice? We want to make sure the deferred work >doesn't force another round of validation. > >-Alex > >On 10/14/13 4:50 PM, "Maurice Amsellem" <maurice.amsel...@systar.com> >wrote: > >>>Sounds like a timing issue with the tests. eg They need to wait for >>>undateComplete event? >> >>In the test case below (which was one of the failing), after the DP has >>been reset, it's waiting for the next frame: >> >><RunCode code="FlexGlobals.topLevelApplication.dataGrid.resetDP()" >>waitEvent="enterFrame" waitTarget="stage"/> >> >>And after that, it's waiting for two more frames before comparing the >>bitmaps... >><WaitForEvent target="stage" eventName="enterFrame" >>numExpectedEvents="2"/> >> >>So maybe I should change to waitEvent="updateComplete" so that it wait >>until the udateDisplayList ? >> >> >> >> >> <TestCase testID="requireSelection_test15" >>keywords="[GridSelection,property,requireSelection ]" >> description="Test selection is on first row/cell,reset >>dataprovider,verify first row/cell is still selected"> >> <setup> >> <ResetComponent target="dataGrid" >>className="components.DataGrid_comp3" waitEvent="updateComplete" /> >> <WaitForEvent target="stage" eventName="enterFrame" >>numExpectedEvents="2"/></setup> >> <body> >> <RunCode >>code="FlexGlobals.topLevelApplication.dataGrid.selectionMode=GridSelect >>ion >>Mode.MULTIPLE_CELLS"/> >> <AssertMethodValue >>method="value=FlexGlobals.topLevelApplication.dataGrid.selectionContain >>sCe >>ll(0,0)" value="true"/> >> <RunCode >> code="FlexGlobals.topLevelApplication.dataGrid.resetDP()" >>waitEvent="enterFrame" waitTarget="stage"/> >> <AssertMethodValue >>method="value=FlexGlobals.topLevelApplication.dataGrid.selectionContain >>sCe >>ll(0,0)" value="true"/> >> <WaitForEvent target="stage" eventName="enterFrame" >>numExpectedEvents="2"/> >> <CompareBitmap numColorVariances="20" >> maxColorVariance="20" >>url="../Properties/Baselines/$testID_cell.png" target="dataGrid"/> >> </body> >> </TestCase> >> >> >>Maurice >> >>-----Message d'origine----- >>De : Justin Mclean [mailto:jus...@classsoftware.com] Envoyé : mardi 15 >>octobre 2013 01:34 À : dev@flex.apache.org Objet : Re: Build failed in >>Jenkins: flex-sdk_mustella #470 >> >>HI, >> >>Sounds like a timing issue with the tests. eg They need to wait for >>undateComplete event? >> >>Justin >
