On 11/4/11 1:37 PM, Peter Klügl (Commented) (JIRA) wrote:
[
https://issues.apache.org/jira/browse/UIMA-2273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13143958#comment-13143958
]
Peter Klügl commented on UIMA-2273:
-----------------------------------
I wonder a bit about two methods:
FeatureStructureTreeContentProvider (fsview)
public void inputChanged(Viewer viewer, Object oldInput, Object newInput) {
if (oldInput != null) {
mDocument.removeChangeListener(this);
}
if (newInput == null) {
mCurrentType = null;
return;
}
mCurrentType = (Type) newInput;
mDocument.addChangeListener(this);
Display.getDefault().syncExec(new Runnable() {
public void run() {
mFSList.refresh();
}
});
}
This one gets a ICasDocument, and then just does a complete refresh, but
if I remember correctly
the combo box which contains the types must also be updated.
FeatureStructureContentProvider (editview)
public void inputChanged(final Viewer viewer, Object oldInput, Object newInput)
{
this.viewer = viewer;
if (newInput != null) {
Display.getDefault().syncExec(new Runnable() {
public void run() {
viewer.refresh();
}
});
}
}
Both methods do not contain any logic for exchanging the listener and do not
use the the document as input (needs to be set). So I guess I implement the
logic in the new casDocumentChanged method?
The later one just needs a type system and does not need to register any
listeners, because the type system cannot change,
even not when you change the CAS view. We should clean the code up to
pass this in via setInput.
Didn't we want to move casDocumentChanged to an ICasEditorListener?
There the casDocumenChanged method implementation
should call setInput, and the setInput logic should be fixed to work
properly.
Jörn
