Community
Participate
Working Groups
build I20040921 - went to set a breakpoint on Tree.releaseWidget(): - Ctrl+Shift+T, Tree - Ctrl+O, releaseWidget - Ctrl+Shift+B - wanted to see how many times this was called during shutdown - shutdown the target - the breakpoint was hit several times, making me think there was an error - it turns out that the method was only getting called once, but because the first line of releaseWidget() was a for loop, the breakpoint was being hit for each iteration (I only figured this out when I happened to see the value for i changing in the variables view) (if you're interested in more details on this debug scenario, see eclipse.platform.rcp newsgroup post: "Problem closing an RCP application") The source for Tree.releaseWidget() is: void releaseWidget () { for (int i=0; i<items.length; i++) { TreeItem item = items [i]; if (item != null && !item.isDisposed ()) { item.releaseResources (); } } ... } This happened because Ctrl+Shift+B always sets a line breakpoint. I think it would be less confusing if it set a method breakpoint if invoked when the selection is on the method signature.
Using the ruler double-click, and appropriate breakpoint is created (i.e. method vs. watchpoint vs. line breakpoint). We aren't doing the same thing for CTRL-Shift-B, as it invokes the "toggle line breakpoint" command. However, it seems like we should do the same thing.
There is an issue to be careful of with this one: when a method declaration also contains the first line of a method, we should insert a line breakpoint in favour of a method breakpoint. Similarly, when a field contains an initializer, a line breakpoint should be installed. Thus, when "toggle line breakpoint" is invoked, the line breakpoint should have first priority over watchpoints/method breakpoints.
Just curious, why would a line breakpoint be preferable in the case where the signature and first statement are on the same line?
It might be preferrable (up to the user, not sure why). However, if we hard- code the action to create only a method breakpoint in such situations, my observation is that there would be no way to create a line breakpoint, if that is what the user really wanted.
We have introduced a new interface to toggle breakpoints (any kind). We would need to introduce a new action "toggle breakpoint", and bind to Ctrl-Shift-B.
Isn't Toggle Breakpoint already bound to Ctrl+Shift+B? I use it a lot -- it's much more consistent than using the ruler due to clutter there (even with folding turned off).
It's bound to "toggle *LINE* breakpoint", we want to bind it to "toggle *SOME KIND* of breakpoint". The double-click action allows the target action to determine what kind of breakpoint to create (i.e. not specific to line, method, watchpoint...).
OK, makes sense.
Deferred. We think adding a "toggle breakpoint" action would confusing in the menu. We could bind ctrl-shift-B to the "toggle breakpoint" action, without placing it in the menu, but that is also confusing, as the key binding would not appear in any menu.
Re-opening for 3.3
Fixed. Added a new "Toggle Breakpoint" action in the Run menu bound to CTRL-Shift-B. This action uses the generic 'toggle breakpoint' adapter that clients provide or reverts to line breakpoints if clients only provider the 'toggle line breakpoint' function. This way a breakpoint of the appropriate type is created based on cursor location. The user can still create a line breakpoint specifically (for example, fields with initializer), by using the "Toggle Line Breakpoint" action specifically.
Please verify, Mike.
verified.
