#15338 closed defect (fixed)

wxWindow::GetClientSize() can return negative size under OS X

Reported by: vadz Owned by: csomor
Priority: low Milestone: 3.0.0
Component: wxOSX-Cocoa Version:
Keywords: client-size inconcistency Cc: csomor@…
Blocked By: Blocking:
Patch: no

Description

We have a unit test failure

/Users/zeitlin/src/wx/git/tests/window/clientsize.cpp:90:Assertion
Test name: ClientSizeTestCase::ClientSizeNotNegative
assertion failed
- Expression: szw.GetWidth() >= 0

currently and debugging I see that the value returned by GetClientSize() is indeed (-3,-3) and that this happens because this is what [NSView frame] returns.

Is there any way to prevent NSView from returning this nonsensical value? If not, we probably should ensure that we convert it to 0 ourselves.

Any other insights would be welcome, TIA!

Change History (6)

comment:1 Changed 13 months ago by csomor

  • Status changed from new to infoneeded_new

If the control has a size of 1,1 and the border is double, then having a content area of -3,-3 is not too strange to me, as the size should be 4,4 to allow for the borders at all ..

in which problems do we run if we don't clip these to 0,0 ?

I must say that I use at some places the difference between client size and size to account for any adornments a control might have, and at these places I don't make sure wether the size is at least as big as it should in order to achieve a 0,0 client size, I just use the difference between the two sizes.

comment:2 Changed 13 months ago by vadz

  • Status changed from infoneeded_new to new

The problem is that for me it doesn't make sense for the size to be negative, this is something that I think just shouldn't happen in our Universe.

More practically, the problem is that the same code doesn't behave in the same way under different platforms, as the unit test passes under MSW and GTK but fails under OS X. And we added this test originally because of some existing code that misbehaved if the returned values were negative (see #13184). So I think it would be better to force the size to be 0, if it's not going to create any other problems elsewhere -- is it?

comment:3 Changed 13 months ago by csomor

  • Owner set to csomor
  • Status changed from new to accepted

I have to look through the occurrences of GetClientSize in my code, because as I mentioned I am relying on the difference between the two sizes to be always a correct representation of the non-client structure.

comment:4 Changed 13 months ago by csomor

  • Status changed from accepted to infoneeded

How about clipping in the wx/window.h's GetClientSize, that way DoGetClientSize could always be used in case the 'real' negative size is needed ?

comment:5 Changed 13 months ago by csomor

  • Status changed from infoneeded to accepted

ok, I'll clip in DoGetClientSize as the other ports do, I see that I've switched to my native GetContentArea in most places anyway already

comment:6 Changed 13 months ago by SC

  • Resolution set to fixed
  • Status changed from accepted to closed

(In [74538]) never return negative client sizes, fixes #15338

Note: See TracTickets for help on using tickets.