The purpose of blocking is to reload user INIs after they
have been edited. However, ISOProperties never reloads
default INIs, because they aren't meant to be edited.
Blocking on default INIs is thus useless, and it's
rather annoying for games that have two default INIs,
because it makes it impossible to see both at once.
On OS X, this broke Cmd-V to paste in the text boxes. Apparently wx
thinks having mnemonics (which are Alt-* on Windows) be Cmd-* on OS X,
even if this disables standard shortcuts, is a good idea.
Lioncash suggested just getting rid of the accelerators on non-menu
controls, so I'm doing that rather than disabling them only on OS X.
1) Apparently wxString::Format is type safe, and passing a u32 to it
with the format "%lu" crashes with a meaningless assertion failure.
Sure, it's the wrong type, but the error sure doesn't help...
2) "A MenuItem ID of Zero does not work under Mac". Thanks for the
helpful assert message, no thanks for making your construct have random
platform-specific differences for no reason (it's not like menu item IDs
directly correspond to a part of Cocoa's menu API like they do on
Win32).
This makes the code cleaner and also leads to some user-visible changes:
The wx game properties will no longer let the user
select WAD languages that don't have any names.
The Qt game list will now display names using the languages
set in the configuration instead of always using
English for PAL GC games and Japanese for WADs.
If a WAD doesn't have a name in the user's preferred language,
English is now selected as a fallback before Japanese.
Core::Shutdown was only called on app exit, yet the emu thread exits
whenever emulation stops; if you launched a new game it would just join
via the destructor when s_emu_thread was set to a new thread.
(Incidentally, the destructor also makes explicitly joining on app exit
rather pointless.)
Because the GUI thread wasn't waiting for the CPU thread to fully shut
down, Core::IsRunning would remain true briefly after CFrame::DoStop
which, given Dolphin's penchant for accessing variables belonging to
other threads, can only mean trouble... In my case, because the previous
commit caused UpdateGUI, which is called at the end of DoStop, to call
PauseAndLock, which checks IsRunning, pressing stop at the right time
would cause strange behavior.
Since its lifetime is managed on the CPU thread, this (or a refactoring)
is absolutely required. One of the functions with a PauseAndLock call
added is CFrame::UpdateGUI; this is fine now, since it's called only
after important events happen, so just make sure not to call it every
frame or something :)
Initially, the dialogs construct in the background when Dolphin initializes. However, it waits until the user actually makes the dialogs visible to decide on whether to create the Wii or GC control layouts.
Therefore, the call to CreateBaseLayout() essentially creates a sizer that isn't actually attached to a main sizer that is set as the sizer for the dialog to use. So upon destruction, these controls would never actually be destroyed if the user didn't open and then close the TAS dialogs.
