[wxMac 2.8x] wxWindow::DoGetBestSize bug still not solved

[H]

In article <XLtIBC.A.6x.J_jIGB at brage.sunsite.dk>,
 vadim at wxwindows.org (Vadim Zeitlin) wrote:

> On Sun, 15 Apr 2007 16:53:49 +0200 H <H at h.com> wrote:
> 
> H> When the real window size is (0, 0) and there are children (in this case 
> H> scrollbars) you might get a negative client size.
> 
>  But the problem is clearly that GetSize() returns (0, 0) if the window
> does have the scrollbars -- this is obviously wrong quite independently of
> GetBestSize() (which I think does behave correctly). Of course, I write
> this supposing that my other hypothesis -- namely that GetSize() does work
> correctly and the window simply does not have scrollbars yet at this moment
> -- is wrong, but this actually still not clear.
> 
> 
> H> I would already have fixed the problem if somebody can tell me which 
> H> functions should have which values. I do not know which values these 
> H> functions should return:
> H> 
> H>  - GetSize() // probably at all times the real size of the window
> 
>  Yes, the size of the window including scrollbars if they're currently
> shown. If GetSize() returns 0 for a window which does have active scrollbar
> hen it's a bug.
> 
> H>  - GetClientSize() // what happens if the children's sizes are larger 
> H> than the window's size? At the moment we get sometimes negative values 
> H> under these conditions.
> 
>  GetClientSize() doesn't care about children at all. It should return the
> size available for the children (or for drawing), i.e. the size of the area
> of the window not taken by the scrollbars.
> 
> H>  - DoGetBestSize // which size is best? With or without scrollbars - 
> H> especially if only scrollbars are present?
> 
>  The full, i.e. non-client, best size. When scrollbars appear/disappear the
> best size may need to be recalculated.
> 
> H>  - Get/SetMinSize() // What is the minimum size - again especially under 
> H> the condition of existing/visible scrollbars?
> 
>  This is the only one about which I have some doubts. The existing code
> treats it as if it took the full size. I think using client size might have
> been more logical but, on balance, it's probably better to continue to
> suppose that this one works with the full size and add a SetMinClientSize()
> if we really need it
> 
> H>  - SetDefaults() // with or without scrollbars? Does a default size of 
> H> (0, 0) makes sense at all? At the moment (0, 0) is returned which does 
> H> not make sense for me at all as this results in a non-visible window as 
> H> a default state.
> 
>  SetDefaults() is a wxSize method and is completely trivial, in particular
> it doesn't know at all about scrollbars. It simply replaces the components
> of wxSize left unspecified by user by the components of the given size
> object.
> 
> H> At the moment I am using these functions hoping that they return 
> H> something useful but this is not always the case.
> 
>  Again, I still don't know if there is indeed bug in GetSize() or if it's
> just the matter of not updating the best size of wxTreeCtrl when items are
> added to it. My bet would be the latter but as you keep writing that
> GetSize() is buggy you probably have some reasons to believe this. So can
> you see, in a simple example not involving wxTreeCtrl at all, that
> GetSize() returns (0,0) for the window which does have scrollbars (i.e.
> SetScrollbars() with non-0 parameters was called)?
> 

GetSize() returns (0, 0) from the system if the window is not shown on 
the screen. It does not matter whether the window has got children 
(scrollbars) or not.

>  Thanks,
> VZ

Hi Vadim,

It is very difficult to for me to create another example. I would like 
to use the notebook sample because I know in the meantime what is 
happening there.
I did not say that there is a bug in GetSize(). GetSize() is fine and 
does what it should do.
DoGetBestSize() is the problem (or GetClientSize())! DoGetBestSize() 
returns (0, 0) because it calls GetSize() and does not take into 
consideration that there are scrollbars that should be visible!
Other classes (like the generic tree control) assume that the size 
obtained by DoGetBestSize() is large enough to make the client size at 
least zero. But this is not the case.
If DoGetBestSize() returns (0, 0) and you set the window to this size 
and the scrollbars are still marked to be shown GetClientSize() returns 
negative values!

So, there are 2 possibilities to get rid of the bug:

Possibility 1 - adapting DoGetBestSize()

By removing 

        // return as-is, unadjusted by the client size difference.
        return size;

and by replacing the variable "size" by "best".

in the else-clause. Then the size will be increased so that at least the 
client size will always be larger or equal to zero:

    // Add any difference between size and client size
    wxSize diff = GetSize() - GetClientSize();
    best.x += wxMax(0, diff.x);
    best.y += wxMax(0, diff.y);


Possibility 2 - adapting DoGetClientSize()

The solution is to guarantee that DoGetClientSize always returns values 
larger or equal to zero. But some methods (like DoGetBestSize() rely on 
the fact that GetClientSize() will sometimes return values smaller than 
zero). TOTALLY STRANGE....

Original:
    if (m_hScrollBar  && m_hScrollBar->IsShown() )
        hh -= m_hScrollBar->GetSize().y ;

    if (m_vScrollBar  && m_vScrollBar->IsShown() )
        ww -= m_vScrollBar->GetSize().x ;

Solution:
    if (m_hScrollBar  && m_hScrollBar->IsShown() )
        hh -= m_hScrollBar->GetSize().y ;
    if (hh < 0)
      hh = 0;

    if (m_vScrollBar  && m_vScrollBar->IsShown() )
        ww -= m_vScrollBar->GetSize().x ;
    if (ww < 0)
      ww = 0;

For this solution I need the confirmation that GetClientSize() always 
returns values larger or equal to zero!

Personally, I prefer to modify DoGetBestSize because it needs an 
overhaul anyway and it assumes that GetClientSize() returns negative 
values (I do not like this construction at all as it does not make 
sense; nobody expects a client size smaller than zero).

Hartwig