Everything is initialised in the constructor, I used object initialiser syntax
where possible, layout is done with FLPs instead of absolute positioning, and I
changed the text a little
Functionally:
Fixed TabIndex (mostly by removing it), made the documentation link actually
visible, reordered the tabs, and changed some text.
In the code:
Did away with the designer's code style, moving declarations as close to their
init as possible.
To that end, most controls now use the object initialiser syntax, including
nested ControlCollections where possible (basically everything that isn't
assigned to a field).
The four TabPages and the more complex GroupBoxes are each constructed in a
helper method to make maintainance easier.
All event handlers are inlined as lambdas, the OK button's handler calls a
helper method to write out the config so it's easier to maintain.
Added some custom controls, and a float equality ext. method which I'm
definitely going to forget exists.
* add MAME to OpenAdvanced
* make mame launch games
limited to arcades that only need rom name. other devices require machine name and rom name, and won't run. nor they are meant to be supported anyway: we have enough emulators that do the job better for particular devices.
dunno if direct disk access will be avoidable, there are quite some files it might want to load other than the rom (parent rom, bios, artwork). trapping all of these might be a future task.
it is also known that mame can load "romname.zip" file just as well as "romname" folder, which would represent an unarchived zip. I make use of it to send it zip name with extension. it's easy, and we're not obliged to recognize mere folder paths in the mame-advanced-loader logic.
* ability to run lua code inside mame
* Move PlatformSpecificLinkedLibs and implementations to common and rename
* Specify file ext. at LoadPlatformSpecific call site
* Move Client.Common.Global.RunningOnUnix to PlatformLinkedLibSingleton
* Inline var Resolver
* Use PlatformLinkedLibManager internally
* Move plugin load check to LinkedLibManager, use LinkedLibManager
* Interpolate
* Return exit code from dlclose/FreeLibrary
* Skip all calls to externs in BlipBufDll when using mono
* Use PlatformLinkedLibManager in SevenZipLibraryManager
* Add expected return value to workaround (from testing on Win32)
* Remove ".dll" from DllImport attr, remove temporary workaround, see desc.
The library can be built by changing the output file name in
`.../blip_buf/Makefile` to `libblip_buf.so`, and running `make`. It will be
loaded if placed in the `.../output` folder.
* Remove unused code, add TODO (this class is req. for Waterbox.PeWrapper)
The TODO is to [rewrite with
C#](https://docs.microsoft.com/en-us/dotnet/standard/io/memory-mapped-files)
instead of importing from `kernel32.dll`.
* Update OpenTK again but better (for #1384)
* Add Mono run script
* Add libblip_buf.so (temporary)
Temporary because it should be a separate package which BizHawk depends on.
* Add distro detection, add "already running" and "unknown distro" messages
* Gray-out Lua Console on Unix
* Extract superclass from EmuLuaLibrary, add shell implementation for Unix
* Specify libdl version, Fedora doesn't have the versionless symlink
* Remove empty `ToolStripMenuItem`, null `Text` caused crash on Unix
* Transform OpenTK keyboard input into a `List<KeyEvent>` and read that
Also fixes crash on rebind
* Remove debug `using ...;`
I did this in a funny way (sets the environment for the process).
The idea is that any code which sloppily used Path.GetTempDirectory (etc.) would now have its pathing changed.
It is a little dangerous to allow this to be changed on the fly (I do allow it) since something may expect it to be stable, but I think it's OK.
So anyway. keep your eyes peeled for problems. It's possible I could do this differently and only affect a subset of safely managed things.
should fix#1252
YoshiRulz