SetSize on wxChoice / wxComboBox

[Stefan Csomor]

Hi

IIRC win32 API was using the y component of a size sent to these control
to indicate the size of the control and the drop-down list. What is the
contract as of trunk behind the wx versions of these controls ? always
just indicating the control's size or more ? if yes, then I'd have to
replace the height with GetBestSize().y then I guess

Thanks for an update,

Stefan

[Vadim Zeitlin]

On Mon, 17 Jun 2013 15:41:56 +0000 Stefan Csomor wrote:

SC> IIRC win32 API was using the y component of a size sent to these control
SC> to indicate the size of the control and the drop-down list. What is the
SC> contract as of trunk behind the wx versions of these controls ? always
SC> just indicating the control's size or more ? if yes, then I'd have to
SC> replace the height with GetBestSize().y then I guess

No, nothing more, wxComboBox is consistent with all the other controls and
setting its height to 100 really makes the permanently visible part of the
combobox 100 pixels tall. Even if this doesn't make much sense, it's still
better to handle this control consistently with all the others instead of
doing something special for it.

The only drawback of the current approach is that there is no way to set
the height of the dropdown currently but if we really need this, we should
just an extra method to wxComboBox to do it.

Also, please notice that there is a unit test for wxComboBox::SetSize() in
the unit test suite, it would be great if it could (continue to?) pass
under OS X.

Thanks,
VZ

[Stefan Csomor]

Hi

exactly the behavior of that test is what contradicts the conclusion
reached in

http://trac.wxwidgets.org/ticket/14498

in order to follow that, I should indeed replace the height component of a
SetSize call with

GetBestSize().y

..

Best,

Stefan

[Vadim Zeitlin]

On Tue, 18 Jun 2013 10:38:19 +0000 Stefan Csomor wrote:

SC> Hi
SC>
SC> >SC> IIRC win32 API was using the y component of a size sent to these
SC> >control
SC> >SC> to indicate the size of the control and the drop-down list. What is
SC> >the
SC> >SC> contract as of trunk behind the wx versions of these controls ? always
SC> >SC> just indicating the control's size or more ? if yes, then I'd have to
SC> >SC> replace the height with GetBestSize().y then I guess
SC> >
SC> > No, nothing more, wxComboBox is consistent with all the other controls
SC> >and setting its height to 100 really makes the permanently visible
SC> >part of the combobox 100 pixels tall. Even if this doesn't make much
SC> >sense, it's still better to handle this control consistently with all
SC> >the others instead of doing something special for it.
...
SC> > Also, please notice that there is a unit test for wxComboBox::SetSize()
SC> >in the unit test suite, it would be great if it could (continue to?)
SC> >pass under OS X.
SC>
SC> exactly the behavior of that test is what contradicts the conclusion
SC> reached in
SC>
SC> http://trac.wxwidgets.org/ticket/14498

Sorry, I don't see any contradiction? The conclusion I made there was that
we should have a default maximum for the combobox height to avoid problems
with this. AFAICS this should fix the problem mentioned in this ticket. And
as setting the max size for any window (including child ones) is supposed
to work now, it seems like it ought to be simple to do.

SC> in order to follow that, I should indeed replace the height component
SC> of a SetSize call with
SC>
SC> GetBestSize().y

Well, if OS X explicitly doesn't support comboboxes with any other height,
we may still do this. But perhaps we could leave at least the possibility
to set smaller height? I know that it's supposed to be achieved by using a
different window variant under OS X but I am not sure if many people know
about this API.

Thanks,
VZ

[Stefan Csomor]

Hi

>SC> > Also, please notice that there is a unit test for
>wxComboBox::SetSize()
>SC> >in the unit test suite, it would be great if it could (continue to?)
>SC> >pass under OS X.
>SC>
>SC> exactly the behavior of that test is what contradicts the conclusion
>SC> reached in
>SC>
>SC> http://trac.wxwidgets.org/ticket/14498
>
> Sorry, I don't see any contradiction? The conclusion I made there was
>that
>we should have a default maximum for the combobox height to avoid problems
>with this. AFAICS this should fix the problem mentioned in this ticket.
>And
>as setting the max size for any window (including child ones) is supposed
>to work now, it seems like it ought to be simple to do.

ok, so you would rather set the max height to be GetBestSize().y than
overriding this in SetSize ?

>
>SC> in order to follow that, I should indeed replace the height component
>SC> of a SetSize call with
>SC>
>SC> GetBestSize().y
>
> Well, if OS X explicitly doesn't support comboboxes with any other
>height,
>we may still do this.


>But perhaps we could leave at least the possibility
>to set smaller height? I know that it's supposed to be achieved by using a
>different window variant under OS X but I am not sure if many people know
>about this API.

we can leave this, of course, but it will not really work, as the artwork
will not scale down, only the variant is relevant for getting a smaller
artwork.

Thanks,

Stefan

[Vadim Zeitlin]

On Wed, 19 Jun 2013 07:11:42 +0000 Stefan Csomor wrote:

SC> ok, so you would rather set the max height to be GetBestSize().y than
SC> overriding this in SetSize ?

Yes, but if setting smaller height doesn't work neither, then it probably
doesn't really matter in practice...

Regards,
VZ