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

Vadim Zeitlin vadim at wxwindows.org
Sun Apr 15 08:07:38 PDT 2007


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)?

 Thanks,
VZ

-- 
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/





More information about the wx-users mailing list