Makes sense to me. -Alex
On 10/13/13 5:24 PM, "Maurice Amsellem" <maurice.amsel...@systar.com> wrote: >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 >
