Something in 1.13 broke centering child windows

Describe the bug On 1.12.1, a child window added to another window at run-time, with X and Y set to Dim.Center() is displayed in the center of the parent Window that it is added to.

In 1.13.x, the child window is placed at 0,0 when shown. This occurs on Ubuntu 23.04 and on Windows 11 in PowerShell. If the terminal is resized down and then to a size larger than the child window, it then centers itself.

I set a breakpoint to see what was going on.

In 1.13.x, the superview of the child has 0 width and height, even though the parent Window itself has the expected dimensions. In 1.12.x, the superview of the child has the expected dimensions of the parent window.

Note that both of these Windows were created using the TerminalGuiDesigner tool.

The code used to add the child to the parent is just three lines (edited for verbosity):

//Elsewhere in the parent window class:
ChildWindowClass _childWindowAsAFieldBelongingToParentWindow = null;

//Function called by any means to create and show the child for the first time:
public void FunctionThatAddsTheChildWindow()
{
        _childWindowAsAFieldBelongingToParentWindow ??= new( );
        Add( _childWindowAsAFieldBelongingToParentWindow );
        ShowChild( _childWindowAsAFieldBelongingToParentWindow );
}

To Reproduce Steps to reproduce the behavior:

Using 1.13.X (seems broken for any version of 1.13):

1. Create a Window with width and height = Dim.Fill(0)
2. Create a Window with explicit dimensions (any will do, so long as they’re smaller than the terminal), and with X and Y = Dim.Center().
3. Add that second Window to the first Window, and show it.
4. The child window will be at 0,0,

Expected behavior The child window should be shown positioned at the center of the parent window it was added to, as in 1.12.

Desktop (please complete the following information):

• OS: Windows 11 and Ubuntu 23.04
• Terminal: Happens on any terminal emulator or shell I’ve tried, including just at a bash prompt, tmux, screen, and zsh.

Started happening after updating to the 1.13 release series. No code changes were made.

[dodexahedron]

Ah yes. Looking at the PR, it looks like you implemented a much more thorough and likely more efficient fix than the initial fix, which was just adding the call to LayoutSubviews(), which is what I’m currently using as a workaround.

I’ll test this in a few minutes and let you know how it went when I’m done.

[dodexahedron]

Cool. I don’t know for sure if I had ever hit that issue, though I may have one time that I just thought it was caused by Windows, when the system was under high CPU load from something else.

I’ll check this out later this evening (UTC-7) if I don’t forget. 😅