... though harmlessly so. They called to nonstatic member functions of classes
with improper this pointers; though the functions did not use this.
Bind events to nonmember funtions instead. Sometimes just to empty lambdas to
consume the event and ignore it, blocking other handlers.
... 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.
... 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.
The only call to Show for HistoryWindow is in AudacityProject::OnHistory, and it always calls HistoryWindow::UpdateDisplay. All HistoryWindow::UpdateDisplay does is check IsShown() and if so, call HistoryWindow::DoUpdate.
Removed the call to HistoryWindow::DoUpdate in the constructor because AudacityProject::OnHistory will get that done.
Removed HistoryWindow::OnShow. No reason to implement it outside the normal wxDialog::Show() mechanism, and all it did was call HistoryWindow::UpdateDisplay (and then AudacityProject::OnHistory would do that again).
Didn't see any other reasons it has been slow, as it's just getting the state names and sizes from the stack, not actually examining anything about the states. It probably doesn't really need to clear the list and repopulate it every time, but let's see if this gives sufficient improvement before adding a lot of mechanisms for tracking exactly what needs to change.
