Bugzilla – Full Text Bug Listing
| Summary: | [CellEditors] Double click behavior for tableviewer | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Kenneth Rabe <Kenneth.J.Rabe> | ||||||||
| Component: | UI | Assignee: | Thomas Schindl <tom.schindl> | ||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||
| Severity: | enhancement | ||||||||||
| Priority: | P4 | CC: | arvera, bokowski, cgross, emoffatt, jan.stamer, Konstantin.Scheglov, mn, rohit_1004, Tod_Creasey, tom.schindl | ||||||||
| Version: | 3.1 | ||||||||||
| Target Milestone: | 3.3 M6 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | All | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Kenneth Rabe
This behaviour is provided by JFace. Moving to the UI component. hello, is there somebody going to do something with that? I think that the single click editors are quite weird behavior on every platform, and I would really like to see popping editor on double-click only in the whole eclipse as well... Created attachment 45532 [details]
Implementation of editor activation strategy
This is a first implementation of an editor activation strategy inside Table/TreeViewer. A minor problem is the handling of pressing RETURN which maybe needs to be polished.
Created attachment 45533 [details]
Example how it works
I would love to see this patch go in. At least on OS X, single-click-to-edit on a table is really strange. (In reply to comment #5) > I would love to see this patch go in. At least on OS X, single-click-to-edit > on a table is really strange. > If you need a working version based upon JFace-Code until this patch goes in you can get it from my SVN-Repository: - Repository: http://publicsvn.bestsolution.at/repos/ - Path: java/at.bestsolution.jface.custom/trunk Tom (In reply to comment #6) > (In reply to comment #5) > > I would love to see this patch go in. At least on OS X, single-click-to-edit > > on a table is really strange. > > > If you need a working version based upon JFace-Code until this patch goes in > you can get it from my SVN-Repository: > - Repository: http://publicsvn.bestsolution.at/repos/ > - Path: java/at.bestsolution.jface.custom/trunk > > Tom > Just to clear up things: Please note that this is nothing provided by Eclipse-Foundation. It's my personal/companies repository where I offer these things and I make no warranties to change the API in future e.g. by integrating other patches of mine. Hi All, can somebody please fix the bug? It is really bad especially if you enable table/ tree editing: On start of the drag the editor is opened. When the drag is finished you end up with an editor for a Tree item that does not exist any more!!! By the way the existing patch does NOT work for the TreeViewer. This needed another hack of mine. The problem is that now I have to deploy a custom hacked jface library which is not good software development. Thanks very much, Jan (In reply to comment #8) > Hi All, > > can somebody please fix the bug? It is really bad especially if you enable > table/ tree editing: > > On start of the drag the editor is opened. When the drag is finished you end up > with an editor for a Tree item that does not exist any more!!! > > By the way the existing patch does NOT work for the TreeViewer. This needed > another hack of mine. The problem is that now I have to deploy a custom hacked > jface library which is not good software development. > > Thanks very much, > Jan > Could you please provide information what's not working when running with TreeViewer and I'll incooperate it into my own version, I must admit that I have only tried it using TableViewer. Did you take a look into my SVN-Repository you don't need to ship your own JFace-Component because you could work around it like shown there. Hi,
I found a workaround by modifiying the mouse adapter (see below). I am glad that this Bug will be fixed in 3.3!
Thanks,
Jan
addDoubleClickListener(new IDoubleClickListener() {
public void doubleClick(DoubleClickEvent event) {
// Avoid overhead when no activation strategy or no editors
if( cellEditorActivationStrategy != null && getCellEditors() != null && getCellEditors().length > 0 ) {
Item[] items = treeControl.getSelection();
// Do not edit if more than one row is selected.
if (items.length != 1) {
return;
}
// ONLY this had to be changed
if( cellEditorActivationStrategy != null && cellEditorActivationStrategy.shouldActivateCellEditor(lastMouseEvent, items[0].getData(), true) ) {
treeViewerImpl.handleMouseDown(lastMouseEvent);
}
}
}
});
(In reply to comment #9)
> (In reply to comment #8)
> > Hi All,
> >
> > can somebody please fix the bug? It is really bad especially if you enable
> > table/ tree editing:
> >
> > On start of the drag the editor is opened. When the drag is finished you end up
> > with an editor for a Tree item that does not exist any more!!!
> >
> > By the way the existing patch does NOT work for the TreeViewer. This needed
> > another hack of mine. The problem is that now I have to deploy a custom hacked
> > jface library which is not good software development.
> >
> > Thanks very much,
> > Jan
> >
>
> Could you please provide information what's not working when running with
> TreeViewer and I'll incooperate it into my own version, I must admit that I
> have only tried it using TableViewer. Did you take a look into my
> SVN-Repository you don't need to ship your own JFace-Component because you
> could work around it like shown there.
>
Hi, (In reply to comment #10) > Hi, > // ONLY this had to be changed > if( cellEditorActivationStrategy != null && > cellEditorActivationStrategy.shouldActivateCellEditor(lastMouseEvent, > items[0].getData(), true) ) { > I can't see any difference from what you posted than what the patch would give you the only thing you added is the null check which is unnecessary because it is already done in the if above. > treeViewerImpl.handleMouseDown(lastMouseEvent); > } > } > } > }); > > Created attachment 46238 [details]
This patch fixes a problem with an endless-loop
In some situations it is possible that Viewer gets into an endless loop fireing doubleClick events without any reason (I only had this behaviour on linux-gtk)
Following up from comments in bug 149193. Tom, I see what you mean about not knowing which column. I was thinking in terms of the Nebula Grid which uses spreadsheet like cell selection and therefore knows what cell should be activated. I think I can do what I need with the implementation described here. Let me run it by you and see if it makes sense. I don't want the editor to be activated on mouse down (single or double) so I can provide an activation strategy that always returns false. Seperately I can also add my own key listener on the table and call TableViewer.editElement(model, column). Thats it I think. I will also need to find some way to redirect the first key pressed to the editor that becomes active. I'll have to explore that, but otherwise does that seem workable? (In reply to comment #13) > Following up from comments in bug 149193. > > Tom, I see what you mean about not knowing which column. I was thinking in > terms of the Nebula Grid which uses spreadsheet like cell selection and > therefore knows what cell should be activated. I think I can do what I need > with the implementation described here. Let me run it by you and see if it > makes sense. > > I don't want the editor to be activated on mouse down (single or double) so I > can provide an activation strategy that always returns false. Seperately I can > also add my own key listener on the table and call > TableViewer.editElement(model, column). Thats it I think. I will also need to > find some way to redirect the first key pressed to the editor that becomes > active. I'll have to explore that, but otherwise does that seem workable? > You are completely right Chris but even SWT-Table could provide it. But there are some things I think need to be done before e.g. #151377 and afterwards #151295. May current way of thinking is to incooperate the Activation-Strategy into EditingSupport once bug #155346 and bug #154329 are sorted. Right, thanks. For all those who want to use DoubleClick Activation I attached a snippet our collection demonstrating how this could be done easily before 3.3 will add support for it. See bug #164365 (In reply to comment #15) > Right, thanks. > Chris if you are interested I just added a patch to bug #151295 where your problem of losing the first entered key is also addressed ;-) For all of you guys the patch in bug #151295 solves all the activation problems. fixed as part of bug #172646 sorry not marked fixed Verified in I20070321-1800 by running Snippet026TreeViewerTabEditing |