Read-only editor content: ByteArrayStorage & ByteArrayStorageEditorInput [message #545725] |
Thu, 08 July 2010 18:37 |
|
The read-only version is pretty trivial:
public class ByteArrayStorage implements IStorage {
private byte bytes[];
public ByteArrayStorage(byte bytes_[]) {
bytes = bytes_;
}
@Override
public InputStream getContents() throws CoreException {
return new ByteArrayInputStream( bytes );
}
@Override
public IPath getFullPath() {
return null;
}
@Override
public String getName() {
return "Bytes";
}
@Override
public boolean isReadOnly() {
return true;
}
@Override
public Object getAdapter(Class adapter) {
return null;
}
}
and
public class ByteArrayStorageEditorInput implements IStorageEditorInput {
private ByteArrayStorage store;
public ByteArrayStorageEditorInput( byte bytes[] ) {
store = new ByteArrayStorage( bytes );
}
@Override
public IStorage getStorage() throws CoreException {
return store;
}
@Override
public boolean exists() {
return false;
}
@Override
public ImageDescriptor getImageDescriptor() {
return null;
}
@Override
public String getName() {
return store.getName();
}
@Override
public IPersistableElement getPersistable() {
return null;
}
@Override
public String getToolTipText() {
return store.getName();
}
@Override
public Object getAdapter(Class adapter) {
return null;
}
}
(context: I'm using eclipse 3.5 with WTP among other things installed)
However, when I change storage.isReadOnly() to return false, I get an NPE (no suprise) in at org.eclipse.jface.text.source.LineNumberRulerColumn.getWidth (LineNumberRulerColumn.java:477). Not where I'd expect it to blow, but whatever. Again, this is with a JS file. I suspect other editor types would choke in other places (or not at all).
.java editor NPEs in the same spot. No shock there, the JS editor derives from the java editor.
.cpp "works", but cannot "undirty" itself. Not surprising given an IStorage that claims to be writable but has no way to be written.
Ditto for the standard XML editor, though it didn't care for the formatting of my javascript file. Shocker.
Not bad. Better than I expected in fact. Still... the one I actually care about blows up. No bueno.
--Mark Storer
Senior Software Engineer
Autonomy Cardiff
import legalese.disclaimer;
Disclaimer<Cardiff> disCard = null;
Google Code Search
|
|
|
Re: Read-only editor content: ByteArrayStorage & ByteArrayStorageEditorInput [message #545727 is a reply to message #545725] |
Thu, 08 July 2010 18:52 |
|
Oddly enough, my code looks remarkably similar to what's posted here
According to this blog, implementing an IPersistableElement will allow the data to be saved...
More as things develop.
EDIT: Grr. Returning an IPersistableElement implementation allows didn't help with the NPE. Turning off quick-diff did. Huh. Okey doke.
That hurdle passed, I started looking into getting my data back out of some random editor. Doesn't look good. Given an IEditorPart, there doesn't seem to be a way to extract its contents.
The only thing I can think of at this point is to respond to all those getAdapter(IJavaScriptElement.class) calls and cross my fingers.... and JavaScriptCore only takes IFiles... Augh!
Even if I can convince JSC to take one of my memory streams, I still need to create an adapter for each type of editor that I'd like to support.
It looks like I'm not the first person to run into this issue.
A year ago, someone by the name of Hallvard Traetteberg was trying the same goal with a different approach... He was trying to whip up his own DocumentProvider:
http://www.eclipse.org/forums/index.php?t=msg&th=155348& amp;start=0&
The thread ends with the issue unresolved. Not very encouraging.
--Mark Storer
Senior Software Engineer
Autonomy Cardiff
import legalese.disclaimer;
Disclaimer<Cardiff> disCard = null;
Google Code Search
[Updated on: Thu, 08 July 2010 20:57] Report message to a moderator
|
|
|
Powered by
FUDForum. Page generated in 0.03170 seconds