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
