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 ? > 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. Michaël > > ..ede > ------------------------------------------------------------------------------ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
