[Patch] WinGUI - CLI output, custom DAR, Queue, Window size

[ExDeus]

Sorry, it's been a while, so not sure if we're using one thread or many these days for WinGUI patches.

CLI Output

I haven't seen it discussed, but I assume backwards compatibility between the current WinGUI and the 0.9.3 version of the CLI is a low or nonexistent priority, but I thought, at least in this isolated case, it might be nice to be able to parse the output of the last CLI version without throwing an exception, so I added a branch to correctly parse either new or old CLI output for the aspect ratio info.

Pastebin: http://handbrake.fr/pastebin/pastebin.php?show=832

DAR

_cachedDar needs to be set before its value is accessed, and it should be based on the (display width) / (display height).

So, I started by initializing _cachedDar to the CalculateAnamorphicSizes().Width / CalculateAnamorphicSizes().Height.

Next, if you set the PAR from the source PAR at the end, it overwrites the values that were calculated from the display width and output width in updownDisplayWidth_ValueChanged(). So, I moved the PAR values up above the call to updownDisplayWidth_ValueChanged().

Finally, if you use one of the .NET TryParse() functions, the out variable is set to 0 if the parse fails, so you have to check the return value of TryParse() for success, and if it fails, initialize the variable to a desirable value (16 for the modulus value, in this case).

Pastebin: http://handbrake.fr/pastebin/pastebin.php?show=836


Activate Queue Window

I patched this before, so the window would actually be raised to the foreground when the Show Queue button is clicked. What happened?

Pastebin: http://handbrake.fr/pastebin/pastebin.php?show=833


WinGUI Window Size

Do we really care about the user's desktop resolution? Why is this being checked? Worst case scenario, the WinGUI window is larger than the desktop, in which case scrollbars appear. So what - let them handle it. Is it so bad that the user shouldn't be allowed to run the GUI at all? I, for one, can't be the only one who runs the GUI on a home theater PC with a height slightly under 700, due to overscan. The WinGUI works fine after I create a custom build just to get around the resolution check.

So, I removed the resolution check, and simplified the remaining code.

Pastebin: http://handbrake.fr/pastebin/pastebin.php?show=834

[s55]

CLI Output

I never have maintained backwards compatibility. It just over complicates things and by the time we get releases out, it usually requires so much code it's just not worth it.

DAR

I'll look at this later when I'm not so tired.

Activate Queue Window

It also activated the window when adding an item to the queue. I got several complaints over that. I must have forgotten about it. I've just moved the activate onto frmMain and it works fine.

WinGUI Window Size

The window is significantly smaller now, so I'll get that limit dropped so it'll work fine on overscan panels.
Netbook users have just been a nightmare, hence the limitation.

[s55]

It would appear there are still a few glitches in the Custom mode, however this dar patch appears to fix an exception or two that was appearing.

[ExDeus]

Brilliant, thank you.

One note - It appears on the minimum GUI size the text of the error string wasn't updated to reflect the new 620 height requirement.

I realize you could just change the value, but I made a quick patch so as to reformat the string in preferred .NET syntax.

Side question - do you have a preference on the root "index" we should use for creating patches, i.e., from HandBrake/ or HandBrake/win/ or HandBrake/win/C#/ ?

Patch: http://handbrake.fr/pastebin/pastebin.php?show=851