Community
Participate
Working Groups
Build Identifier: 20100617-1415 I have developed a plugin which adds a new breakpoint type to the CDT. I have created an IToggleBreakpointsTargetFactory (amongst other things) but I want the Breakpoint Types popup menu to default to the regular type ("C/C++ Breakpoints" as set up by org.eclipse.cdt.debug.internal.ui.actions.ToggleCBreakpointsTargetFactory). In figuring out what's going on I have come across a problem. Early on in the workbench startup, org.eclipse.debug.internal.ui.actions.ToggleBreakpointsTargetManager.chooseToggleTargetIDInSet() is called to figure out what the default type should be. It calls all the target factories it can find - including mine and CDT's. CDT's ToggleCBreakpointsTargetFactory.getDefaultToggleTarget() has some logic which only returns an ID if the currently selected context is a CDT element; otherwise it returns null (signifying "no preference"). Unfortunately this is being called before the workbench has opened, so (at the time it counts) it always returns null. If you have another factory in there - like I do - which clones the code from ToggleCBreakpointsTargetFactory, the same logic causes it to also return null when it is first called. This causes the ToggleBreakpointsTargetManager to arbitrarily pick the first target factory in its list as the default - in my case, mine! - and remembers it as the default until such time as the user picks a different one. I've worked around the issue by having my plugin always return ToggleCBreakpointsTargetFactory.TOGGLE_C_BREAKPOINT_TARGET_ID. Nevertheless there's obviously a bug here, albeit a minor one. Either the logic in ToggleCBreakpointsTargetFactory which doesn't return a preference if the C Breakpoints Model isn't active is bogus, or the ToggleBreakpointsTargetManager is attempting to set up its preferences at an inappropriate time. (Therefore, this may turn out to be a bug in org.eclipse.debug.ui, rather than cdt.debug.ui.) Reproducible: Always
Created attachment 180076 [details] suggested change I'm no expert here, but looking at ToggleBreakpointsTargetManager#chooseToggleTargetIDInSet, when the factory returns null, the first target is arbitrarily picked. I find it strange that in that case, the code still calls setPreferredTarget(). Seems like the preferred target was not really determined yet. Shouldn't the call to setPreferredTarget() only be done if the preferred target was actually returned by a factory? The patch (for the platform) shows what I'm talking about. Does that help your case?
You have a good point, I always felt that the logic for selecting the target missing something. I think your workaround is perfectly appropriate, but for Helios we could try to solve this with some new API. What if we added something like getSecondDefault(), or getFallbackDefault(), so that the standard CDT breakpoint gets chosen if there is no debugger active?
(In reply to comment #1) Thanks for the suggested patch, but it doesn't help - getDefaultToggleTarget still returns null every time. I dug deeper; every time it is called, the first line of ToggleCBreakpointsTargetFactory#getDebugContext() evaluates to TreeSelection.EMPTY ...
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. -- The automated Eclipse Genie.
Problem has not changed.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie.
