BUG in sample/statbar sample or wxStatusBar BUG + more ( wxMSW 2.6.2 ) - SOLVED ?

BUG in sample/statbar sample or wxStatusBar BUG + more ( wxMSW 2.6.2 ) - SOLVED ?

Post by undergrave » Mon, 20 Mar 2006 21:09:43


ulian-Nicu Serbanoiu wrote:

I've managed to track down the bug regarding the huge size of the
statusbar.
Here it is how it goes:
When the statusbar is created it automatically becomes a child of the
parent window.

*Fact*: A window ( wxDialog or wxFrame ) with a *single* child it
automatically makes that child as big as the client area ( almost in gtk
). This is done in the base class wxTopLevelWindow in the function
wxTopLevelWindowBase::DoLayout. This can be found in
src/common/toplvcmn.cpp. The function checks first if a layout is
present and uses it in case it is present. If no layout is present it
starts iterating all the child windows and if it finds only one child
window [that is not a statusbar or toolbar or menubar] it makes that
child as big as the client area with this call ( if there is ONLY one
child of that type ):
....
child->SetSize(ofs, ofs, clientW - 2*ofs, clientH - 2*ofs);
....

The problem arises when I actually need to hide a status bar for one
reason or another and from the program I call SetStatusBar ( NULL );
After doing that, the function "IsOneOfBars" defined in
src/common/framecmn.cpp ( bool wxFrameBase::IsOneOfBars(const wxWindow
*win) ) will not work properly because that status bar is still a child
of the window( dialog, frame ) and the function will "say" that the
child is not a statusbar ( IsOneOfBars will return false ) and the
status bar will be resized to the entire client area ( well ... almost
the entire client area... as you can see from the source ).

In my opinion this feature is not really useful and generated the bugs
reported by me in one of previous mails.
My repair was ignoring the automatic resize and only accept the layout.
The function looks like this:

void wxTopLevelWindowBase::DoLayout()
{
// if we're using constraints or sizers - do use them

if ( GetAutoLayout() )
{
Layout();
}
else
{
return;
..........
}
}


Everything works now fine. I don't know if this is a good way to repair
this bug but since I cannot find a good reason to resize the only
component to the parent's client size I will consider this as a fix.
For me it is not useful and I was wondering if any of the developers of
the wxWidgets library could tell me the reasons for this ( glade like ?
) behavior .

I don't provide a fix because I don't know the reasons [for that
behaviour] yet and I will be glad to find them.
Hope the information I provided is correct.

I also modified the SetStatusBar as you can see below ( file
src/common/framecmn.cpp ) :

I'd like to know if it's ok because the previous version seemed a little
odd to me.

void wxFrameBase::SetStatusBar(wxStatusBar *statBar)
{
/*
bool hadBar = m_frameStatusBar != NULL;
m_frameStatusBar = statBar;

if ( (m_frameStatusBar != NULL) != hadBar )
*/

bool different = ( statBar != m_frameStatusBar );
m_frameStatusBar = statBar;
if( different && m_frameStatusBar != NULL )
{
PositionStatusBar();

DoLayout(); // this is the function that makes the bar larger in
its original form
}
}

I'm waiting for you suggestions and opinons ( in detail if possible ).

Thanks,

Iulian

---------------------------------------------------------------------
To unsubscribe, e-mail: XXXX@XXXXX.COM
For additional commands, e-mail: XXXX@XXXXX.COM

 
 
 

BUG in sample/statbar sample or wxStatusBar BUG + more ( wxMSW 2.6.2 ) - SOLVED ?

Post by undergrave » Mon, 20 Mar 2006 23:23:19


Thanks for clearing this for me !. So the only place were we should be
looking is somehow at the list of children of the frame / dialog and at
the IsOneOfBars function.
I will come up with a real fix if possible, but I'm waiting on others'
suggestions also.

Once again thanks,

Iulian

---------------------------------------------------------------------
To unsubscribe, e-mail: XXXX@XXXXX.COM
For additional commands, e-mail: XXXX@XXXXX.COM