... Two controls were associated with the same path,
"/FileFormats/FFmpegMaxPredOrder"
But where the paths are read in ExportFFmpeg.cpp, that was read in one place,
and in another, "/FileFormats/FFmpegMaxPartOrder" was read, and that path was
not written anywhere.
The intention was surely that the other spin control should have used that path.
... but see code comments about the apparent original intent, to update some
other preference instead; which I don't do, thus preserving present behavior
Problem:
If an ASlider in the main window is clicked, then you can't TAB away from the control.
Fix:
Keyboard shortcuts are handled using key down events. However, ASlider was handling char events for reasons unknown. I'm unsure why this was causing a problem, but changing ASlider to handle key down events fixes the bug.
Problem:
1. Use either no prior config files, or set the default shortcuts to standard.
2. If a set of keyboard shortcuts is imported, then any shortcut for a command which only has a default shortcut in the full set is not set, unless it differs from the default shortcut.
This occurs because in CommandManager::HandleXMLTag(), the imported shortcut is only used if it's different from the default shortcut. But for all commands, even those commands which only have a default shortcut in the full set, GetDefaultKeyFromName() returns the default shortcut.
Fix:
Use the imported shortcut, regardless of whether it is different from the default shortcut. (I've left the function GetDefaultKeyFromName(), even though it is not longer used.)
Note:
This results in a change of behaviour:
Before: if you'd customized the shortcut for a command, then if you imported a set of shortcuts, that customized shortcut would only have been changed if the imported shortcut was also customized.
Now: If you import a set of shortcuts, then these become your shortcuts, regardless of any customizations present before the import.
I think the new behaviour is what a user would expect.
Problem:
In Mouse preferences, the list of bindings has a dummy empty column, which is a workaround for getting the Tool column to be right aligned. As a result, Narrator reads the list as having 5 columns which is confusing. In addtion, when arrowing down such a list, Narrator initially just reads the contents of the first column, which is unfortunately an empty string.
Fix:
After all the columns have been inserted, the dummy column can be deleted. This workaround was suggested by some Microsoft documentation.
Problem:
In the Macros window, the list of steps has a dummy empty column, which is a workaround for getting the Num column to be right aligned. Narrator reads the table/list as having 4 columns which is confusing. In addition, when arrowing down such a list, Narrator initially just reads the contents of the first column, which is unfortunately an empty string.
Fix:
After all the columns have been inserted, the dummy column can be deleted. This workaround was suggested in some Microsoft documentation.
Note:
I've made what I think is a correct change for some Mac specific code, but haven't tested this.
