[lazarus] Patch: ComboBox issues

[Marc Weustink]

+ From: Karl Brandt [mailto:pascalive at bol.com.br]
+ Sent: donderdag 31 juli 2003 4:22
+
+ Mattias Gaertner wrote:
+
+ > On Wed, 30 Jul 2003 11:10:57 +0200
+ > "Marc Weustink" <marc.weustink at cuperus.nl> wrote:
+ >

[Snip]

+ > What autosize function?
+
+ I think has to do with setting Align property to alTop in
+ TObjectInspector.AvailCompsComboBox.
+ I can't see other positioning setting in this control.
+
+ It looks, at same time after a WM_SIZE, that the LCL stores the total
+ height (Edit + dropDownlist) as the actual clientrect and uses this when
+ positioning the controls.
+ If i modify the WM_SIZE handling i could avoid this, but i'm looking a
+ cleaner way

I was wondering why there isn't such adjustment in Delphi, so I've been
playing with some spy and control modification tools and saw the following.

When sending a SetWindowPos with a new height N (Original height is H) I
get:
  WM_WINDOWPOSCHANGING  height N
  WM_WINDOWPOSCHANGED   height N
   WM_SIZE               height N
    WM_WINDOWPOSCHANGING  height H
    WM_WINDOWPOSCHANGED   height H
    WM_SIZE               height H
     WM_WINDOWPOSCHANGING  height H

So the win32 interface should allways report editheight at the end (but
isn't it getting this height from the internal WM_SIZE ?)

On a dropdown I see the same, where N is the total height.

GetClientRect reports height N

[SNIP]

+ > TCustomComboBox is a base class, so optional properties should
+ > be protected.
+
+ The current way i did is incompatible if custom descendants of
+ TCustomComboBox

I think it also works for fpc. to access protected members, cast it to a
local derived class, like
  TMyCustomComboBox = class(TCustomComboBox)
  end;

Marc