... as a preparation for splitting up class AudacityProject.
Use ProjectWindow as an alias for AudacityProject, and fetch it from the
project with a static member function, where certain of its services are used;
pretending they are not the same class.
Use global accessor functions to get wxFrame from the project where only
wxFrame's member functions are needed, so there will be less dependency on
ProjectWindow when it becomes a distinct class.
... Unnecessary because transitively included.
But each .cpp file still includes its own .h file near the top to ensure
that it compiles indenendently, even if it is reincluded transitively later.
... except Audacity.h
This forces us to make each header contain all forward declarations or nested
headers that it requires, rather than depend on context.
... except Audacity.h; and in no others.
Do so even if Experimental.h gets multiply included, as in both the .h and
.cpp files.
This makes it easier to do a text scan to be sure there are no unintended quiet
changes of meaning because of omission of Experimental.h when the flag is
an enabled one.
Also move inclusions of Experimental.h earlier.
Also don't require Experimental.h to be preceded by Audacity.h to define
EXPERIMENTAL_MIDI_OUT correctly.
... it's either the source of the connection that is being destroyed, or other
object (such as an ancestor window) transitively owning it and so causing it to
be destroyed too;
or, the sink is being destroyed, and that sink is a wxEvtHandler (which is
always so for Disconnect, though not for Unbind in case Bind was passed a
member function of a non-wxEvtHandler).
wxWidgets takes care of erasing the connection in such cases.
This removes most calls to Disconnect and Unbind. Many destructors shrank to
nothing.
Notably, in case of popup menu handling, the call to Disconnect is not removable
because the object being destroyed is neither the source nor the sink.
... Now restores state again properly and does not cause undocking of other
bars when you restart.
Redoes commit 2d56c8ec3286aa0a4a22e5be9148a2a1e01b8e17 better
This is an update to commit 516af71. The Dock key is now retained in the config file, so that if a user goes back to a version before the fix, the toolbar layout remains unchanged.
Note that when ToolManager::ReadConfig() is called, InitPreferences has already been called which has set the version keys to the current version of Audacity. Therefore the initial values of these keys are stored in AudacityApp.
Problem:
1. If a toolbar is docked and hidden, when config is written, dock is set to 0 (undocked).
2. When config is read, if a toolbar is docked, then the show field is ignored, and the toolbar is always shown.
Summary of fix:
1. Introduce a new version of the dock field (DockV2) to minimise the problems when running previous versions of Audacity, having run a version with this patch(as suggested by Paul).
2. In ToolManage::WriteConfig, for a docked toolbar which is hidden, DockV2 is set to the dock number, and not 0.
3. In ToolManager::ReadConfig, for a hidden docked toolbar in the config, the toolbar is docked, but is not included in the configuration.
Note, that if a version of Audacity without this fix is run after running a version with this fix:
1. The dock of each toolbar is reset to its default value.
2. In addition, for 2.1.3, 2.2.0 and 2.2.1 whether a toolbar is shown or hidden is reset to its default value.
- Dead code from experiments in SelectionBar removed.
- Many warnings about unused parameters fixed with WXUNUSED()
- Many warnings about signed / unsigned comparisons cleaned up.
- Several 'local variable declared but not used' warnings fixed.
This reverts commit 048c1b8c5a92e68ca9de67d25098400ab32ab68c.
I observed that it was not all right if you switch between Audacity versions, as
some cautious upgraders might do:
Delete audacity.cfg.
Open 2.2.0 and quit.
Open 2.1.3 -- and observe that the scrubbing and combined meter toolbars appear,
one over the other, at top left. Combined and separate meter toolbars are not
meant to appear at the same time.
Quit 2.1.3 and open 2.2.0. Now those two toolbars appear at some other random
seeming positions.
Summary of fix:
1. In ToolManger::WriteConfig, for a docked toolbar which is hidden, the dock number is not set to the dock number rather than 0 (undocked)
2. In ToolManger::ReadConfig, for a hidden docked toolbar in the config, the toolbar is docked, but is not included in the dock's configuration.
Works by using the newer and better logic of ToolManager for remembering which
window to focus.
It seems, at least on Windows, that when the toolbar with the focused control
is docked after the end of a docking (of itself or another bar), then focus
remains.
If the bar with the focus is undocked and another bar docks or undocks, focus
is still lost.
... Only the case that you click the grabber and release, or you drag the
toolbar ending in a docked position.
Doesn't work yet when drag ends un-docked.
Problem: On Windows 10 1703, with the Jaws screen reader running, additional paint messages are sent to Audacity compared with when Jaws is not running. My assumption is this is probably a Jaws bug. In particular, when a project is closed, ToolDock::OnPaint, and AdornedRulerPanel::OnPaint are called.
Fix: changes ensure that these OnPaint functions can be called without causing a crash.
