Community
Participate
Working Groups
RDT disables the File->Move menu item also for non-remote projects in the "C/C++" and the "Remote C/C++" perspective. Steps to reproduce: - Create standard (non-remote) C project - Select it - Observe that File->Move is grayed out It is not grayed out if either in a different perspective (e.g. Java) or if RDT is not loaded as a plugin. Also if one tries to move an RDT project using File->Move from a difference perspective (where it is not grayed out) one gets a NullPointer Exception: java.lang.NullPointerException at org.eclipse.ui.internal.ide.dialogs.ProjectContentsLocationArea.createUserEntryArea(ProjectContentsLocationArea.java:236) Summary: File->Move should not be grayed out for non RDT projects even in the Remote perspective and it should be grayed out for RDT projects even in other perspectives. If that is not possible an error should be shown instead of just causing a NullPointerException.
Which version of PTP/RDT are you using? As for as I know we didn't disable the Move command in RDT. Can you provide the error stack?
I discovered it with latest CVS HEAD. I just tested it and the problem is already present in Helios (4.0.6). The stacktrace (for latest CVS HEAD): java.lang.NullPointerException at org.eclipse.ui.internal.ide.dialogs.ProjectContentsLocationArea.createUserEntryArea(ProjectContentsLocationArea.java:236) at org.eclipse.ui.internal.ide.dialogs.ProjectContentsLocationArea.createContents(ProjectContentsLocationArea.java:166) at org.eclipse.ui.internal.ide.dialogs.ProjectContentsLocationArea.<init>(ProjectContentsLocationArea.java:114) at org.eclipse.ui.dialogs.ProjectLocationMoveDialog.createDialogArea(ProjectLocationMoveDialog.java:112) at org.eclipse.jface.dialogs.Dialog.createContents(Dialog.java:760) at org.eclipse.ui.dialogs.ProjectLocationMoveDialog.createContents(ProjectLocationMoveDialog.java:96) at org.eclipse.jface.window.Window.create(Window.java:431) at org.eclipse.jface.dialogs.Dialog.create(Dialog.java:1089) at org.eclipse.jface.window.Window.open(Window.java:790) at org.eclipse.ui.actions.MoveProjectAction.queryDestinationParameters(MoveProjectAction.java:153) at org.eclipse.ui.actions.MoveProjectAction.run(MoveProjectAction.java:167) at org.eclipse.jdt.internal.ui.refactoring.reorg.ReorgMoveAction.run(ReorgMoveAction.java:105) at org.eclipse.jdt.ui.actions.MoveAction.run(MoveAction.java:146) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:275) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(SelectionDispatchAction.java:251) at org.eclipse.jface.action.Action.runWithEvent(Action.java:498) at org.eclipse.jface.commands.ActionHandler.execute(ActionHandler.java:119) at org.eclipse.core.commands.Command.executeWithChecks(Command.java:476) at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508) at org.eclipse.ui.internal.handlers.HandlerService.executeCommand(HandlerService.java:169) at org.eclipse.ui.internal.handlers.SlaveHandlerService.executeCommand(SlaveHandlerService.java:241) at org.eclipse.ui.menus.CommandContributionItem.handleWidgetSelection(CommandContributionItem.java:829) at org.eclipse.ui.menus.CommandContributionItem.access$19(CommandContributionItem.java:815) at org.eclipse.ui.menus.CommandContributionItem$5.handleEvent(CommandContributionItem.java:805) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4163) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3752) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) at org.eclipse.equinox.launcher.Main.run(Main.java:1410) at org.eclipse.equinox.launcher.Main.main(Main.java:1386)
I just launched a runtime from my workspace and noticed the following: a) Local/remote C/C++ projects cannot be moved (the Move command is disabled) in C/C++ or Remote C/C++ perspective because the action associated with that command is MoveResourceAction: Standard action for moving the currently selected resources elsewhere in the workspace. All resources being moved as a group must be siblings. (http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/ui/actions/MoveResourceAction.html) Therefore Move command is disabled on the project level. This action is contributed via the org.eclipse.ui.navigatorContent extension point in CDT. If you select something inside the project, the Move command will be enabled. So RDT is not preventing projects to be moved. b) Move command is enabled for Java projects and its children in the C/C++ and the Remote C/C++ perspectives. That's because JDT uses a different move action for the Move command. c) I'm not sure how the Move command is enabled for the local/remote C/C++ project in other perspectives. You might want to open another bug for this.
(In reply to comment #3) > I just launched a runtime from my workspace and noticed the following: > > a) Local/remote C/C++ projects cannot be moved (the Move command is disabled) > in C/C++ or Remote C/C++ perspective because the action associated with that > command is MoveResourceAction: > > Standard action for moving the currently selected resources elsewhere in the > workspace. All resources being moved as a group must be siblings. > > (http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/ui/actions/MoveResourceAction.html) > > Therefore Move command is disabled on the project level. This action is > contributed via the org.eclipse.ui.navigatorContent extension point in CDT. But it is not correct that the Move of a standard C/C++ project is disabled. You can move a C project in the C perspective as long as RDT is not installed as a plugin. > If you select something inside the project, the Move command will be enabled. > So RDT is not preventing projects to be moved. Yes you can move files within a project. I'm only talking about moving the whole project. > c) I'm not sure how the Move command is enabled for the local/remote C/C++ > project in other perspectives. You might want to open another bug for this. I don't think it is enabled in other perspectives but instead disabled by RDT. That's why I filed it against RDT. The reason is that I can move local C projects in the C perspective as long as RDT is not installed. Thus I'm reopening it because I still think it is an RDT bug.
(In reply to comment #4) > But it is not correct that the Move of a standard C/C++ project is disabled. > You can move a C project in the C perspective as long as RDT is not installed > as a plugin. I can reproduce this using CDT only with the Indigo RC3 build so this is a CDT issue. Please open a bug against CDT for this. RDT reuses CNavigatorRefactorActionGroup from CDT which uses the MoveResourceAction I mentioned in my previous comment. > > c) I'm not sure how the Move command is enabled for the local/remote C/C++ > > project in other perspectives. You might want to open another bug for this. > I don't think it is enabled in other perspectives but instead disabled by RDT. > That's why I filed it against RDT. The reason is that I can move local C > projects in the C perspective as long as RDT is not installed. > > Thus I'm reopening it because I still think it is an RDT bug. The inability to move a local/remote C/C++ project is not something contributed by RDT so I think this should be resolved as invalid or this bug should be moved to CDT.
I just retested it with CDT and without RDT and I agree. It is caused by CDT. I must have made a mistake before when testing. Sorry! It is disabled in the C perspective even without RDT. I'll create a new bug against CDT. This leaves the NullPointerExcpetion. Since the NullPointerException is only caused if the user is in the "wrong" perspective it could probably reduced to low priority (or maybe also closed).
(In reply to comment #6) > I just retested it with CDT and without RDT and I agree. It is caused by CDT. I > must have made a mistake before when testing. Sorry! It is disabled in the C > perspective even without RDT. I'll create a new bug against CDT. > > This leaves the NullPointerExcpetion. Since the NullPointerException is only > caused if the user is in the "wrong" perspective it could probably reduced to > low priority (or maybe also closed). Thanks for verifying Roland. Yes I agree the NPE should be low priority.
Assuming this will not be fixed.
