Bug 5340 - Cancelling add exception breakpoint has no effect
Summary: Cancelling add exception breakpoint has no effect
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Debug (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows 2000
: P1 normal (vote)
Target Milestone: ---   Edit
Assignee: Darin Wright CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-10-29 14:58 EST by John Arthorne CLA
Modified: 2001-10-31 15:05 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Arthorne CLA 2001-10-29 14:58:20 EST
1) Go to the breakpoints pane in the debug perspective
2) Click the J! button to add an exception
3) In the progress dialog, click cancel. The progress dialog closes immediately
4) Eventually the exception list comes up, it ignored the cancelation request.

It should either honour the cancellation request or diable the cancel button 
(when calling ProgressMonitorDialog.run pass false for the canceleable 
parameter).
Comment 1 Darin Swanson CLA 2001-10-30 17:36:31 EST
I am not sure if this can be made more responsive, but the cancelling should be 
handled in the JobManager for the SearchEngine.
Moving to JCORE.
Comment 2 Philipe Mulet CLA 2001-10-31 07:34:23 EST
The JobManager uses the progress monitor passed into the result collector (the 
job holds onto it).

Maybe it should check more often, like when doing match locating.

However, the resultCollector.done() is called even if the operation was
canceled, is this the problem ? The collector should check at this point, if
it was canceled.
Comment 3 Philipe Mulet CLA 2001-10-31 07:47:05 EST
Back to JDT-Debug for further investigation.
Comment 4 Darin Swanson CLA 2001-10-31 12:10:58 EST
Fixed the AddExceptionDialog to honor the cancel of the progress monitor dialog.
Please verify.
Comment 5 Darin Wright CLA 2001-10-31 15:05:35 EST
Verified. The dialog still flashes (appears & disappears quickly), but that is 
the best we can do without doing some overriding of the "open" method in the 
dialog/window hierarchy. Since this is not a common case, suggest leaving the 
implementatin as is.