| Preventing ErrorEditorInput from Showing [message #480809] |
Tue, 18 August 2009 10:54  |
Eclipse User |
|
|
|
Hello!
I'm working on improving a plugin. The problem I'm encountering is this:
There's a class
public class LispDocumentProvider extends FileDocumentProvider
protected IDocument createDocument(Object element) throws CoreException {
IDocument document = super.createDocument(element);
//..etc
}
When the user attempts to open a file with file-open and chooses a file
which is not in the current selected project in the navigator, the
document provider, which is called when creating an editor
(createPartsControl), attempts to call super.createDocument(element). This
returns null because the document is not 'provided' by the current file
provider for the current project.
I have changed the code to detect if it is null and if so create a new
file in a default project. However, while this works, I have to return
something in createDocument, the value null. This forces an exception
somewhere and a ErrorEditorInput is created. I would like to prevent this.
I have tried hooking into the init method for the Editor class, but no
matter what exception I throw, it always opens it in an error editor.
The problem is narrowed down to the EditorReference class which calls
createPart(), and then if an error is introduced, it calls getEmptyEditor
which creates the ErrorEditorInput.
I imagine this class is created when the user presses open on the file
open dialog. Thus, I have no control over it unless i want to take control
of the file open dialog somehow.
Any ideas?
Thanks!
|
|
|
| Re: Preventing ErrorEditorInput from Showing [message #481000 is a reply to message #480809] |
Wed, 19 August 2009 06:34  |
| Eclipse User |
|
|
|
Seth wrote:
> Hello!
> I'm working on improving a plugin. The problem I'm encountering is this:
>
> There's a class
> public class LispDocumentProvider extends FileDocumentProvider
> protected IDocument createDocument(Object element) throws CoreException {
> IDocument document = super.createDocument(element);
>
> //..etc
> }
>
> When the user attempts to open a file with file-open and chooses a
> file which is not in the current selected project in the navigator,
> the document provider, which is called when creating an editor
> (createPartsControl), attempts to call super.createDocument(element).
> This returns null because the document is not 'provided' by the
> current file provider for the current project.
>
> I have changed the code to detect if it is null and if so create a new
> file in a default project. However, while this works, I have to return
> something in createDocument, the value null. This forces an exception
> somewhere and a ErrorEditorInput is created. I would like to prevent
> this.
>
> I have tried hooking into the init method for the Editor class, but no
> matter what exception I throw, it always opens it in an error editor.
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=70838
Dani
>
> The problem is narrowed down to the EditorReference class which calls
> createPart(), and then if an error is introduced, it calls
> getEmptyEditor which creates the ErrorEditorInput.
> I imagine this class is created when the user presses open on the file
> open dialog. Thus, I have no control over it unless i want to take
> control of the file open dialog somehow.
>
> Any ideas?
> Thanks!
|
|
|
|
| Re: Preventing ErrorEditorInput from Showing [message #481742 is a reply to message #481712] |
Mon, 24 August 2009 03:53 |
| Eclipse User |
|
|
|
Seth wrote:
> Quote from bug report:
> "Downgrading since everyone must have worked around this by now. It
> looks like
> this could be fixed by checking for the error edit part explicitly and
> returning null in that case.
> "
> What's the work around?
I'd directly ask in the bug report.
Dani
> No matter what, i have to return something to represent the document.
> That ErrorEditorInput is displayed for anything which, well, which
> isn't valid! If I could change the actual eclipse code which checks
> for the ErrorEditorInput, it would be trivial, but i can't!
>
> The only 'work around' i've found is to close the error right after it
> opens. It is really not a solution, though, because it takes a while
> for it to open and then close. Very visible!
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.04878 seconds
Home