Community
Participate
Working Groups
Build Identifier: HEAD After using applyAndReverse, I get from time to time dangling references. I'll attach a test case that show the problem. It seems that if you build a tree and remove a node which children have been modified, applyAndReverse will still keep modifications on those children. BUT the children are nowhere contained. Reproducible: Always
Created attachment 173842 [details] Test case v1 Sorry, there are some whitespace changes in the patch :-(
Created attachment 173860 [details] Remove changes for not contained objects This is an attempt at fixing this bug by removing changes for object that are not contained. This patch makes my previous test case pass but breaks ManualRecorderTest#testRecord1. Again sorry for the whitespace changes in the patch but it seems that the code format changed since 2008. I'm using the formatter template from HEAD.
The change recorder is properly recording the state changes and restoring them. Both n2 and n3 are dangling references in the initial state. If we didn't record their changes, then two applyAndReverse calls wouldn't produce the correct final state so undo-redo would be broken. Of course in any specific application you'd be free to filter the objects, checking for recorded changes to dangling references, and remove those from the result, but I don't think the framework should just enforce that.
Thank you Ed. Ok, it makes sense. In my case, I don't need to record such changes so I will filter them in my ChangeRecorder. Could you just have a quick look at my patch and tell me if eliminateNotContained looks good?
The condition root.eContainer() == null will necessarily always be true for the result of getRootContainer for a well formed instance. Otherwise it looks fine.
(In reply to comment #5) > The condition root.eContainer() == null will necessarily always be true for the > result of getRootContainer for a well formed instance. Otherwise it looks > fine. Thank you very much Ed.
