[lazarus] Patch: ComboBox issues

[Karl Brandt]

Marc Weustink wrote:

> + > + -Changes to the Height property are ignored and reading it will
> + > +   allways return the height of the edit part (determined by the font):
> +
> + Ok. The gtk-interface is doing the same for scrollbars.
> +
> +
> + > +    just like in Delphi
> +
> + Who cares what Delphi can _not_ do? ;)
> 
> It is not a Delphi issue, but it is (or at least was) a Win(32 ?) issue.
> 
> For some odd reason, the height of a combo is the Edit area +
> DropDownHeight.
> At least that was what I thought. I've reread the the MSDN about comboboxes
> and nowhere is stated that the height is fixed. I think it is possible to
> set the heigtht of the edit area.

You can set in two ways:
-Sending a CB_SETITEMHEIGHT message, but just after a click the size
returns to the former. I think this is useful only with owner draw controls

-Changing the control font: default font: size = 24, default GUI font = 21

and AFAIK standalone edits height also can't be changed

> Speaking of, I've been playing with it in the past and the only issue which
> comes into mind is that when the edit area height is less then the internal
> editor height, the editor is not shown. I cant recall if it was on all
> platforms or just win311/win95/NT351/NT4

If you set height < (EditHeight+ ItemHeight + 2) the dropdown list is
not show.
Where EditHeight = Getwindowrect (and not CB_GETITEMHEIGHT,-1 returned
value)
ItemHeight = CB_SETITEMHEIGHT,0

Bellow i'll try to explain the behavior under win32:

height < (EditHeight+ ItemHeight + 2) -> dropdown is not show
height > (EditHeight+ ItemHeight + 2)
   - without items : shows a empty dropdown list where heigth(of the
     dropdown) = height - EditHeight -( 2 ??)
   - with items
      + ((number of items)*item height + EditHeight) < heigth : fits to
         the number of items
      + ((number of items)*item height + EditHeight) > heigth : shows a
         scrollbar (if WS_SCROLL style)

When i said before : i _tried_ ;-)

karl