Community
Participate
Working Groups
At the moment there's no API to listen for Cell-based selections on Table/Tree-Viewers.
Created attachment 46627 [details] Adds new Listener API to Listen for CellSelections
Tom, thanks for the patch. One minor comment: CellSelectionEvent should probably have an element field instead of the item field. More generally, I am not sure what this is for (if it only uses the mouse as a selection source). What is your use case for adding this?
(In reply to comment #2) > Tom, thanks for the patch. One minor comment: CellSelectionEvent should > probably have an element field instead of the item field. > > More generally, I am not sure what this is for (if it only uses the mouse as a > selection source). What is your use case for adding this? > Yes please see a much better version in in my implementation from Bug 149193. I think the overall idea becomes clear when you look at my example code from bug 149193. But I think you are often interested which specific cell a user currently entered and as shown in 149193 this could be used to activate CellEditors in a more elegant way than it is now providing informations about the cell-activation (key-strokes,double-click,key-board-selection)
Any comments on this. I'm answering question like "do I know which cell is click once a week" and because we already extract this information for editing I think we could also make it available to the users.
Created attachment 54784 [details] A first patch to bring back this feature This patch adds the API and modifies AbstractViewerEditor to deal directly with ViewerCell instead of recollecting the information already known because of the CellSelection. The current implementation only provides cell selections based upon Mouse-Actions but extending the whole system to allow keyboard navigation and selection should be possible. The given patch provides a first step. Boris think this could be our next topic to work on because I modified API methods from AbstractViewerEditor I think we should put this in directly after TableViewer-Independency is done (before TreeViewer-Independency)
Created attachment 54904 [details] And make it reapplyable to HEAD
Boris wanted me to explain the great picture for this new feature so here it is. For me cell-selection events are fired under the following circumstances: - click on cell - double click on cell - keystrokes defined using something like ColumnViewer#setCellSelectionStrokes(KeyStroke[]) (maybe we should support standard strokes like SPACE, RETURN using constants) Based upon this information I think EditingSupport will get a new API function like EditingSupport#isEditorActivationEvent(CellSelectionEvent) which will decide if an editor for the currently selected cell is started. CellSelection based on Mouse-Events is nearly ready if this patch goes in CVS but I haven't implemented it in this patch because this bug only talks about the ground work providing all those new functionalities. The reall work on editor activation customization needs to be done in bug #151295. Let's now go to keyboard-activation. To make this happen the first thing we need to support is keyboard navigation inside table/tree's. To accomplish this we need to track the currently selected cell ourselfs by hooking into the keyboard events(Boris could you once more provide the link you sent me while chating I've somehow lost it). We need to provide a methods in CellLabelProvider which deals with layouting the currently selected cell and maybe turn of the system selection using ownerdraw like shown in one of the SWT-Snippets. The rest is easy if the SelectionEvent is fired because one of the defined key-strokes is detected EditingSupport#isEditorActivationEvent(CellSelectionEvent) is checked and the editor in the cell is activated. To support keyboard activation I have no test-code until now but I only wanted to present the great picture to all of you. I'd love to get some comments from all of you interested in this for my understanding really very important feature for Datacentric-Editing-Applications based upon JFace-Viewers.
Created attachment 55407 [details] patch that applies to HEAD
Created attachment 55408 [details] One more change to start customization of editor activation
Created attachment 55412 [details] And finally the fully customizable editor activation for Mouse selections This patch allows a fully customized editor activation based upon mouse clicks. Simply implement the EditorActivationStrategy and check the informations provide by the cell-selection event to you. Using EditorActivationStrategy we don't need to extend EditorSupport. If you for example want to activate editors on double-click this code fragment solves this it for you: -------------8<------------- columViewer.setEditorActivationStrategy(new EditorActivationStrategy() { protected boolean isEditorActivationEvent(CellSelectionEvent event) { return event.swtEvent.type == SWT.MouseDoubleClick; } }); -------------8<-------------
Although technically not 100% correct I added this bug as blocker for bug #167509 because when we decide to integrate this patch AbstractViewerEditor works with ViewerCell and it would be much more natural pass this information along to the editing support.
Eric, if you have some time could we look at this together?
Please refer to bug #151295 for a fully working implementation
Boris, just drop by if you want to discuss this...
(In reply to comment #14) > Boris, just drop by if you want to discuss this... > Eric and Boris could please when looking at the patches (please use the one from bug #151295) also clarify why we need a seperate focus listener in AbstractViewerEditor I think CellEditor handles focus lost events perfectly itself.
Out of cycles...moving to M6.
Completely swamped. Boris if we need to take action in 3.3 for this come and see me.
Eric I don't think we need any action we have rethought all this and solution we have proposed for 3.3 is found in bug #172646. This doesn't mean that this api won't make sense in future but it doesn't block other bugs. I removed the dependencies
Eric, do you mind if I take care of this bug and I like take it over for 3.4
Tom, not in the least...;-), thanks.
removing 3.5
multi change because of intenion of stepping back as platform-ui committer
Tom/Boris, Any update on this problem ? Could you guys suggest any work around for this problem so that I can programmatic-ally set the selection on a table viewer column (cell) that is part of the table viewer. I started by looking at the snippet Snippet059CellNavigationIn33 http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.jface. snippets/Eclipse%20JFace%20Snippets/org/eclipse/jface/snippe ts/viewers/Snippet059CellNavigationIn33.java?view=markup Even by running the above snippet, I see that the selection is not set or focus on the table column. When the table widget comes up I do have to hit the down arrow for the selection to be visible on the row 2 - column 1 or I have to hit Enter when the table widget comes up first and then the item in row 1 - column 1 is put into edit mode. But I would like to make the selection visible (lets say I would like to either show selection on row 1 - column 1 or make the cell row 2 - column 2 in edit mode) right away when the table widget is brought up. How can I do that ? If possible, could you please provide me with some small snippet code to do this ? Thank you very much.
(In reply to comment #23) > Could you guys suggest any work around for this problem so that I can > programmatic-ally set the selection on a table viewer column (cell) that is > part of the table viewer. Does the snippet that I attached to bug 198260 help?
(In reply to comment #24) > (In reply to comment #23) > > Could you guys suggest any work around for this problem so that I can > > programmatic-ally set the selection on a table viewer column (cell) that is > > part of the table viewer. > > Does the snippet that I attached to bug 198260 help? Yes it does. Thank you.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
