This is part 1...
Provides some relief to the selection "hang"
This patch adds the ability for the keyboard based commands (like cursor left,
extend selection right, etc.) to know when the key has been released.
When the patch is applied the current state is saved only when the key is
released and not every time it repeats.
Here's an example of the difference it makes.
This video show the selection "hang", but also watch the CPU usage. All I'm
doing is pressing SHIFT+RIGHT ARROW.
http://youtu.be/tdMntDwGSkM
This one is the same thing bug with the patch applied. Notice that the
selection "hang" no longer occurs and look at the CPU usage!
http://youtu.be/EpXNsQ4Cky0
research into why that code had been ifdef'd in the first place and allowed
the root cause to be identified.
Now the menus are cleaned up properly, which also fixes bug #458 without
having the workaround in r12639.
Basically, the problem was that attempts were being made to manipulate
menuitems on a menu that no longer existed (after the menus were rebuilt).
One tricky aspect was that until GetActiveProject() is ready to return non-NULL, ControlToolBar::RegenerateToolsTooltips() cannot get the project's CommandManager, so cannot get the shortcuts. Changed ControlToolBar::RegenerateToolsTooltips() to be public and now call it late in wAudacityProject(). When called before the project is completely instantiated, in the rewritten ControlToolBar::RegenerateToolsTooltips(), it just sets the tooltips to the names without the keys, pretty much as now -- but I don't think users will ever see that because of the subsequent call.
Anyway, did it in a more programmatic way than the previous code, which reduces string literals duplication.
Btw, I changed the start value for the ID_PLAY_BUTTON because the former value of 0 causes FindWindow() to return the toolbar rather than the button -- wxWidgets bug.
Also got rid of some cruft and applied a few WXUNUSED.
