search

picoe / Eto

Cross platform GUI framework for desktop and mobile applications in .NET
Other
3.66k stars 333 forks source link

[WinForms] Dialogs with TableLayouts not autosized properly #1401

Open ItEndsWithTens opened 5 years ago

ItEndsWithTens commented 5 years ago

When creating a custom dialog in WinForms, there seem to be some circumstances under which TableLayouts aren't autosized correctly. I wish I could say what exactly those circumstances are, but they apparently involve TabControls and GroupBoxes.

Expected Behavior

A dialog, with tab control, containing some nested table layouts and group boxes, defaults to a size that shows all the controls (this being just an example I arrived at by manually resizing the dialog, but I'd expect something similar): WinForms-Expected

Actual Behavior

The dialog isn't the minimum possible, but is much smaller than I think is appropriate considering what controls are inside it: WinForms-Actual

Steps to Reproduce the Problem

To reproduce the screenshots above:

  1. Clone https://github.com/ItEndsWithTens/EtoDialogAutoSizeTest
  2. Build and run the WPF GUI. Click "Spawn complex Dialog" and you'll get a dialog box that looks sensible, with everything in plain view.
  3. Close the WPF GUI and build/run the WinForms project. Spawn the complex dialog, and everything is shrunken down. The dialog is resizable, and shows that all the controls are there, just not contributing to the dialog size.

A simpler reproduction, that's hopefully easier to debug, is available with the "Spawn simple Dialog" button:

  1. Build and run the WinForms GUI.
  2. Click "Spawn simple Dialog". There should be two stacked GroupBoxes, each with a button, no surprises there, everything looks fine.
  3. Close that dialog, check the "nest" option, and spawn the simple dialog again. The buttons are too small, and their text is cut off. I don't know if this is the TabControl's fault, or some interaction between that and the GroupBoxes.
  4. Close that, uncheck "nest", check the "include buttons" box, and make another simple dialog. The button text is fine, and Cancel is visible, but OK is off to the side, as if the positive/negative buttons aren't taken into consideration when auto sizing a dialog box. This may be a separate issue from the TableLayout thing, but it came up at the same time, so I added an option to try it.

Specifications

I'm fully prepared for this to be my own misuse of Eto's layout features, but even after reading the TableLayout docs, and issue #1299, I haven't been able to wrap my walnut brain around what I'm doing wrong. I've been trying to figure this out for a little bit now, and didn't want to open an issue unnecessarily, but I have the impression you're ramping up development toward version 2.5, and didn't want to risk possibly letting something slip past.

Currently my actual project is just setting the dialog box in question to have an absolute initial size, at some fraction of the primary screen's dimensions, but that strikes me as fragile, and by rights I think it should be only as large as necessary for the controls it contains.

Of course, another point would be "why not stop using WinForms altogether", but I'm doing 3D rendering work, and despite my long term desire to use WPF, in the short term performance with embedded graphics stuff leaves something to be desired. I know WinForms is extra effort to maintain, so I don't want to suggest this is a pressing issue, I'd just like to find out if this is in fact only an oversight on my part.

cwensley commented 4 years ago

Thanks for reporting the issue, sorry for the late response. I think the WinForms platform needs some major refactoring how the preferred size and layout is done. Currently a lot of (excessive) code is done to set the MinimumSize of controls to their preferred size which is a terrible way to do it.

Ideally, Eto should be using overrides to OnLayout() and GetPreferredSize() for container controls to properly translate Eto's layout system to Windows.Forms.