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 Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
