Thanks to Darrell Walisser for the outline of the problem, which was causing laggy dragging of stereo track sizes in spectrogram view.
This was caused by refreshing the horizontal ruler unnecessarily.
The Ctrl-Z was interrupting the enveloping, making it finish, but it then got asked to finish again on a mouse up. This change stops the second finish from happening.
Previously Ctrl Click on Wave behaved exactly as Ctrl Click on Track Control Panel. With this change on wave it
(a) No longer toggles. It only adds.
(b) It will extend and can be drag extended.
It is possible to change (a) to be toggle if that is desired.
This should ease the creation and extension of discontinuous track selections.
It turns out that having fixed the behaviour of Shift-Click on the Track Control Panel, I'd also fixed the behaviour of Shift-Click on the wave. But then I blew it by over riding the Shift-Click behaviour on wave to use the version that does NOT horizontally extend. This change comments out the 'bShift' and so gives us the original Shift-Click behaviour on wave, without undoing the other fixes.
I first of all added a warning message if trying to configure while playing.
Then decided that it is more in keeping with current style to grey out the Spectrogram Settings menu item.
So the new warning message should actually never be reached.
... 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.
Problem was that cfd7648fce2388ec8ae35b38004f2ae111c484af fixed a memory leak
but created a dangling pointer bug, which does not happen during usual run
of Audacity because AudacityProject::OnCloseWindow is reached then before
destroying AudacityProject.
Fixed it by using a std::shared_pointer for the TrackList that both
AudacityProject and TrackPanel must use.
The function builds pop up menus that are never displayed and
creates runtime debug warnings. It is left over from PRL's experiment
in 2.1.2 with a context menu for the vertical ruler.
... See comments #1 and #2 at
http://bugzilla.audacityteam.org/show_bug.cgi?id=1331
Don't make strange undo history if, e.g., R to record (or other keystroke
with undoable effects) interrupts a drag with undoable effects (like time
shift). Ensure that by first simulating a mouse button up event to stop the
drag, before dispatching the keystroke.
Don't crash if certain other drags, that do not have undoable effects, such
as selection or vertical ruler drag -- are interrupted by a keystroke
command (Ctrl+C in particular could cause crash). However, in these cases,
the drag is still allowed to continue.
