Community
Participate
Working Groups
Clone of bug #528134 to report the fix in EEF 2.0.x. Steps to reproduce (in a Sirius context as it is easier, but the issue is not Sirius-specific): 1. Open a Sirius diagram which provides EEF-based properties view, and select an element which provides an editable text field (most obvious case: select an EClass in EcoreTools and use it's Name field). Say the class is named "A" initially, and thus the text field displays "A". 2. Launch a background job/thread which waits a few seconds and then renames "A" into "A2". I'll attach a patch to the Sirius Debugging View which provides buttons to launch such actions for testing. 3. While the job is waiting, start to edit the text field, for example into "A3". DO NOT VALIDATE YOUR EDITION. 4. When the background job finally performs the model change, the value being edited ("A3") is lost and unconditionally replaced with the new value computed from the new model state, "A2" => KO. The example is a little contrived and simplified, but there are concrete scenarios where the resulting behavior is very bad: in particular when the user was editing a multi-line text field, which can take some time, and some background process (for example synchronization with remote changes) overwrites everything he had written with no chance at all to get it back.
New Gerrit change created: https://git.eclipse.org/r/114462
Gerrit change https://git.eclipse.org/r/114462 was merged to [master]. Commit: http://git.eclipse.org/c/eef/org.eclipse.eef.git/commit/?id=4f353e1fe5d96da0d32b052ce008d2355f44703c
New Gerrit change created: https://git.eclipse.org/r/115394
(In reply to Eclipse Genie from comment #3) > New Gerrit change created: https://git.eclipse.org/r/115394 This new patch is for a different, but related case, where: * the user selects and element E; * in its properties view, it starts editing one of E's text properties by typing inside a text widget; * before the user has validated his change (at this time, the new text only exists in the SWT widget), some background job takes a lock on element E; * this lock triggers an update of all the properties widgets to make them read-only (and display a lock); * at this point, the user can neither continue typing nor recover the text he was in the process of editing. The proposed patch detects the situation where a lock it taken while the user is in the process of editing the text, and in this case opens a dialog box which a) explains the situation, and b) offers to copy the text into the system clipboard before it is lost. It's not very satisfying in terms of user interaction but for now I have not found a better way.
Gerrit change https://git.eclipse.org/r/115394 was merged to [master]. Commit: http://git.eclipse.org/c/eef/org.eclipse.eef.git/commit/?id=0404d254e5e6fda22b6909957a5d6706ee24c270
Fixed by 0404d254e5e6fda22b6909957a5d6706ee24c270.
EEFTextLifecycleManager_textLossByLocking_message should be used as message and not the title in plugins/org.eclipse.eef.ide.ui/src/org/eclipse/eef/ide/ui/internal/widgets/EEFTextLifecycleManager.java Line 514
New Gerrit change created: https://git.eclipse.org/r/116430
Gerrit change https://git.eclipse.org/r/116430 was merged to [master]. Commit: http://git.eclipse.org/c/eef/org.eclipse.eef.git/commit/?id=4f2fc626123f8273bbee3911b79637b96611e7e1
Validated with Sirius 5.1.1
New Gerrit change created: https://git.eclipse.org/r/116623
