See first topic at http://bugzilla.audacityteam.org/show_bug.cgi?id=451#c16. Calling mTracks->Clear() with deleteTracks true resulted in data loss. Also, although a fatal error, it continued doing some project-opening tasks, i.e., GetDirManager()->FillBlockfilesCache() and setting up OD stuff, that are pointless if parse failed and all the tracks are thrown out.
Capitalized "Error Opening Project" titles -- as titles should be.
Add wxLogWarning messages to AudacityProject::OpenFile()
Fixed correction for "A linked track's partner should never itself be linked" to remove the link from the partner, not the original (left).
Fix possible NULL pointer dereference in previous commit.
I refactored the code into AudacityApp with a new timer. This is provisional pending discussion - if it is decided that it should go somewhere else I will move it.
At bottom of http://bugzilla.audacityteam.org/show_bug.cgi?id=137#c17:
> I noticed that although when we open the same project a second time with File >
> Open or File > Recent Files we show an error "is already open in another
> window", there is no block on executing the .aup from your file manager and
> opening as many copies of the project as you like. I had not done that when
> Audacity moved the files around in error the first time, but can we block this
> anyway?
This is a different bug from Bug 137, repeatable, and I think lower priority. But I went ahead and fixed it with this commit.
Also fixed previously unnoted bug where AudacityApp::MRUOpen() returned true when it actually failed to open the file. Also removed AudacityApp::OnMRUProject() cruft.
Unfortunately, it still creates a new, empty project window on Win Explorer open whereas Open and Recent Files commands do not. I think that constitutes a new, separate P5 bug.
Overall, this is another aspect of what I was talking about in http://bugzilla.audacityteam.org/show_bug.cgi?id=322#c26. Opening files vs projects got conflated for convenience, but this code is hacked in some regards, rather than being a good design, and that's why this type of bug shows up.
Fixed bug in resetting mPrevT1. That caused remaining issue noted in Bug 258 comments 2 and 3.
Moved call to UpdateMeters from TrackPanel::OnTimer() to audacityAudioCallback, where it calls gAudioIO->mOutputMeter->UpdateDisplay(), so the updates are synchronized with Meter Toolbar updates.
Removed unnecessary call to MixerBoard::UpdateMeters() in AudacityProject::UpdateMixerBoard().
Various cleanup.
Changed the bSilentlyCorrect parameter to DirManager::ProjectFSCK() to be bAutoRecoverMode. If project check errors are found during auto-recovery, it's hazardous to allow the user the various options available during normal project open. But rather than squelching the messages as well as option dialogs during auto-recover, show the messages in the log and bring up an alert.
This means the helper methods Find*() no longer need bSilentlyCorrect -- they always report to the log.
EXPERIMENTAL_LINKING -> EXPERIMENTAL_SYNC_LOCK
Restore some "border" lines in TrackInfo.
Get rid of unused DEFINE_COLOUR( clrTrackInfoSyncLockSel...).
Clean out some undocumented commented-out code. Add/remove some comments.
