Community
Participate
Working Groups
RC1 - lock workspace in background operation - open project properties - select Builders - uncheck Java Builder - press OK observe: nothing happens. There should be a blocking dialog informing me about the conflict with the background operation. What is dangerous in this scenario is the fact that I can cancel the dialog and starting another operation which basically stacks operations.
Same behaviour when adding a JRE to the list of installed JREs via Preferences- >Java->Installed JREs.
These are two different bugs. The JRE update uses the progress service, so I'm not sure what the problem is there... I will open a new bug for this. This one belongs in Ant.
According to Erich this might be a workspace problem. I see the same behaviour with User libraries. When I cancel the dialog after I have pressed OK (yes that's possible) then the blocking dialog appears.
I added this related bug to JDT-Debug (please verify steps) - bug 64937
The code is calling PlatformUI.getWorkbench().getProgressService ().busyCursorWhile() which is the correct thing to do. Need to track down why busyCursorWhile() doesn't show the progress dialog. Don't change your code until we understand the issue with busyCursorWhile()
oops - my previous comment should have be assigned to bug# 64937 (will add it there as well) - sorry
Erich in your spare time :-) could you please direct me to what would be the appropriate use of the progress service in this case? I would assume busyCursorWhile() but that will not give the user any dialog as we are already in a modal situation. Thanks
OK - there are actual 3 problems you have to solve: 1) make sure that the progress monitor is passed through from the properties dialog down to each call. From the stack traces I've seen I saw several occasions where the progress monitor got "lost" and then a null progress monitor got passed down. 2) make sure that you can run with forked=true 3) create an initial runnable context from the Properties dialog when starting the operation. IProgressService.busyCursorWhile() is the best way to do so. I'm still optimistic that this will be possible (see bug# 64937). For now you can verify that the progress monitor is properly passed around you can run the runnable by using an old ProgressMonitorDialog. It will not have all the desired characteristics of busyCursorWhile() (appears with a delay, can report blockage). Actually IProgressService.run(true, false, runnable) should also work, but I haven't verified it.
Kevin I will attach a patch for BuilderPropertyPage. Could you review it and give me any feedback, thanks.
Created attachment 11838 [details] Patch for BuilderPropertyPage
DarinS. Are you seeing the ProgressDialog? When I lock the work space for 1 min, then remove the builder, I see the busy cursor until my background job is finished. This is the same behaviour that I am seeing when the default JRE is changed (see bug 65504).
Kevin is right - we are blocking on a syncExec in the UIThread. Bug 66429 has a patch that fixes this - I would appreciate it if you tested against your case before I release it.
Tod, what would we need from head to test this out...please list all the dependant plugins.
org.eclipse.ui.workbench was all I needed.
All you need is the workbench from HEAD. Kevin is right (I am saying that a lot lately <grin>!)
Tod, with bug 66429 closed what bug describes that fix that will make this work?
This is the one. You should look out for a couple of things 1) I can't report blockage on anything without a monitor. Any operation that can be blocked needs a monitor sent to it. If it is API then run it in a UserJob so at least you can lock out the UI 2) Try to not open multiple dialogs for a series of different code paths. Creating user jobs and then doing a busyCursorWhile will likely block one of them.
With the changes I have made you can no longer get into the state Dirk described but we cannot always present a blocking dialog (see bug 66591) but will always at least present a busy cursor. Decreasing severity to normal.
Changes to BuilderPropertyPage and ExternalToolsUIMessages.
Any further improvements would require changes in API methods to take a progress monitor. These will be addressed post 3.0 and via other bug reports such as bug 66591
Please verify Kevin.
verified, DarinS please update build notes
Thanks. Build notes updated.
