Community
Participate
Working Groups
I20040121 What I did: 1) Initiated a background project tag 2) While waiting, I tried typing in an editor in a different project -> Busy "blocked by background job" dialog popped up. 3) Hit cancel in the dialog. 4) Try to edit again 5) Repeat 3-4 a few times -> Finally the background tag is done, but it still claims to be blocked. Will attach the stack. It looks like the ProgressMonitorJobsDialog is not sending the cancel through to the underlying runnable, but just closing immediately and leaving behind the waiting task. I need to investigate a bit more.
Created attachment 7589 [details] Stack trace
John we have updated this dialog in the latest integration build so cancel of the dialog is no longer possible (although you can cancel the jobs). I think this is obsolete.
What if the user really does want to cancel the foreground activity? They realize that they have tried to do something that conflicts with the background activity, so they want to back out and do something else instead while they wait for the background job to complete. We support cancelation when blocked, so I don't see a technical reason why we can't do it. We just have to get the BlockedJobsDialog cancel button to call setCanceled on the EventLoopProgressMonitor. The main thread, which is stuck waiting for a scheduling rule, checks for cancelation on the monitor while it is waiting.
The new dialog doesn't allow cancel as it is only to show blocking - i.e. there are too cases now - one where you are running an operation and one where you are reporting a block only.
I agree with having two different dialogs for these two cases, but I'm saying the "blocked" case should still support cancelation. We didn't do this correctly before (hence this bug), but it can be done. I think the "blocked" dialog needs two buttons: "Cancel selected operations" -> Cancel background jobs "Try later" -> Cancel the foreground operation. Note: I can reproduce the problem in I20040127 by closing the "blocked" dialog using the shell close button or the close action in the shell's drop down menu. Moving to UI, but I can investigate a patch if you like.
The user still has to be able to cancel the modal operation when blocked. We want to demo this next week at EclipseCon.
Suggestions implemented and released into HEAD. I will close this Bug if all of your needs have been satisified.
I'm never satisfied :)
Closing pending comments.
*** Bug 50757 has been marked as a duplicate of this bug. ***
I don't see any improvement in build 200401290841
The UI changes were not released in that build.
UI did not resubmit until 20040130
Marking closed
