Certain dialogs can result in an overly wide window

[CoffeeFlux]

This is most easily reproduced with aegi-mo's Apply dialog on Windows. Interestingly, it does not happen with every dialog, so there's some specific characteristic causing this.

[CoffeeFlux]

This is apparently reproducible cross-platform when compiling against wx 3.1

[Myaamori]

All automations affected seem to have a floatedit control. I can reproduce the issue in an automation that previously had no issues by changing an intedit control to a floatedit and adding a step argument.

[arch1t3cht]

I didn't see this issue before, so I didn't mention it in the commit, but there is a possible fix in https://github.com/arch1t3cht/Aegisub/commit/9ebe154964c4d335e74026f653de24beb3699dab .

If step is not zero, the default size of wxSpinCtrlDouble elements is chosen such that it will fit its entire range of possible values - from the minimum value to the maximum. The min and max options for floatedit controls default to -DBL_MAX and DBL_MAX each, which by default sizes floatedit controls large enough to fit DBL_MAX. This also occurred for older versions of wx, but these versions would write large floats in exponential notation, which limited their widths.

The linked commit makes the min and max fields for floatedit controls default to 0 and 100 respectively when step is set, which matches the internal defaults set by wx. This does change the behavior of Lua dialogs, but it doesn't contradict the documentation in the automation manual or the v4-docs folder. So far it also doesn't seem to break any existing automation scripts.

Changing the default size instead of the default limits for these controls seemed to be more complex and less reliable from what I've seen in various wx issues on the topic.