I'm 100% certain I found the cause this time (r13739 was
still needed though).
There's a design flaw in wxMenuBar::RebuildAccelTable() that
will always leave the last accelerator active as they are
removed from the menus.
For the Edit menu, that will be "Move Cursor -> to Track End"
because of the way the submenus are traversed. And because that
fella happens to have an unmodified character for an accelerator
it can't be used in a label track until another menu is opened
and closed.
The workaround is to nullify the accelerator table when a menu
closes.
Per David Bailes, removing the "&" mnemonic characters also
removed the access key feedback present to screen reader
users. He also found that having the mnemonic and the
accelerators still prevented the focus from jumping to the
transport button.
I'm hoping that with wx3, we can clean this up some as it
appears they've redone the whole bitmap button design.
I couldn't handle it anymore. The darn pointer would seemingly
switch to left/right arrows whenever it felt like it...and stay
that way.
Actually, it was when it passed over the toolbar resizer when
docked. The problem was that it wouldn't change back to a normal
pointer because it didn't have the events it needed to do that.
So, I moved the resizer logic into it's own window and now the
pointer changes like it should.
As a bonus, we get a tooltip so the user will know what to do
when the pointer changes as it passes over the resizer.
Whenever a menu is NOT open, the accelerator keys are
stripped from the menu items so that the O/S doesn't even
know that accelerators are being used (we do it internally).
While this stripping was being down when the menus are set
up, it was NOT being down when the Undo and Redo menu items
were modified to include the "last action".
So, the fix is to strip the accelerator then as well.
When looking into the +morphfilter issue, I noticed that
I wasn't consistently handling preset chunks. While I
didn't have any effects complaining about it, some of it
was (near as I can deduce...this stuff isn't well documented)
probably wrong.
So, I cleaned it all up and in the process added more validity
checking when loading presets for all 3 preset formats.
Incidentially, the +morphfilter still crashes Audacity...but
it also crashes Cubase, so we're in good company. :-) I've
sent an email to the author to see if I'm setting the chunks
correctly or he has a known issue.
Removed a line in AddItem() and InsertItem() that didn't
seem to make sense (especially given the comment). However,
it caused an issue where the key assignment would persist
for one last time after leaving Preferences. It would then
act as desired.
Closing the window via the frame's close button was
not being recognized by wxWidgets. I'm sure it's
because of the of the additional event handler, but
the close event should have been sent on to the wx
handler since it wasn't handled.
No matter...just capture the event and close the
window manually.
It would crash Audacity when the initial default parameters
were saved (effGetChunk w/program) since it didn't seem to
have a default programs selected.
Fix is to simply to default to program 0 on startup.
It never really worked right on GTK and MAC, so remove all of the
specific code for them and just allow it to work on Windows until
a correct solution is found.
(GTK and MAC have their own cycling key combos anyway)
On Windows, when the button access keys were used, the focus
would jump to the associated button. This would be a real
pain for keyboard user since they would then have to TAB back
to the control they were on to make further adjustments.
By using the accelerator table instead of the normal mnemonic,
the access key isn't directly tied to the button, so focus
remains untouched.
On GTK, this actually makes the accelerators work. It seems
that normal mnemonics do not work with a wxBitmapButton, so
using the accelerator table provides the access keys.
This should correct the crash and will also correct
the problem where one project's playback/capture was
being metered in another project if multiple projects
were open.
The hairbrained "solution" I came up with in r13716
"worked" but it was simply unnecessary and this is
what I should have just done to begin with.
The previous "solution" actually caused some display
issues in the menus.
The problem is that lookup of effects is based on their
ID and legacy effects didn't play well in this scheme, so
I've added a workaround for now. This will go away when
I get all of the effects converted.
And removes some debugging.
This is more of a toleration than a fix since I can't
get any of the Waves plugins to display their custom views.
They do work in generic view however, so I've put in a
temporary hack to force all Waves plugins to use the
generic view.
This MUST be tested by everyone on as many platforms as you
have access to...reason:
This removes a very old piece of code (May 10, 2003) in the
command manager that worked around a problem in GTK where
accelerators could not be changed again after the initial
menu setup.
While there is another way to fix this bug, remove this old
code is actually a better way AS LONG AS it doesn't break
anything else. So far, it's looking like it is no longer
needed.
But, I'll be trying as many combinations of changing shortcuts,
entering/exiting preferences, swapping shortcuts, etc, as
I can on Linux, Windows and OSX.
But, the more ppl trying to break keyboard shortcuts the
better.
In case it helps, here's the comments that Dominic had in the
code:
// This is a very weird hack. Under GTK, menu labels are totally
// linked to accelerators the first time you create a menu item
// with that label and can't be changed. This causes all sorts of
// problems. As a workaround, we create each menu item with a
// made-up name (just an ID number string) but with the accelerator
// we want, then immediately change the label to the correct string.
// -DMM
When undoing not only should the capture state be checked to
see if it safe to undo, but the captured track should be
checked as well since some activities only set the captured
track and not the state.
One example is if a user tries to export a file to an invalid file or
is not permitted to write to it. For the FFmpeg, MP2, and OGG exporters
this error would not be flagged and to the user, it would look like the
file was exported.
These now throw up an error dialog to left the user know.
But, it made another issue visible...several exporters
fail silently and the user may thing the export was
successful when it was not.
Will be hitting that next.
The problem was that the mouse capture was not being reset
when the pointer left the track panel. In that case, as
long as no buttons are down, the capture state needs to be
reset so that when the mouse re-enters the track panel it
figures out what is going on from a clean slate.
