Community
Participate
Working Groups
I20030813 The search view sets the global action handler for the goto next match action like this: action.setActionDefinitionId("org.eclipse.ui.navigate.next"); //$NON-NLS-1$ and in the view: actionBars.setGlobalActionHandler(IWorkbenchActionConstants.NEXT, action); I suspect the reason why it stopped working is that platform text introduced an action via XML: <action id="org.eclipse.ui.edit.text.gotoNextAnnotation" label="%goToNextAnnotation.label" tooltip="%goToNextAnnotation.tooltip" toolbarPath="org.eclipse.ui.workbench.navigate/history.group" retarget="true" style="pulldown" allowLabelUpdate="true" definitionId="org.eclipse.ui.navigate.next" icon="icons/full/etool16/next_nav.gif" disabledIcon="icons/full/dtool16/next_nav.gif" hoverIcon="icons/full/ctool16/next_nav.gif" class="org.eclipse.ui.internal.texteditor.NextPulldownActionDelegate"/> which is retargeted by the Java editor and also retargets IWorkbenchActionConstants.NEXT: bars.setGlobalActionHandler(ITextEditorActionDefinitionIds.GOTO_NEXT_ANNOTATION, fNextAnnotation); bars.setGlobalActionHandler(ITextEditorActionConstants.NEXT, fNextAnnotation); I can still step through the results if the results are not opened in the Java editor. Once the Java editor gets opened (with activate == false) the shortcuts stop working. It looks as if the control is transferred to the Java editor but not fully returned to the Search view.
*** Bug 41672 has been marked as a duplicate of this bug. ***
please look at this.. thanks..
*** Bug 42271 has been marked as a duplicate of this bug. ***
This is painful. The problem was introduced sometime in between the I20030806 build and the I20030813 build. It appears the the actionsById held by the CommandManager is modified by bringing the Java source editor to the top. It's at this point that the actionsById changes from non-Java commands to Java commands. This changed is triggered by the match navigation code. Here's a rough trace where the actionsById actually changes: org.eclipse.ui.internal.Workbench.updateActiveCommandIdsAndActiveContextIds(Workbench.java:638) at org.eclipse.ui.internal.WorkbenchWindow.registerActionSets(WorkbenchWindow.java:450) at org.eclipse.ui.internal.WorkbenchWindow.updateActiveActions(WorkbenchWindow.java:1160) at org.eclipse.ui.internal.WorkbenchWindow.updateActionSets(WorkbenchWindow.java:2009) at org.eclipse.ui.internal.WorkbenchPage$ActionSwitcher.updateActionSets(WorkbenchPage.java:350) at org.eclipse.ui.internal.WorkbenchPage$ActionSwitcher.updateTopEditor(WorkbenchPage.java:256) at org.eclipse.ui.internal.WorkbenchPage.bringToTop(WorkbenchPage.java:555) at org.eclipse.ui.internal.WorkbenchPage.showEditor(WorkbenchPage.java:2124) at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2062) at org.eclipse.ui.internal.WorkbenchPage.access$6(WorkbenchPage.java:2029) at org.eclipse.ui.internal.WorkbenchPage$9.run(WorkbenchPage.java:2016) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:84) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2011) at org.eclipse.ui.internal.WorkbenchPage.openMarker(WorkbenchPage.java:1988) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:1928) at org.eclipse.search.internal.ui.text.GotoMarkerAction.showWithoutReuse(GotoMarkerAction.java:137) at org.eclipse.search.internal.ui.text.GotoMarkerAction.show(GotoMarkerAction.java:58) at org.eclipse.search.internal.ui.text.GotoMarkerAction.run(GotoMarkerAction.java:50) at org.eclipse.search.internal.ui.SearchResultViewer.openCurrentSelection(SearchResultViewer.java:543) at org.eclipse.search.internal.ui.SearchResultViewer.showNextResult(SearchResultViewer.java:484) at org.eclipse.search.internal.ui.ShowNextResultAction.run(ShowNextResultAction.java:28) at org.eclipse.jface.action.Action.runWithEvent(Action.java:842) at org.eclipse.ui.actions.RetargetAction.runWithEvent(RetargetAction.java:203)
Commenting out the following line in the plugin.xml makes it work (for both searching and annotations): definitionId="org.eclipse.ui.navigate.next" Unfortunately, I'm not sure why. Perhaps Chris can answer this question better than I.
*** Bug 42933 has been marked as a duplicate of this bug. ***
*** Bug 33531 has been marked as a duplicate of this bug. ***
*** Bug 43627 has been marked as a duplicate of this bug. ***
JDT might consider Doug's suggestion in #5 for the M4 build *only*. i can't get a proper fix in for the build tomorrow, so here at least is an explanation of the problem (for those ui people on the cc: list who may care): the command system gathers up from the workbench a mapping of command ids to action instances. key sequences are bound to command ids, so it is this mapping that resolves which action instance to run when a key sequence is pressed. this map is built as a composite of other command id to action instance maps, in the following order: global actions actionsets workbench page action service workbench part action service the last two maps are part of the new command system still in progress, the first two are the mechanism to get legacy code working with the keybindings. early on, the search view registers a global action (which goes in the first map). everything works fine until a java editor is opened, which causes the an action of the same command id to be registered in the action set map. as long as the java editor is open, it is this action that is getting the command id (and hence the keybindings) - even when part focus changes. when all java editors close things return to normal. as i said, i don't think i can fix safely this tonight. it's late and i just ate a big bowl of ice cream and some gummi rats. so hard to think.. :) i *may* be able to get a safe fix in in the morning, if for some reason we are delayed, otherwise this needs to be postponed until after M4.
I wouldn't change the XML for M4 since this might affect other scenarios (e.g. next/previous hidden due to disabled action set but key binding in editor should still work).
Marking for M5 so that a better solution can be explored.
*** Bug 44461 has been marked as a duplicate of this bug. ***
When talking yesterday with the UI team we agreed that next/prev navigation for the search view is not critical for M4. Maybe this decission has to be revisted depending on how important this is for the Debug team.
*** Bug 33105 has been marked as a duplicate of this bug. ***
*** Bug 44942 has been marked as a duplicate of this bug. ***
*** Bug 46495 has been marked as a duplicate of this bug. ***
What is the status of this bug for M5?
this bug did not get fixed for m5, with activities and roles work taking priority. moving to m6.
fixed. in org.eclipse.search.internal.ui.SearchResultViewer, the constructor includes: IActionBars actionBars= fOuterPart.getViewSite().getActionBars(); actionBars.setGlobalActionHandler(ActionFactory.NEXT.getId(), fShowNextResultAction); * this handler is active only when the Search view is active in org.eclipse.jdt.internal.ui.javaeditor.BasicJavaEditorActionContributor init(IActionBars bars, IWorkbenchPage page) includes: bars.setGlobalActionHandler(ITextEditorActionConstants.NEXT, fNextAnnotation); * this handler is active only when the java editor or outline view (are there others?) is active. so far so good. the problem is that the action set registers as well when the first java editor opened (activated or not). we register all actions in active action sets to receive keybindings. i made this true so long as no global action is registered.
