| Undo of RecordingCommand is done in a strange order... [message #608576] |
Fri, 22 June 2007 18:11 |
 Michael
Messages: 43
Registered: July 2009 |
Member |
|
|
Hi.
I'm using RecordingCommand to catch changes in my EMF model and undo the=
m =
if needed. The model objects are also mapped to edit parts which hook em=
f =
change listeners into the model objects. When RecordingCommand is undone=
=
it issues that change events as undo is progressing. And i suddenly foun=
d =
that the order of events during undo of a bunch of EMF model changes is =
=
different to the reverse order of events that i receive when making thes=
e =
changes.
I've made some debugging and found that when i undo a RecordingCommand, =
it =
in turn undoes internal instance of CompositeChangeDescription.
CompositeChangeDescription contains list of ChangeDescription, being ask=
ed =
to undo it goes trough the list from the end and undoes each =
ChangeDescription.
This looks like correct unwinding of EMF changes, but surprisingly the =
list contains only one ChangeDescription that itself contains all the =
changes.
And the changes in list iside this single ChangeDescription are unwinded=
=
in the
order that is different from both strict and reverseing order of changes=
=
as they were performed before undoing... Well, maybe the resulting model=
=
will be ok after undoing all primitive changes in that other order, but =
=
the problem is that my edit part receives a notification during the undo=
=
and the model appears to be in wrong state at this moment.
Here is an example trace of the events. I have next structure from EMF =
objects:
topobject -> binding1 -> inst1 -> binding2 -> instr2 -> binding3.
Each of binding and bindingInstr objects has not-containment property =
named "type" that is set to ReferencedDesign1. ReferencedDesign1 itself =
is =
contained in a list property in the topobject. The action is to delete t=
he =
binding2 and to move it's child binding3 to bindInst1. And the action is=
=
made in signle transaction. Then the action is undone. Here are event =
lists (in format: "eventType: objectInstance.property =3D oldValue -> =
newValue):
While removing middle node:
REMOVE: instr1.bindings[0] =3D binding2 -> null
SET: binding2.parent =3D instr1 -> null
REMOVE: instr2.bindings[0] =3D binding3 -> null
ADD: instr1.bindings[0] =3D null -> binding3
SET: binding3.parent =3D instr2 -> instr1
REMOVE: binding2.instructions[0] =3D instr2 -> null
SET: instr2.type =3D ReferencedDesign1 -> null
SET: binding2.type =3D ReferencedDesign1 -> null
While undoing the remove:
SET: binding2.parent =3D null -> instr1
ADD: instr1.bindings[0] =3D null -> binding2
SET: binding3.parent =3D instr1 -> null
REMOVE: instr1.bindings[1] =3D binding3 -> null
ADD: binding2.instructions[0] =3D null -> instr2
SET: binding2.type =3D null -> ReferencedDesign1
SET: binding3.parent =3D null -> instr2
ADD: instr2.bindings[0] =3D null -> binding3
SET: instr2.type =3D null -> ReferencedDesign1
The incorrectness of undo order is obvious (binding2 on the first step o=
f =
undo is returned into containment hierarhy whereas it's type is not yet =
=
restored from null to ReferencedDesign1), please help...
PS. I'm using org.eclipse.emf.transaction_1.0.2.v200611161636.jar
-- =
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
Powered by
FUDForum. Page generated in 0.02681 seconds
] 
Search
Help
Register
Login
Home
