Bugzilla – Full Text Bug Listing
| Summary: | Active cell editor does not prevent execution of shell default button when "Enter" is pressed | ||
|---|---|---|---|
| Product: | [RT] RAP | Reporter: | Jamie <ctljm> |
| Component: | RWT | Assignee: | Project Inbox <rap-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | austin.riddle, juergen.panser, neubauer, rsternberg, swimmer_86 |
| Version: | 1.3 | ||
| Target Milestone: | 1.5 M5 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 334504 | ||
| Bug Blocks: | |||
The actual problem is that dialog ( Shell ) default button execution is not prevented if there is an active cell editor. As a workaround set dialog default button to null. Needs more investigation how this is prevented in JFace. Changed the title accordingly. Ivan, do you know any news about fixing progress of this issue? Best regards, Yury. Hi Yury, sorry for the late response, but I was in vacation these days. I had no time to investigate it further, but I will look on it again this week. Some additional findings. In RCP the default button execution is prevented by canceling the SWT.TRAVERSE_RETURN event - see TextCellEditor line 168. In RAP, the default button does not respect the canceled SWT.TRAVERSE_RETURN event. We need first to solve the bug 334504, as SWT.TRAVERSE_RETURN event is not fired at all in IE, Safari, Chrome and Opera. (In reply to comment #5) > We need first to solve the bug 334504, as SWT.TRAVERSE_RETURN event is not > fired at all in IE, Safari, Chrome and Opera. Since bug 334504 is fixed and this bug has been opened for 1.3 - Is this something for a last-minute fix for SR2? No... The bug 334504 was a blocker, but not enough to fix this one. Additional fixes (both on client and/or... jface) are needed. There is also same issue with ESC key, in RCP esc disable text cell edition without closing the whole dialog. In RAP pressing ESC close the dialog Hi, I ran into the same problem with an editing support in a wizard dialog. Same code in a FormEditor works. The inital problem was reported about one year ago. Is a fix planned in the near future? There is no easy fix for this issue (both client and server side are affected). I will look on it again as soon as possible, but I can't promise anything. Thanks.
A quickfix may be to overwrite the buttonPressed method of the WizardDialog class:
protected void buttonPressed(final int buttonId) {
if (Display.getDefault().getFocusControl() instanceof Button) {
super.buttonPressed(buttonId);
}
}
A second approach may be to change the behavior of the keyReleaseOccured method in the TextCellEditor:
protected void keyReleaseOccured(final KeyEvent keyEvent) {
if (useHack) {
if (keyEvent.character == '\r') { // Return key
// Because of RAP bug 329926 handleDefaultSelection isn't called -> we have to do it by our own
if (this.text != null && !this.text.isDisposed() && (this.text.getStyle() & SWT.MULTI) != 0) {
if ((keyEvent.stateMask & SWT.CTRL) != 0) {
super.keyReleaseOccured(keyEvent);
return;
}
}
//handleDefaultSelection(event);
fireApplyEditorValue();
deactivate();
}
}
super.keyReleaseOccured(keyEvent);
}
But these are only quickfixes...
The main problem here is that canceling a key event (ENTER or ESC) works on the client-side "keypress" DOM event. As "default" button execution and dialog close by Escape key is done on "keydown" DOM event (see Shell.js#_onKeydown) the current JFace mechanism does not work. One possible solution will be to change the "default" button execution and dialog close by Escape key to "keypress" DOM event. In this case some additional adjustments are needed as Text widget prevents the propagation of "keypress" events (see TextField.js#_onkeypress). With RAP 1.5 M4 this problem occurs with every Text widget! If you have a Text widget and buttons the first button gets a selection event if the return key is pressed in the Text widget. The last button that has got the focus triggers the selection event. Create a composite with e textbox and two button A and B. Click on A (which may open a dialog) then click into the textbox, enter some chars and press the return key. The dialog opens. With the implementation of CANCEL_KEY (Bug 367869) and adaption of JFAce code (Bug 367923) to use them, this issue has been fixed. Using ESC and ENTER on active cell editor does not affect parent dialog anymore. Juergen, could you open a separate bugzilla about your findings. |
Build Identifier: 20100917-0705 I have a TextCellEditor used in a EditingSupport which handles the editing in a TableViewer, and this TableViewer locates in a Dialog. The problem is, when I edited the cell in the table and then pressed 'Enter', the whole dialog was closed. The correct behavior should be that the editor was deactivated. And the same code works well in RCP. So it is a problem in RAP. With almost the same code, except that the TableViewer was moved from a dialog to a view, it worked with no problem, even in RAP. I debug the code, and found that the TextCellEditor.handleDefaultSelection() was not called when the 'Enter' was pressed. While in RCP, or using a view in RAP, the method was called. Reproducible: Always Steps to Reproduce: 1.Create your own dialog: public class ViewerDiaglog extends Dialog { ... protected Control createDialogArea(Composite parent) { ... viewer = new TableViewer(parent, SWT.MULTI | SWT.H_SCROLL | SWT.V_SCROLL | SWT.FULL_SELECTION); Table table = viewer.getTable(); String[] titles = { "First name", "Last name", "Gender", "Married" }; int[] bounds = { 100, 100, 100, 100 }; for (int i = 0; i < titles.length; i++) { final int index = i; final TableViewerColumn viewerColumn = new TableViewerColumn(viewer, SWT.NONE); .... viewerColumn.setEditingSupport(new PersonEditingSupport(viewer, i)); ... } ... } 2. Create your own editing support: public class PersonEditingSupport extends EditingSupport { private CellEditor editor; private int column; public PersonEditingSupport(ColumnViewer viewer, int column) { super(viewer); ... editor = new TextCellEditor(((TableViewer) viewer).getTable()); ... } ... } 3.Create a button in your view to open the dialog for testing. public class View extends ViewPart { ... @Override public void createPartControl(Composite parent) { buttonOK = new Button(parent, SWT.PUSH); buttonOK.setText("Open a viewer dialog"); buttonOK.addSelectionListener(new SelectionAdapter() { @Override public void widgetSelected(SelectionEvent e) { Shell shell = getViewer().getTable().getShell(); ViewerDiaglog dialog = new ViewerDiaglog(shell); dialog.open(); // MessageDialog.openInformation(shell, "WARNING", "You pressed OK!"); } }); } ... } 4. Run your application in RAP: press the button, the dialog with a viewer should popup. 5. Click a cell in the table to edit the text, key in some characters, then press 'Enter'. 6. Now the dialog is closed, which is wrong. 7. If you set a breakpoint in TextCellEditor.handleDefaultSelection(e), you will find that it is not called, which it should.