|
Re: CompareEditorInput setDirty difference between eclipse 3.2 and 3.3 [message #328967 is a reply to message #328960] |
Mon, 09 June 2008 13:55 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Michael Valenta![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=eclipsemfv%40gmail.com) Messages: 35 Registered: July 2009 |
Member |
|
|
Jan,
There were changes made in that area in 3.3. However, I don't see the
relationship between the setDirty(Object, boolean) method and the nodes
you are referring to. The purpose of the setDirty method(s) on
CompareEditorInput is to track the dirty state of the editor and, as
such, only has two states (dirty and notdirty) and only fires events
when that state changes. It sounds like, in 3.2, the compare editor
input was firing additional events, even if the state didn't change and
the structured diff viewer you are referring to was relying on those
events to update its decoration.
Part of the work in 3.3 was to add support for the use of file buffers
(i.e. shared documents) to compare. With this support, both the
structured viewer and the merge viewer can use the same underlying
document and the structured viewer can update its state properly by
listening to changes to the document. This is mentioned in the ISV doc at
http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse. platform.doc.isv/guide/compare_structureviewer.htm
The last paragraph mentions the abstract StructureCreator superclass
which has built in support for shared documents.
Michael
Jan Mauersberger wrote:
> Hi,
> it seems that there was a change in the
> CompareEditorInput.setDirty(Object,boolean) implementation from 3.2 to
> 3.3. As a result only the first node in the structured diff viewer is
> "rendered" dirty (i.e. <Node>) after some text merge was done in the
> lower pane. Every subsequent text merge on a different node does not
> mark the node dirty. It seems that the code change only fires a property
> change (which results in showing the nod dirty?) if the editor input
> isn't dirty yet.
>
> Does anyone know why this change was introduced and how I can further
> show all dirty nodes dirty?
>
> Thanks in advance,
> Jan
|
|
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.24766 seconds