Community
Participate
Working Groups
Build Identifier: I20100608-0911 I have a usage scenario to distingush between user clicking on the breakpoint checkbox and programatic change. I would like to request for such a feature and will be able to create a patch if this request is acceptable by the platform team. Reproducible: Always
Hi Patrick, Could you give more details? Are there any common use cases for this feature?
Hi Pawel, Here is my main use case: When the user press the checkbox in the breakpoint view, if it failed to enabled in the backend due to resource conflict, than I need to pop up a dialog with reason why it failed to enable (plant). In another case, if the breakpoint enablement change that is not cause by the user, and it failed to enable than I don't want to pop up the dialog. -Patrick
In what cases are breakpoints enabled programmatically? Scripts?
(In reply to comment #3) > In what cases are breakpoints enabled programmatically? Scripts? Yes, we have script to enable/disable breakpoint. It also can be from a breakpoint with action to enable another group of breakpoint, but symbol is not valid and breakpoint fails to enable.
Can't the client keep track of this on it's own? i.e. the client that is programmatically toggling breakpoints keeps track of which ones and can determine whether or not a message should be displayed. From an API point of view it feels awkward to have two notifications for the same thing.
(In reply to comment #5) > Can't the client keep track of this on it's own? I have to supports multiple clients. One client sets the enable attribute of a breakpoint, this generates breakpoint changed event notification, the second client is not aware whether this is from the UI or not. It is nice to have a common way to tell whether changes are from the user or not, and breakpoint manager client can make decision whether to prompt or not. With this common bit of information, breakpoint manager clients can be unaware of each other.
I don't think there should be a special API/notifcation mechanism for this. There should be a uniform API for toggling breakpoints and notifying. Most clients need to programmatically toggle breakpoints to simulate the same behavior as the user toggling. I would suggest to add a special attribute to your breakpoints for this - set an attribute that says "don't prompt". Otherwise every client has to be aware of the special API for toggling.
I'm not sure I have anything else to add. It would help me to understand the request if I knew what is the specific use case you're trying to solve. A programmatic action to enable breakpoints could mean a lot of things. In Wind River's debugger we do have a programmatic changes to breakpoints. They are triggered by another client to the debugger back end (a command line interface) which changes the installed breakpoint. This change then needs to be reflected in the GUI. But I suspect you have a very different use case.
(In reply to comment #8) > A programmatic action to enable breakpoints could mean a lot of things. > In Wind River's debugger we do have a programmatic changes to breakpoints. > They are triggered by another client to the debugger back end (a command line > interface) which changes the installed breakpoint. This change then needs to > be reflected in the GUI. But I suspect you have a very different use case. This is the same as one of my use case. We also have a command line, scripting interface that can change the debugger state and needs to be reflected in the UI.
(In reply to comment #9) > This is the same as one of my use case. We also have a command line, scripting > interface that can change the debugger state and needs to be reflected in the > UI. So now I'm very curious how you were planning to go about some of the problematic work flows. Here's our biggest problem: User has a breakpoint planted on a target. The target is powered down and at this point our debugger engine cannot modify the breakpoint (either disable, enable, etc., or even remove it). If user tries to remove the breakpoint, we attempt to remove it from the target and if that fails, we re-create the breakpoint in the IDE. In case where the BP applied to multiple target, the recreated breakpoint is configured so that it only applies to the target(s) that failed to remove the breakpoint. However, it gets more complicated if the user modified a breakpoint (e.g. disabled/enabled). In this case, we don't simply change the breakpoint back to what it was before because that could possibly lead to some kind of recursive cycle between targets changing the breakpoint back and forth. Instead we leave the changed breakpoint with an error attached, and create another breakpoint with the old attributes. Unfortunately, this is really confusing to users. I think that if there is something we should do here in the platform, it would be to make it possible to make a breakpoint change somehow conditional on feedback from breakpoint listeners. I.e. breakpoint manager call listeners with a breakpoint change notification and at the same time collect status from the listeners on the validity of the change. The feedback would then be routed back to the client making the change so that it could revert the breakpoint changes.
We have the same problem, while target is in a state that is not possible to make change to the breakpoint, we do the following. 1. enable/disable breakpoint is not allowed, clicking on the checkbox will not change the state. This was possible in the new flexible breakpoint view, where is not not possible in the old view. I would like to see support from platform to be able to grayed out checkbox item for better feedback. 2. Modify breakpoint is not possible. In my case, I completely disabled the property page dialog. User can browse the breakpoint properties, but it is not possible to make change. 3. Remove/Remove All/Skip Breakpoints will failed, I have to cache these requests in the breakpoint service and reapply the requests when possible and a dialog with error message is prompt to the user. This is a way for me to workaround the issue, not to be able to disable breakpoint actions in the platform breakpoint manager. I have filed a bugzilla to have the ability to consolidate breakpoint manager listerns to control the state of the breakpoint manager toolbar actions. In our current eclipse product, I have make changes to the platform code to have these action disabled by polling the breakpoint manager listener for the state. As you have already discovered, trying to maintain a consistent state between the target and the UI is difficult, there are complications how to manage breakpoint change notification. Recursive breakpoint change notification is unavoidable, I have to workaround by setting flags to stop the recursive change notification.
I like your approach to the problem, sounds more user friendly than ours. As far as this request, could you have a second method: setEnabledByScript() and use internal flags in the breakpoint to distinguish between the two? I don't think there's any special value in introducing an API at platform level for this because we can't change actions and scripts that are out there to use new the new method. I.e. even if we changed the IBreakpoint.setEnabled() method javadoc to say: only call in response to UI event, we'd be breaking an API contract.
