... Now restores state again properly and does not cause undocking of other
bars when you restart.
Redoes commit 2d56c8ec3286aa0a4a22e5be9148a2a1e01b8e17 better
... Also checked more error returns from library functions. Detect it when
write fails (maybe because of exhaustion of space) -- don't continue,
pretending all is still well.
Using one non-specific error message in many places, because we're in string
freeze now.
... Problem was a wrongly implemented comparator for wxArray Sort().
The array of points was not really sorted, and results differed with repeated
calls to Sort().
Unlike with std::sort, these comparators are supposed to be trichotomous.
Problem dates to commit 7d5e54e364fcccd630274f2658703543d8c596eb
See also commit 4a500c77dda5592468f931db0c791236679157b4
... doing that only for the user-visible string, seen in the Manage>About menu
of the effect dialog and in the sorted or grouped Effect/Generate/Analyze
menus.
But don't for the string used internally and written into pluginregistry.cfg,
so that compatibility of that file is preserved.
See also commits cafbff9ff82520ff7d4344570385752869c6d230 and
c6bbe4c3dae8a52bb4b7a3c720af97bc3bd69769
... The part that checks the previously unused statusFlags argument of
audacityAudioCallback can make zero-length labels. I did provoke this into
happening repeatably on macOS using a debug build, zero buffer length in device
preferences, and a busy CPU running other programs, within just two minutes of
recording.
But close zooming in on the label, and listening, revealed nothing obviously
wrong, no click in the playback. So I consider that a false positive.
But the part of the drop-out detection that would make nonzero length
labels, because the other AudioThread is lagging in its writes to disk --
this part remains. Yet I have not yet provoked this into happening.
1) When the program detects this, insert zeroes into the recording to keep the
other good parts synchronized.
2) When recording stops, a message box alerts the user, and a label track is
added showing the lost parts, labelled with consecutive numbers.
3) A menu item visible in alpha builds only is added to Tools, to simulate
recording errors at random times and test the reporting feature.
... If you record or append-record, and do things during it that affect
the undo stack, and then complete recording -- then the last undo item will
undo the recording completely, and the other changes will belong to earlier
undo items that contain no part of the new recording.
Things that affect the undo stack during recording can include new undo items
such as movement of pan and gain sliders or adding and editing of labels
with Ctrl+M or Command+.
But such things also include certain changes of view that do not create new
undo items but rather update the most recent undo item to include that change.
Examples are change of mute or solo, resizing of tracks, changes of selection,
zooming (horizontally or vertically), switch among wave track view types, etc.
Fixing this was a rather involved project. This ought to be tested
thoroughly to be sure there are no other odd surprises in the behavior of
undo.
... in case you also do things, concurrent with the recording, that affect the
undo stack, either by pushing it (such as by changing the gain on one of the
playing tracks, or making a label) or by "Modifying state" without a new undo
item (such as when you change its size or mute or solo).
