... Because all hit tests returned all fields blank, or else, returned a
UIHandle object whose Preview method gives the rest of the information; so
the other fields were redundant.
... Rather, construct them during hit tests (also capturing more state sooner
rather than at Click time, and adding some accessors for later use)
This also fixes bug 1677 by other means and avoids similar problems.
A cell may be implemented to re-use a previously hit handle object, not yet
clicked, in a later hit test, by remembering a weak pointer, but TrackPanel
holds the strong pointers that determine when the object is destroyed.
And the objects will surely be destroyed after drag-release, or ESC key.
For now they are also destroyed whenever not dragging, and hit-testing is
re-invoked; that will be changed later, so that the re-use mentioned above
becomes effective, but still they will be destroyed when the pointer moves
from one cell to another.
... Let cell hit tests, and handle preview, know states only, not transitions.
Cell hit tests are passed a mouse state that does not always match the current,
but anticipates the button click to come; usually left, but if the Control
[sic] key on Mac is down, then right.
Thus, pressing and releasing Mac Control in multi-tool switches in and out of
the magnifier cursor.
Zoom tool takes precedence;
Otherwise do special hits appropriate to the track subclass -- and only
WaveTrack here uses Tools toolbar state, and now disallows clicks on things
when they are not drawn because the view is spectrogram;
Finally, default to right button zooming in Multi tool, or to time shift in
that tool, or to selection adjustment in Multi or in Select tool.
...no actions reimplemented to them yet.
Later commits will move special cases one at a time from TrackPanel, preserving
all click and drag capabilities at each step. With a few exceptions, but those
lost abilities are restored in yet later commits. (Ctrl+Click on the Label
track being one.)
... The return codes were mostly ignored anyway, and exceptions will be thrown
instead.
It seems there was also confusion whether the return values of Track::Paste
and Track::SyncLockAdjust were to indicate success or indicate whether there
was any change. No matter now.
A sync-lock group is a maximal sub-sequence of the tracks, containing:
one or more wave tracks (and/or Note tracks, if MIDI is enabled),
and zero or more label tracks.
(These are not exhaustive of all of the types of tracks.)
So redefine Next(), Prev(), and Last() carefully to implement this intention.
... And in some places where a library uses signed types, assert that
the reported number is not negative.
What led me to this, is that there are many places where a size_t value for
an allocation is the product of a number of channels and some other number.
... 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.
