Hi, with r4500, I stop event propagation a bit earlier. We now should have the previous behaviour while selecting in AttributeTable.
Michaël Le 17/06/2015 10:33, [email protected] a écrit : > On 17.06.2015 06:38, Michaël Michaud wrote: >> Hi Ede, >> >>>> btw. i noticed that our AttributWindow only supports it for selection, but >>>> not for unselection. >> Seems that when the LayerView is active, Ctrl D can be used to unselect, >> while Shift A is the way to unselect the Attributetable. >> I admit this is not very consistent. LayerView seems too complex to >> change. Maybe JTable default behaviour can be changed. Any hint ? > let's keep shortcuts aside for now. what Jukka and me talked about is the > mouse click select behaviour. > > try a version before your commit and after. before you could select ranges via > 1. Click one (one selected) > 2. holding Shift+Click another one (now the range from 1. to this row are > selected) > 3. thereafter Ctrl+Click another unselected one (now the prev. range and this > one are selected) > 4. Ctrl+Shift+Click another unselected one (now the prev. range plus a new > range are selected) > > ranges work analogue for unselection when your starting cell is unselected > but your end cell or cells in the range are. > points 3. and 4. for unselection do not work anymore after your synch commit, > but did before > >>> ok, dug in a bit further and versions before the synchronization supported >>> Ctrl+Shift+Click deselection. >>> >>> as far as i can see this is prevented now because table row selection does >>> not actually only select rows anymore but >>> - selects in table >>> - fires an event to the layerview selectionchange event >>> - which in turn updates the table agn. because its registered as a >>> layerviewchange listener >>> - which involves a selection clearing and reselecting the table entries agn. >>> >>> Mike: afaics selection events coming from the table should only update the >>> layerview but skip reupdating the table selection >> Sorry, I did not understand how the new event propagation is related to >> Ctrl+Shift+Click deselection. >> Here is how the new LayerView listener is supposed to prevent selection >> events to enter an infinite loop, >> starting from your example : >> - selects in table >> - fires an event to the layerview SelectionChange event (updates the >> layerView) >> - which in turn fires the new LayerView listener registered in >> AttributeTable >> - this LayerView Listener does not know where the events come from >> (layerView or attributePanel), so it will update back the AttributeTable >> - but to break the loop, this update will not fire the SelectionChange >> again. >> >> I you know a better way to handle such synchronization, let me know, I >> found only a few examples. >> > i would have to fiddle as well, but the whole loop does not feel correct. > ideally both (layerview, attrib.table) would register themselves to the other > as listeners, but not throw any more events when they receive the change > event. > > maybe ill find some time to look at it more closely. > > ..ede > > ------------------------------------------------------------------------------ > _______________________________________________ > Jump-pilot-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ------------------------------------------------------------------------------ _______________________________________________ Jump-pilot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
