[Patch] WinGUI - Yet more AutoName fixes

Archive of historical development discussions
Discussions / Development has moved to GitHub
Forum rules
*******************************
Please be aware we are now using GitHub for issue tracking and feature requests.
- This section of the forum is now closed to new topics.

*******************************
Post Reply
ExDeus
Posts: 43
Joined: Mon Mar 02, 2009 7:13 am

[Patch] WinGUI - Yet more AutoName fixes

Post by ExDeus »

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

I encountered a strange scenario where the output file extension would get set to ".". The bottom line is that Main.autoName() shouldn't try to add an extension if there isn't one to add, and frmMain.SetExtension() should change the extension rather than replace known ones. I may have forgotten a reason for this - like only known extensions should be replaced - but allowing for that makes it easy to get into a situation where no extension is ever added.

Under the following conditions the container format is not set when the application starts:

* The built-in presets are not present (there's no "Normal" preset to select by default).
* The user has custom presets, but does not have a default preset set.

If the user's first action once the app starts is to select the video source then, despite the fact that Main.autoName() is called three times as a result of events propagating, it is not called *after* the first preset in the list (by default) is loaded. The frmMain.SetExtension() function is called instead, which does not change the file extension, it replaces text for known file extensions.

The strange thing is that if the user first does something else with the UI before picking the video source - say, interacts with the Container drop-down, but does *not* select a value - then the first preset is loaded *before* one of the calls to Main.autoName(), and the output file gets named appropriately. It goes to [External code] when you unwind the call stack in Visual Studio, so I don't feel like digging deeper to see why that might be.


On another note, I found a switch statement that resulted in all code branches executing the same logic, so I scrapped it. I assume it was there for historical reasons when the branches had different logic.
User avatar
s55
HandBrake Team
Posts: 10357
Joined: Sun Dec 24, 2006 1:05 pm

Re: [Patch] WinGUI - Yet more AutoName fixes

Post by s55 »

http://trac.handbrake.fr/changeset/2809
On another note, I found a switch statement that resulted in all code branches executing the same logic, so I scrapped it. I assume it was there for historical reasons when the branches had different logic.
Probably. I think I combined code from the 3 input buttons at some point and probably just didn't notice it was the same.
ExDeus
Posts: 43
Joined: Mon Mar 02, 2009 7:13 am

Re: [Patch] WinGUI - Yet more AutoName fixes

Post by ExDeus »

The other thought I had after looking at it again is that it would only execute the source scan if (1 <= type <= 3). Is that desirable?
Post Reply