Community
Participate
Working Groups
Build 20020601 Open type java.lang.Object, select Object type name in editor, and hit F4. No progress is shown during hierarchy opening.
we are using the WorkbenchWindow as the runnable context and it looks like progress doesn't show up under all circumstances. We have two options: a) use a ProgressMonitorDialog as the runnable context ->when dialog has no timeout this will result in a lot of flushing. In particular on save you will see progress first in the status line and then you will see a dialog (BTW, this is also a problem with a manual build, i.e. save uses the status line and the actual build is using a progess monitor dialog) b) use the busy cursor runnable context as we did in F1 ->the draw back here is that you cannot cancel the operation Need advise from Nick what their plans are with regard to the progress monitor.
Sounds like our problem. This is a candidate for fix pass 2.
The operation is being called with: context.run(false, false, op) So the operation is not cancelable and is running in the UI thread. Recommend Search uses (true, true) and changes its code to handle being run in a non-UI thread. We should process UI events after disabling the controls but before running the operation, to at least allow the status line to relayout and show the progress bar and cancel button.
See comments above.
Erich, I'm assuming that you won't be making changes to how you call the progress monitor here. Is it still important for you that the status line progress bar handle (false, false) for 2.0?
The main motivation for using the Application windows progress monitor is to support that opening the a type hierarchy on Object becomes cancelable. As you point out the code is currently called with (false, false, op). This is not correct the operation should be cancelable, so we should call it with false, true. However, what we cannot do is to run the hierarchy refresh code always in an operation/modal context. We had tried this earlier without success. If you can handle "false, true" then we would use the support. However, if this is not possible then we can fallback to use the busy runnable context. Given that opening the hierarchy object has drastically improved (30-40s) we can consider this again.
Adam is looking into what we can do to make this work. If it's at all risky, we will have to defer though. I don't quite understand how fork=false works even the ProgressDialog case. If we're not spinning UI events, I don't see how the dialog even comes up and updates.
>I don't quite understand how fork=false works even the ProgressDialog case. I don't think we have ever done this, so this might indeed not work at all. If it is too risky to support false, true we will switch back to the F1 busyrunnable context solution.
Adam, please investigate. If we can't fix by end of Monday, JDT will have to back out of using it.
The hierarchy calculation uses the animated progress bar. In order for this to work, the event loop needs to be running. We recommend using the EventLoopProgressMonitor to wrap your progress monitor. Note that this is an internal class, so we would have to fix this problem properly post 2.0 (making EventLoopProgressMonitor API is not the right answer). If you do not want to do this, then we recommend using the busyrunnable context instead of the status line.
in this case I prefer to switch back to the busy runnable context. thanks for your investigations
Defering to post 2.0.
Reopened for investigation
Erich, Nick, Is there any work to be done here? Can I close this?
I'm not sure what we can do here. McQ, a while back you said the Mac had progress monitors in a single-threaded model, and handled this problem somehow. Could you explain how they do it?
Sorry, I'm out of the loop on this one. I'm not sure exactly what the problem is. I'm pretty sure it was Steve who was talking about the behavior of the various progress indicators on different platforms. My understanding is though, that once an indeterminate progress indicator on the mac is started, it will continue to spin without requiring application event handling until it is stopped again. The only other interesting case is that busy cursor handling is free. Essentially, if the application stops responding to events, the system puts up a busy cursor , and takes it down the next time an event is dispatched.
There are no plans for the UI team to work on this defect until higher priority items are addressed.
Also see comment in similar bug 31268 : In 2.1 world, since indexes are no longer checked for consistency eagerly during startup, search actions may trigger lazily some indexing work (rebuilding a big index will take some decent amount of time). Thus, opening a type hierarchy can enter this mode, and user gets absolutely no feedback whatsoever, it feels the IDE froze.
JDT is investigating into the type hierarchy open problem for 2.1. Having a fix for bug# 6325 would also improve the current situation (SWT is investigating on this one).
There are currently no plans to work on this feature
