... This makes much code agnostic about how other things (functions and
arguments) are typed.
Many of these neeed to become size_t instead of sampleCount.
This also makes it clearer in the code when we are dealing with a Toolbar ID (for the scrubbing toolbar) and when we are dealing with a button ID (for enabling/disabling the scrub ruler).
Per comments in the bug, fixed by making the pinned/unpinned button more clearly a button.
This involved adding a new type of grabber that does not have the ribs for dragging it and acts as a spacer.
Also fixing grabber so that it does not have to be at position (0,0)
Also making the ruler 1 pixel higher.
Also changing the pin button to be a toggle button that changes from up to down on a click.
Also fixing AButton so that an image can be bigger than the button.
This is using the same idiom of only capturing if not capturing already. These cases in AutoDuck, Resizing, Grabber and TQP might have been latent ASSERTs. This based on precedent rather than actual elicited buggy behaviour.
In commit 89e33da, the override of AcceptsFocus() was removed from the ToolBarResizer class so that ESC could cancel resizing. However this meant that the toolbar resizers were included in the tab traversal of the toolbars.
The fix is the same one that was used to fix the problem with the toolbar grabbers being in the tab traversal: override AcceptsFocusFromKeyboard(), rather than AcceptsFocus().
This happens on Windows 7 if the display scaling factor is set to 125% (and probably higher). This also happens on Windows 10, but only if in addition to the high scaling factor, the display scaling at high DPI is disabled on the compatibility tab of audacity.exe's properties dialog. (The behaviour on Windows 8.1 wasn't checked.) The effect of the toolbar becoming higher, is that on a row of a tooldock, no other toolbar can be in front of the Device toolbar.
In void DeviceToolBar::RepositionCombos(), the desired size of the combo boxes was set to the best size.
The fix is only use the x value of the best size, and leave the y value unchanged. Note that this may not be the only problem in the code which causes this problem, and so this problem may resurface in the future.
