Community
Participate
Working Groups
The text editor Save behavior seems different from the 3.6 seems... I am not sure if this is working as designed or a bug. 1 difference is that you can type into the editor while the save is being performed. For editors like the mine and possibly the Java editor, which allow you to configure "Save Actions", this means that the editor contents can be modified while the Save Actions are being applied to the document... I'm guessing this can cause issues... I know it can cause issues in editors I have developed which apply Save Actions right to the editor document... Also, the cancel button in the progress display is no longer visible. For example, if the Java Save Actions were taking a long time, you used to be able to cancel the save. (Not sure it worked in 3.6 because I'm not sure the UI thread listened to events, but it was there, and i made use of it in my editor) I am opening this defect because I also have editors which use Save Actions and I need to determine how to resolve the above issues. Some of the differences seem better... in 3.6, i am not sure the progress bar repainted or if clicking on the button was heard by anyone because the save was running in the UI thread... But i have issues due to the new responsiveness of text editors during the save and need to know whether this is a bug or if i need to re-code my save actions
I'm sorry, but I cannot reproduce this behavior using 4.2.2. I even tried to make a JDT save action take very long, but this blocks the UI. If you see this in the Text or Java editor, then please provide steps, so that we can take a closer look.
.
So i can definitely reproduce this on Version: 4.3.0 Build id: I20130319-1000 for Windows 64 using the Java Editor on a very large file with wildly different formatting options. I don't see any corruption occurring due to editing the file while it is being formatted as part of the save, but you can definitely insert a few characters into the editor while the save is progressing. This is happening even though there is a busyCursor higher up in the stack because the EventLoopProgressMonitor is processing events. Maybe its always been this way... this is not a big deal to me because I can alter my editors to setEditable to false temporarily on the styled text widget, but wanted to bring it up for completenesses sake. But the absence of the Cancel button on the Status Line is persistent for me on this build... that would be nice to have working. It looks like the calls to the statuslinemanager to toggle the visibility of the button are coming thru ok, but its not rendering the button for some reason.
Created attachment 228738 [details] Cancel Button Missing
(In reply to comment #3) Thanks for insisting Jeremy! I can now reproduce both problems. They are independent from each other, and the missing button issue does not always happen (depends on how old the workspace is. I filed bug 404013 and bug 404016 to track those two non-JDT related issues.
