It depends on how the selection is set. If you call setSelectedRanges(), a single event is fired for the entire change. If you call addSelectedRange() or removeSelectedRange(), an event is fired for each change.
On Jun 24, 2010, at 10:18 PM, aappddeevv wrote: > I'm not sure of the current implementation, but if by doing a selection > indirectly, you fire an event for each selection, as it is selected in the > set being set, then that could be inefficient or at least push the burden of > inefficiency into the client. If it fires after all of them have been > selected, then it should be okay. I think some platforms, can't recall > immediately, allow you to receive each individual selection, if you want it, > then a post selection event that has all of them. It probably uses a timer > underneath to determine which selections get grouped together. > > > -----Original Message----- > From: Sandro Martini [mailto:[email protected]] > Sent: Thursday, June 24, 2010 5:53 PM > To: [email protected] > Subject: Re: [RFC] Selection change events > > Hi Greg, > for me the change is right, and maybe with this application selection > listeners could see what to do (and when it's the case ignoring the > "indirect change" event, like today) ... and on all selectable > components, right ? > Have you an idea on the performance impact of this change on > tables/trees and other containers with many elements inside ? > > Bye, > Sandro >
