Community
Participate
Working Groups
If the action handlers provided their progress monitor and runnable context in the uiInfo adaptable, then operation approver clients could use the same progress monitor or runnable context when approving an operation, rather than creating one themselves. Specifically, this would let the undo/redo action handlers share a progress monitor with AdvancedValidationUserApprover.
released to HEAD. Should appear in 20050509 4pm EDT build.
Backing out this change. It goes against the spec for ProgressMonitorDialog, which does not support reusing the dialog for runnables. This would be a nice enhancement for the future. See bug #94166.
Consider using subtasks in the future? Simply reusing the dialog doesn't help because the operation approver's work is nested inside the running of the action handler.
Discussed problem with Tod. Ideally a SubProgressMonitor could be used, but the current implementation provided by the runtime plug-in assumes that the creator of a SubProgressMonitor knows how many ticks in the parent the sub monitor will use. This is not the case. In fact, it's not even clear how many sub monitors would be used (for example, if there were multiple operation approvers each using the monitor for something different). Further, the operation approvers run before the operation is ever given the monitor, so there hasn't even been a total number of ticks established. The dialog used for this scenario will need to be smarter. I'll update bug #94166 with new info.
Notes for the future: Consider a dialog whose monitor could handle multiple begin task/tick/done sequences, creating a new sub progress monitor each time, so that each client could treat the monitor as if it were brand new. It would seem we'd still have to guess about the total number of ticks needed...
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
