Hi Alex, I implemented the fix with flag and invalidateList.
Two remarks on the fix: >Maybe I'm not understanding. My recommendation is to change >dataprovder_collectionChangeHandler to set a flag and have updateDisplayList >check that flag > and call updateCaretForDataProviderChange. DONE for RESET events only, not REFRESH or others, to minimize the impact of other behavior. Maybe REFRESH would deserve the same fix as it's also calling validateNow() indirectly >Then it should be ok for updateCaretForDataProviderChange to work in immediate >mode and any validateNow calls should be less costly. Actually, the validateNow() was not needed anymore, because when we reach the method in updateDisplayList(), verticalPosition related vars are already validated Agree? Maurice -----Message d'origine----- De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] Envoyé : vendredi 11 octobre 2013 18:55 À : dev@flex.apache.org Objet : RE: Need help on https://issues.apache.org/jira/browse/FLEX-33813 (DataGrid goes blank) Understood. I will do that. -----Message d'origine----- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : vendredi 11 octobre 2013 18:45 À : dev@flex.apache.org Objet : Re: Need help on https://issues.apache.org/jira/browse/FLEX-33813 (DataGrid goes blank) On 10/11/13 8:00 AM, "Maurice Amsellem" <maurice.amsel...@systar.com> wrote: >Hi Alex, thanks for the help. > >I agree that validateNow() is a bad things and breaks the deferred >validation. > >However everything else in updateCaretForDataProviderChange is done in >"immediate" way And validateNow() is also called at other places in the >same method: > >- line 5418 : validateNow () when managing REFRESH >- line 5409 & 5442 : call ensureCellIsVisible(caretRowIndex, -1) >that calls in turn validateNow(); > >So if I change that to >newCaretRowIndexChanged=true; >invalidateProperties(); > >I will have to do it for the whole method, and call the actual >updateCaretForDataProviderChange in commitProperties. > >But then ensureCellIsVisible(caretRowIndex, -1) does not need to call >validateNow() anymore , or we lose all the benefits of deferring. > >But it's a public method. > >Two options: > >1) duplicate ensureCellsVisible as ensureCellsVisibleDeffered , that >does not call validateNow() >2) [Preferred] add an optional parameter >ensureCellIsVisible(rowIndex:int = -1, columnIndex:int = -1, >validateNow: Boolean = true):void > >In the second option, I change the API, but don't break the existing >calls. > >What do you think? Maybe I'm not understanding. My recommendation is to change dataprovder_collectionChangeHandler to set a flag and have updateDisplayList check that flag and call updateCaretForDataProviderChange. I would use updateDisplayList instead of commitProperties because updateCaretForDataProviderChange is updating the display list and not just some set of properties. Then it should be ok for updateCaretForDataProviderChange to work in immediate mode and any validateNow calls should be less costly. Sure it would be nice if updateCaretForDataProviderChange did not use validateNow() but sometimes methods that update the display list have to in order to avoid flicker, and the results shouldn't be any worse than it is now. -Alex
