Community
Participate
Working Groups
I200406190041 I wanted to rename the field "listeners" in the following code: import java.util.EventListener; import javax.swing.event.EventListenerList; public class Test1 { EventListenerList listeners = new EventListenerList(); public void addEventListener(EventListener eventListener) { listeners.add(EventListener.class, eventListener); } } Steps: - Trigger Rename Field Refactoring (using Ctrl-Shift-R) while Cursor is on "listeners" - Rename Field-Dialog opens - Type "ev" in "New Name" and trigger Code Assistant using "Ctrl-Space" Actual Result: A popup opens suggesting some field-names, *but* this popup is triggered on the editor, and not on the dialog. If you press "Enter" to select a suggestion the field is renamed to "ev", and the popup remains open. Expected Result: Popup closes and selection is inserted into the "New Name"-Field.
This is actuall the same problem as described in bug 67611. The keyboard short cuts target the widget of the application window not the dialog. I tested this on build I200406191600 and could reproduce. To better see the bahaviour, open the rename dialog and move it to the lower right corner and press Ctrl+Space in the dialog. You see the code assist opening on the editor. Marking as critical since this is a regression. Moving to platform UI since 67611 was fixed there.
Some additional info... When pressing ctrl+space in a dialog which offers code assist in a field (e.g. New Class>Superclass, Refactoring>Change Method Signature) then the code assist dialog shows up as expected, i.e., it targets the dialog. In the case of Rename Field we don't offer code assist in the dialog (but we should bug# 67974). This means that pressing ctrl+space in any dialog which doesn't offer code assist will pop-up the code assist targetting the editor (e.g. Open Type).
I see this problem as well. This is likely a handler submission somewhere that is not specifying a shell. Downgrading to major, as this does not cause crashes or loss of data.
Note that this seems to be a problem with all commands with "When:" set to "In Dialogs". When I change 'Text Editing > Select Next Word' from 'Editing Text' to 'In Dialogs and Windows', I see the same behavior in any dialog.
Is this dialog supposed to support content assist?
The problem is likely as follows: + Fall back support was added to dialogs to support detached views. Detached views look like dialogs, but want the regular workbench window handlers. So, if no handler is defined for the active shell, the command mechanism checks to see if there is a handler for the active workbench window. + Code assist has a hander on the workbench window, the key binding is defined as dialog+window, but the handler does not handle the case where a dialog is open. Would it be possible to change the content assist action (the one registered on the workbench window) to include a line "if (!workbenchWindow.getShell().equals(display.getActiveShell())) return;"?
> Is this dialog supposed to support content assist? No! The original poster thought it should, and maybe we'll add it post 3.0. Currently it doesn't support content assist and the shortcut should behave as every other unbound shortcut (do nothing). As said in my comment 4, the problem is not about content assist. It's a general problem of all commands which are assigned to the 'In Dialogs and Windows' context. Users and plugin providers can run into this problem whenever they define a command to be active in the d&w context. Another example: Assign Ctrl+Alt+A to Views > Ant. Close the Prefs dialog and re-open it. Pressing Ctrl+Alt+A now opens the Ant view in the Workbench Win. => I don't think we should have to change something with the content assist handler.
Created attachment 12581 [details] Patch to "org.eclipse.ui.workbench" This fixes the problem in two ways: 1.) Actions register through the key binding service are assigned a shell 2.) If a dialog is open, then the fallback to window won't be allowed.
Patch is reviewed by Tod Creasey and Kim Horne. It has been committed to CVS. It should appear in I200406221600.
Verified in I200406230010, GTK+ 2.4.1, KDE 3.2.2, Linux 2.6.6.
