[ wxwindows-Bugs-1771727 ] Rearranging wxAuiNotebook pages leads to inconsistent state

[SourceForge.net]

Bugs item #1771727, was opened at 2007-08-10 14:58
Message generated for change (Comment added) made by biwillia76
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=109863&aid=1771727&group_id=9863

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: AUI
Group: Must fix
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Andrey (andrey_yazhuk)
Assigned to: Benjamin I. Williams (biwillia76)
Summary: Rearranging wxAuiNotebook pages leads to inconsistent state

Initial Comment:
After rearranging notebook pages by D&D wxAuiNotebook::GetPage(index) returns pages according to the old order what is incorrect.
>From the source code it clear that tab order is duplicated it stored in wxAuiNotebook::m_tabs as well as in wxAuiTabContainer objects. wxAuiNotebook::OnTabDragMotion() updates only wxAuiTabContainer. m_tabs remains unchanged and this results in inconsistent state.

A possible solution - create a function wxAuiNotebook::MovePage() that will properly update both m_tabs and wxAuiTabContainer and to call this function where needed (only wxAuiNotebook::OnTabDragMotion() ?)

----------------------------------------------------------------------

>Comment By: Benjamin I. Williams (biwillia76)
Date: 2007-08-20 17:55

Message:
Logged In: YES 
user_id=383645
Originator: NO


The intention is to let the user drag around tabs, but have that not
affect the programmatic index of the tab.  The nature of the control is to
allow the user to rearrange and split the view, but not have that affect
the internal representation.  This is kind of similar to moving around
database columns in a column view, i.e. where the column is in the view
doesn't necessarily affect its column index.

I'd be open to a MovePage() method as described above.

Best,
Ben


----------------------------------------------------------------------

Comment By: Julian Smart (juliansmart)
Date: 2007-08-20 17:07

Message:
Logged In: YES 
user_id=59495
Originator: NO

Hi, I wonder whether the intention is to keep the original insertion order
so the app can still rely on that order for manipulating tabs? Is there any
other implication for this inconsistency, i.e. genuine bug that happens
after a tab is dragged? I think we need to discuss that with Ben @ Kirix.

Thanks!

Julian

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=109863&aid=1771727&group_id=9863