The UI control that's given me the most grief is the GridLayout control. It's function is to arrange widgets that are placed within it.

When determining how it's laid out, it first determines the space that the widgets within it get. If there's room to grow after that, the grid is expanded to fit the space. The widgets are then fitted to the grid.

So what size is a widget? There are three different sizes.

The natural size is the size of the widget if it were entirely unconstrained. For example, the natural size of a ListBox depends on the number of items in the list.

The requested size is the size requested by the user when the widget was initially created. This is the size that's used when determining the initial size of the grid. This can be thought of as a sort of minimum size of the widget. If the user doesn't specify the size of a control, the natural size is used instead.

The current size of the widget. This is the size that it's set to when it's been fitted into the grid. When a widget is created, the current size is set to the requested size, which may default to the natural size. It's then off to the races, as the current size may change as the window (and thus any GridLayout) may change.

And therein lay the problem: I'd been using the natural size when performing the layout for the grid control.

This meant that as values for various controls changed - for example, the width of the filenames in the file list - that widget would signal it needed to resize, and the GridlLayout would accommodate.

Unfortunately the container the GridLayout was in - in most cases, a Dialog - wouldn't be so accommodating, because unlike the child control, it hadn't resized.

The result was widgets trying to render themselves outside the bounds of the parent control.

I'm sure there are other fun bugs waiting to be discovered, but this was one of the major issues in the FileDialog that I was having a lot of trouble tracking down, so I'm glad I finally found it.

 This free site is ad-supported. Learn more
​