wxAuiNotebook::LoadLayout() wxAUI_DOCK_CENTER invariant?

[wsu]

The implementation of wxAuiNotebook::LoadLayout() ignores the wxAuiTabLayoutInfo dock_layer, dock_row, dock_pos fields when dock_direction == wxAUI_DOCK_CENTER.

So does this imply that there is a system invariant that dock_layer, dock_row, and dock_pos should always be 0 when dock_direction == wxAUI_DOCK_CENTER?

If so, then I have found that I can violate this invariant in the auidemo sample by splitting the notebook and moving panes around.

If not, then it seems like the wxAuiNotebook::LoadLayout() implementation should pay attention to the wxAuiTabLayoutInfo dock_layer, dock_row, dock_pos fields.

[Vadim Zeitlin]

On Sun, 5 Jul 2026 21:10:23 -0700 (PDT) 'wsu' via wx-dev wrote:

w> The implementation of wxAuiNotebook::LoadLayout() ignores the
w> wxAuiTabLayoutInfo dock_layer, dock_row, dock_pos fields when
w> dock_direction == wxAUI_DOCK_CENTER.
w>
w> So does this imply that there is a system invariant that dock_layer,
w> dock_row, and dock_pos should always be 0 when dock_direction ==
w> wxAUI_DOCK_CENTER?

I would say yes, but I'm not sure.

w> If so, then I have found that I can violate this invariant in the auidemo
w> sample by splitting the notebook and moving panes around.

How does it affect the actual behaviour? I.e. I don't think the putative
invariant above is enforced in any way currently, but I don't see how would
the values of these variables differing from 0 affect the positioning of a
center pane.

w> If not, then it seems like the wxAuiNotebook::LoadLayout() implementation
w> should pay attention to the wxAuiTabLayoutInfo dock_layer, dock_row,
w> dock_pos fields.

It could/should, I guess, because this shouldn't result in any harm. But I
don't know if it really changes anything?

Regards,
VZ

[wsu]

On Monday, July 6, 2026 at 9:38:09 AM UTC-4 Vadim Zeitlin wrote:

On Sun, 5 Jul 2026 21:10:23 -0700 (PDT) 'wsu' via wx-dev wrote:

w> The implementation of wxAuiNotebook::LoadLayout() ignores the
w> wxAuiTabLayoutInfo dock_layer, dock_row, dock_pos fields when
w> dock_direction == wxAUI_DOCK_CENTER.
w>
w> So does this imply that there is a system invariant that dock_layer,
w> dock_row, and dock_pos should always be 0 when dock_direction ==
w> wxAUI_DOCK_CENTER?

I would say yes, but I'm not sure.

w> If so, then I have found that I can violate this invariant in the auidemo
w> sample by splitting the notebook and moving panes around.

How does it affect the actual behaviour? I.e. I don't think the putative
invariant above is enforced in any way currently, but I don't see how would
the values of these variables differing from 0 affect the positioning of a
center pane.

I haven't seen any directly observable effect of the non-0 variables.  The way I discovered it was indirect:  I have an application that can load multiple  independent documents, each of which can have multiple tabs, and I am trying to implement save and restore of the notebook layout.  Since the documents are independent, I save/restore the layout as part of each document.  When I did some testing, I discovered that I could rearrange the tabs in a way that appeared to result in all the tabs being in the "standard" wxAUI_DOCK_CENTER, but that saving and loading the document produced strange results when there was already another document loaded in the "standard" wxAUI_DOCK_CENTER.

 

w> If not, then it seems like the wxAuiNotebook::LoadLayout() implementation
w> should pay attention to the wxAuiTabLayoutInfo dock_layer, dock_row,
w> dock_pos fields.

It could/should, I guess, because this shouldn't result in any harm. But I
don't know if it really changes anything?

I would prefer that the dock_* variables always be 0 since that would mean I don't have to figure out how to reconcile the values across different documents, but I don't know whether restricting them would cause other problems.  I guess I will have to do some experiments to try to understand what these variables mean for wxAUI_DOCK_CENTER.

Regards,
VZ