Previous fix was at commit f9865f39efe46224a1a77c742a789b2cc70f0c54
But then that had this strange effect on Mac: when a menu command such as
rename brought up a modal dialog, then the first click in the dialog would pass
through to the tracks behind it, changing the selection, and only a repeated
click on the OK button would dismiss the dialog.
I don't know exactly why that happened. This avoids it.
... As they did with Ctrl+Shift+F, with a certain minimimum number of wave
tracks that depends on screen resolution. On my Macbook, that was 13 tracks.
This bug was a consequence of James' TCP layout changes making buttons a little
taller plus my changes to hide any top controls for which there is not
sufficient height.
The fix makes the height of tracks after Ctrl+Shift+F a bit more (44 pixels
not 40) than in 2.1.3.
This fix also replaces some more "magic numbers" with calculation from
tabled data about TCP layout.
... 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.
Call HitTest in just one place
Can now preserve repeatedly hit UIHandle objects during pre-click motion
Fields of HitTestResult besides the handle pointer are now unused
The need to repaint a track during mouse movement can be indicated when
constructing a UIHandle or when updating it for move; HitPreview no longer
does this
And the last allows simplifications of LabelTrack glyph highlighting
Also move the temporary state for label glyph dragging out of LabelTrack
... 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.
... those handles that force a simulated button-up when play interrupts drag,
and can assume that pointers to tracks remain nonNULL and part of the current
project state (not the undo history).
Also pass shared_ptr to Track into more hit test routines.
