Easily find issues by searching: #<Issue ID>
Example: #1832
Easily find members by searching in: <username>, <first name> and <last name>.
Example: Search smith, will return results smith and adamsmith
Because of the new Vincaed, we need to create a new instance of an editor when we open a file, or save a file. When we do this, we do not migrate the Editor.document.properties. We store state in the document properties. This causes problems in the Query window. Auto-completion is broken. I don't know the full impact.
When we create an editor we pass it a file as in :
PaneFactory.getDefault().createNBEditorPane(pane, mime, file);
If we do a SaveAs, and we don't re-instantiate, how do we tell the current editor of the new file? Do do this ...
doc.putProperty(FILE, { file || null );
Is that enough?
When we create an editor we pass it a file as in :
PaneFactory.getDefault().createNBEditorPane(pane, mime, file);
If we do a SaveAs, and we don't re-instantiate, how do we tell the current editor of the new file? Do do this ...
doc.putProperty(FILE, { file || null );
Is that enough?
The DataSystems API re-enabled in Vincaed3 has these associations ( 1-1 relation ):
File <-> FileObject <-> DataObject <-> editor
and it is stuck to it, i.e. the File (and thus the FileObject , DataObject instances) cannot be changed without raising exceptions, side effects etc.
Seeing this limitation and that this approach was not suitable for ADS requirements for an editor, we've tweaked the editor pane instantiation (some releases ago) such that an empty in-memory FileObject is associated to the editor and thus it is no more stuck to the initial File instance. This in-memory FileObject instance never changes. The editor only know the File (on disk etc) instance as a document property, and it is used only for versioning files and displaying the inline diff sidebars.
I understand that you need to keep the editor instance such that the Query Analyzer states stored as document properties are not lost. You can remove the editor pane memory releasing, re-instantiation and GUI replacement and only keep the .setText(); and VersioningCache.setBase(JEditorPane comp, File original, File base); calls, which will assign the new original File reference as document property and use it when needed for versioning. I mean the .setBase() call above will establish the new JEditorPane <-> File loose-coupled association (required by versioning module) via the File original parameter.
The DataSystems API re-enabled in Vincaed3 has these associations ( 1-1 relation ):
File <-> FileObject <-> DataObject <-> editor
and it is stuck to it, i.e. the File (and thus the FileObject , DataObject instances) cannot be changed without raising exceptions, side effects etc.
Seeing this limitation and that this approach was not suitable for ADS requirements for an editor, we've tweaked the editor pane instantiation (some releases ago) such that an empty in-memory FileObject is associated to the editor and thus it is no more stuck to the initial File instance. This in-memory FileObject instance never changes. The editor only know the File (on disk etc) instance as a document property, and it is used only for versioning files and displaying the inline diff sidebars.
I understand that you need to keep the editor instance such that the Query Analyzer states stored as document properties are not lost. You can remove the editor pane memory releasing, re-instantiation and GUI replacement and only keep the .setText(); and VersioningCache.setBase(JEditorPane comp, File original, File base); calls, which will assign the new original File reference as document property and use it when needed for versioning. I mean the .setBase() call above will establish the new JEditorPane <-> File loose-coupled association (required by versioning module) via the File original parameter.
This sounds good, but there is no new file associated to Versioning, so how do I call .setBase? ...
VersioningCache.setBase(comp, original, null)
VersioningCache.setBase(comp, null, null)
This sounds good, but there is no new file associated to Versioning, so how do I call .setBase? ...
VersioningCache.setBase(comp, original, null)
VersioningCache.setBase(comp, null, null)
That's right, that are the required calls. I have to check that the Inline Diff Sidebar corresponding to the old file does not remain visible after the VersioningCache.setBase(comp, null, null) call (i.e. in the case when New action is triggered).
That's right, that are the required calls. I have to check that the Inline Diff Sidebar corresponding to the old file does not remain visible after the VersioningCache.setBase(comp, null, null) call (i.e. in the case when New action is triggered).
A call to : VersioningCache.setBase(_theTextArea, null, null); did not work.
I am sending you rc-21 and corresponding CEditorPanelView.java for review.
A call to : VersioningCache.setBase(_theTextArea, null, null); did not work.
I am sending you rc-21 and corresponding CEditorPanelView.java for review.
Fixed this particular case (issue #7685).
Fixed this particular case (issue #7685).
This was replaced by #7685
This was replaced by #7685
Issue #7680 |
| Closed |
| Fixed |
| Resolved |
Completion |
| No due date |
| No fixed build |
| No time estimate |
1 issue link |
relates to #7685
Issue #7685editor -> ALL -> New [Ctrl+N] -> doesn't detached from loaded file |