Fixes the following bug: if the zoom level is such that the jump does not cause a visible
change in display of the tracks, then the selection in the selection bar, and the play
region are not updated.
The fix simply moves the location of the call to TP_DisplaySelection(), so that it is called
irrespective of whether the tracks are redrawn.
... Start scrub by click or double click on the scrub head; release button or
not; then move.
If you release before moving, you get scrubbing as before, controlled by
motion. Click or drag to switch in and out of seeking. Stop with ESC,
spacebar, etc. No change of selection.
But now if you drag, then scrubbing contines until you release the mouse or
otherwise stop with a key.
If by release of the mouse, then the selection changes as if by a click at
the last play position. If you hold shift, then, as if by shift-click.
If drag begins with a double-click, then the play head remains centered and
the track moves.
... This affects those keys (and NUMPAD arrows), also (shift-)ctrl-f6,
ctrl-home, ctrl-end (which are command-left and right on mac)
Those should be tested to ensure correct restoration of the yellow rectangle,
appropriately in the tracks or the ruler.
This should also be tested with and without the Tracks preference for cyclic
movement of the focus.
... This includes new always-seeking modes unlike scrubbing which can switch
to seeking and back according to the left mouse button state.
The reason for this is that visually impaired users should not be required to
click with the mouse in the track panel window to signal seeking. But mouse
movements can still control scrubbing, because we poll the global mouse
position in the timer, not relying on events from any window object.
* Disk space warning if the recording potentially will not fit in disk space available.
* ProgressDialog enhancements that allow the Stop/Cancel button to be confirmed and the elapsed time to be hidden.
* Messages enhanced to clearly show the actions being taken.
... for functions in final classes.
override is like const -- it's not necessary, but it helps the compiler to
catch mistakes.
There may be some overriding functions not explicitly declared virtual and I did
not identify such cases, in which I might also add override.
... Should have no effect on generated code, except perhaps some slight faster
virtual function calls. Mostly useful as documentation of design intent.
Tried to mark every one of our classes that inherits from another, or is a
base for others, or has abstract virtual functions, and a few others besides.