Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[Cdt-launch-inbox] [Bug 123997] New: launching subclasses of AbstractCLaunchDelegate causes progress information to be lost

https://bugs.eclipse.org/bugs/show_bug.cgi?id=123997 
Product/Component: CDT / cdt-launch

           Summary: launching subclasses of AbstractCLaunchDelegate causes
                    progress information to be lost
           Product: CDT
           Version: 3.1
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: cdt-launch
        AssignedTo: cdt-launch-inbox@xxxxxxxxxxx
        ReportedBy: andrew.ferguson@xxxxxxx


hi,

 I've noticed that launching my launch delegate from different routes sometimes
does not pick up the progress callback information that our code feeds into the
IProgressMonitor parameter it receives.

When launching via launch shortcuts that we provide, progress feedback is fine.
When launching via the Run/Debug buttons or shortcut keys (F10/F11) then the
feedback is ignored and the progress bar goes into indeterminate mode.

After looking into this today, I've found that the problem occurs during a call
to the ILaunchDelegate2 interface from the platform method:

   org.eclipse.debug.internal.core.LaunchConfiguration.launch(String mode,
IProgressMonitor monitor, boolean build, boolean register)

The monitor parameter used in the above method is at different times wrapped in
SubProgressMonitor's and passed into a few routines. The route through the code
I'm seeing is when its determined that a build is needed as well as a launch,
and the original monitor is split in two - one for build and one for launch.

After the build completes, the original monitor is advanced to 50% as expected.
It is then fed into a predicate routine for final launch checks, however
AbstractCLaunchDelegate provides an implementation of this routine that calls
the done() method on the IProgressMonitor when it completes. 

I believe this is the wrong thing to do with respect to the way progress
monitors are used in ILaunchDelegate2 instances. It seems that the
IProgressMonitor received by methods in that interface should be treated as the
same IProgressMonitor object over the lifetime of the ILaunchDelegate2
instance. 

thanks,
Andrew




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


Back to the top