[wingide-users] Suggestion: Breakpoint button behavior

Graham Wideman initcontact at grahamwideman.com
Sat Nov 23 22:59:25 MST 2013


Mostly for Wingware support:

This is a relatively subsidiary issue, but while debugging it's a repeating irritant. I thought I'd report it to the list to see if others concur, or maybe see something different.

The issue is with the way the toolbar debug buttons appear and disappear during debugging phases. The general complaint is that rather than simply greying out the inapplicable buttons, instead they disappear and the remaining ones move left to close up the space.

This entirely defeats the ability to hit the buttons based on their position. In some cases the buttons disappear and rearrange *while in the process* of hitting a sequence of them. 

For example, when the Run indicator is paused on a breakpoint, after making a minor edit I might hit the debug "Stop" button, after which I often want to hit the Run button. 

However, after hitting Stop, while moving over to hit Run, the toolbar goes through two repaints, in which the Breakpoint button disappears, the remaining buttons shift left (modifying my targeting of the mouse toward the shifted Run button) and then as I approach the shifted Run button, the Breakpoint button reappears at the Run button location, shifting the Run button right. If I'm not anticipating this I end up hitting the Breakpoint button that has just replaced the Run button.  Grrrr.

What I would favor is this: If I've elected to make the Debug buttons visible (Toolbar prefs) then make all the debug buttons visible continuously. If some are temporarily inapplicable then grey them out, don't delete them.

My settings are:

Windows 7-64
Wing 5.0.0-1 (rev 30231)
Toolbar size: Auto
Toolbar stype: Adjust for size
Groups shown: File ops, Clipboard, Search, Debug, Bookmarks

Thanks!

-- Graham



More information about the wingide-users mailing list