Community
Participate
Working Groups
Plug-in export (JDT HEAD + JDT Core v_532c) for I20050125-0800 1. Open a CU 2. Move the CU from to package anotherPack ==> CU in editor is now dirty but should be saved Works when using jdtcore.jar from last I-build. Marking as major since I don't know which other side-effects this might have.
Looks like the file is saved (if you revert the editor, the content doesn't change). It is just marked as dirty. But I don't know why. Dani, how does the editor find out it is dirty ?
This is done via IFileBuffer. If you commit a buffer it sets the dirty state (IFileBuffer.isDirty()) to false and notifies all listeners (includes editors) via TextFileBufferManager.fireDirtyStateChanged(...). Do you no longer call commit(...) and just save the file on disk? Let me know if I can help to track it down.
*** Bug 83686 has been marked as a duplicate of this bug. ***
Thanks for helping. It looks like we never called commit (even in previous builds) while doing a move. We just move the file, update its contents and fire the right delta. However we used to not do any side effect on the IDocument. We do now since we use the IDocument to do the code manipulation. I'll see if I can use a new IDocument instead, unless you prefer this solution.
>unless you prefer this solution. No, because the refactoring currently wants the file to be in a saved state. It would look strange (at least to me) to have it unsaved afterwards.
Changed CopyResourceElementsOperation to do the side effect only on the IDocument of the destionation cu. Added regression test CopyMoveResourceTests#testWorkingCopy2()
*** Bug 83861 has been marked as a duplicate of this bug. ***
Verified in I20050214-0927
