When switching to Cell_Formatting to fix rendering in mono and also provide
a speed up to displaying the GameGrid, it broken sorting on the CGame and
CDescription columns. This is because we are no longer setting the Value
field on those cells. On windows, clicking those column headers would do
nothing, under mono it would cause a crash.
Instead of reverting the Cell_Formatting change, this update make us handle
the sorting ourselves. Mono doesnt implement SortCompare, so had to handle
column header clicks and make our own IComparer.
This also disables sorting on columns that are images, including on RomGrid.
Mono doesnt work well with RootFolder of DesktopDirectory,
you end up being stuck in ~/Desktop/. Instead when being
run under mono use MyComputer, which dumps you to /
Mono will crash if you do a Rows.Clear() and the first row isnt visible. To
work around this, when running under mono force scroll to [0,0] cell before
issuing the Clear().
https://bugzilla.xamarin.com/show_bug.cgi?id=24372
Renamed Settings.MonoFileIO to Settings.IsUnix
Created Settings.IsMono
These changes speed up how long it takes to populate the GameGrid after
clicking on a dat in the Tree. MAME 0.155 dat was used for testing.
Before the changes population times were
windows .net = 2.75 seconds
linux mono = 23 seconds
After the changes, both now take 300-400ms.
This was done using 2 main changes.
1. Fully move populating the rows' Values to the CellFormatting function
2. Determine the total number of rows we will need and use
GameGrid.rowCount to set the row count to that. This is much faster
then doing individual Add()'s for each row.
FrmProgressWindow.Designer.cs was setup for the windows being 591 wide,
but rv was forcing it to be 498 when the window was brought up. This
was confusing mono and it was causing rendering issues. This patch
makes it so the Designer and rv agree on the width of the window.
Additional adjustments were made to standardize the spacing between
window edge/progress bar/button, resulting in a width of 511.
- on initial rendering mono likes to send a resize event where the width
is 0, ignore it. This was causing gbDatInfo to not render until a
manual resize was done.
- set AutoScaleMode to System.Windows.Forms.AutoScaleMode.None. This
fixes a number of rendering issues under mono and didnt seem to have any
negative effect under c#/windows builds.
- tweak some of the initial form sizes and locations on FrmMain. A
number of the setting didnt make sense based on the size of the panel
they were put it. This resolves an issue with the gbDatInfo and
gbSetInfo starting off with the wrong size under mono.
- CHDReturnError was not handled and would cause an exception/crash
- CHD error/filename were swapped in ErrorGrid when scanning
- Use regex when parsing chdman stdout output
