Community
Participate
Working Groups
Build Identifier: I20100608-0911 Currently there is no API to control the enablement of the breakpoint actions/operations. For my debugger, it is not possible to change (enable/disable/skip) the breakpoint while the target is running. It would be nice to be able to control the breakpoint actions/operations. However, the API should also consider other debugger that might not be able to add/remove breakpoint. Modifing source file is a tricky one to tackle, changes might need to be cached until the target is capable to perform these operations. Reproducible: Always
This is a tough problem because for most debugger implementations any breakpoint can be installed on any number of debugger instances. So if one debugger instance disables it, it will reduce functionality for another. In our (Wind River) debugger we've solved the problem as following: - target enters state where bps can't be modified - user changes breakpoint state - debugger attempts breakpoint change, it fails - since the update breakpoint can't be installed on target, it's marked with an error - debugger re-reads breakpoints state from target to synchronize the IDE breakpoints - debugger adds an IDE breakpoint that corresponds to the target breakpoint in old state The end result is that if user tries to modify a breakpoint he ends up with an extra copy. It's neither simple nor intuitive, but at least it's correct. Fortunately the use case is rather rare. HOWEVER. For your use case you, you can simply throw a CoreException from within IBreakpoint.setEnabled(). I just gave it a try and it works, both in the editor and in BP view. Please reopen if you have something else in mind.
After reading bug 326203 I see the use case: gray out the checkboxes in Breakpoints view.
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. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
