Community
Participate
Working Groups
R3.0 Michael Spiegel reports: Hello, I'm trying to use a FileEditorInputFactory within my plugin. I've added the following extension point to my plugin.xml: <extension point = "org.eclipse.ui.elementFactories"> <factory id ="org.eclipse.ui.part.FileEditorInputFactory" class="org.eclipse.ui.part.FileEditorInputFactory"> </factory> </extension> I keep on getting the error, "Unable to restore editor - no input factory ID." I've tracked the problem down to org.eclipse.ui.internal.EditorManager, where I get a NullPointerException thrown here: // TODO - DDW - dynamic UI - a check for a null input was deliberately removed here. if (input instanceof IPathEditorInput) { editorMem.putString(IWorkbenchConstants.TAG_PATH,((IPathEditorInput)inpu t).getPath().toString()); } So am I doing something wrong on my end, or is there a cleanup needed in this eclipse code?
You don't need to include that extension in your plugin.xml. It's already in the plugin.xml for org.eclipse.ui.ide. The "Unable to restore editor - no input factory ID." error occurs if the memento from workbench.xml for the editor has no factoryId attribute. This is done in EditorManager.getRestoredInput(). Note that it hasn't even tried to look up the factory class yet. The NPE you report must be due to a null result from getPath(). Can you confirm? Since this occurs before EditorManager.saveEditorState has written the factory id, that would cause it to be omitted. It would be better if it skipped writing the editor memento entirely in the case of an error like this. FileEditorInput.getPath() should only return null in bizarre circumstances though, e.g. a linked resource referring to an undefined workspace variable. See IResource.getLocation() for more details. Michael, are you using linked resources at all? Is the project containing the file closed? Anything else unusual?
*** Bug 71298 has been marked as a duplicate of this bug. ***
> The NPE you report must be due to a null result from getPath(). Can you confirm? Yup, the NPE is caused by a null result from getPath(), which is caused by project.exists() is returning false in file.getLocation(). I am creating the file in the getStateLocation() area of my plugin. Is that messing things up? Here's how I create the file, IPath filePath = changeLogPlugin.getStateLocation().append(fileName); if(filePath.toFile().createNewFile()) { out = new FileWriter(filePath.toFile()); out.write(entry.toString()); out.close(); out = null; filePath.toFile().setReadOnly(); } IFile fileHandle = ResourcesPlugin.getWorkspace().getRoot().getFile(filePath); FileEditorInput fEditorInput = new FileEditorInput(fileHandle); IWorkbenchPage activePage = changeLogPlugin.getWorkbench().getActiveWorkbenchWindow().getActivePage(); activePage.openEditor(fEditorInput, "org.eclipse.ui.DefaultTextEditor");
This is a very non-standard way to use the workspace. First off, getStateLocation() returns a directory in the workspace's metadata area. Regular workspace files or other resources should not go here. Also, you're mixing up file system paths and workspace paths. filePath is a filesystem path, but getFile expects a workspace-relative path. It's treating the first segment of the path as the project name, which does not exist. E.g. if the filePath ends up being "c:\eclipse\workspace\.metadata\.plugins\yourplugin\filename", then it's looking for project "eclipse" ("c:" is the device of the path). Try using: IFile fileHandle = ResourcesPlugin.getWorkspace().getRoot().getFileForLocation(filePath); instead. I'd also suggest you create the project and file using the IResource APIs, rather than the java.io.File APIs. E.g.: String projectName = "MyProject"; IProject project = workspace.getRoot().getProject(projectName); if (!project.exists()) { IProjectDescription desc = workspace.newProjectDescription(projectName); project.create(desc); } IFile file = project.getFile(fileName); InputStream is = new StringBufferInputStream(entry.toString()); file.create(is, false, null); file.setReadOnly(true);
Ah, I am begining to understand what's happening. Let me give a small bit of background: I'm writing a plugin that provides ChangeLog-style aggregates of the CVS log entries. I'm writing a DoubleClickListener, so that when the user clicks on an entry, a temporary file is created with the information (if it does not exist), and opened in a DefaultTextEditor. Looking at it now, I had two design options. Dump the temporary files into a central location, getStateLocation(). Or dump each temporary file into the project it is associated with. I choose the first option, at the time not considering the second option. Is it possible to pull in the getStateLocation() files into a workspace path? I guess not, since they are not in the workspace. I may have to switch my design approach, in that case.
As a followup, I've reimplemented that piece of code to distribute the temporary files among the projects they belong to. It wasn't too difficult. I guess the remaining question is whether it would be a good idea to allow plugin-internal files to have a workspace path. In my example, it would be beneficial as I could centralize all my temp files, instead of scattering them among projects. But I do not know if there are disadvantages to adding that functionality. Thanks for all your help so far.
If it's for temporary files, then using the state location is not bad. It's possible to use linked resources, where the workspace file points to a physical file that is not directly under the regular location for the containing project. See IFile.createLink(...).
Also, I recommend using a SelectionListener and implementing the defaultSelect handler instead of using a double-click listener. That way, using the arrow keys and Enter will work. If you're using a viewer, use addOpenListener instead, which automatically honours the preference for single-click or double-click to open.
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
Remy is now responsible for watching the [EditorMgmt] component area.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
