[lazarus] Bugs in TCustomListBox
Mattias Gaertner
nc-gaertnma at netcologne.de
Sun Dec 29 10:46:34 EST 2002
On Sun, 29 Dec 2002 13:48:04 -0200
Karl Brandt <pascalive at bol.com.br> wrote:
> Mattias Gaertner wrote:
>
> >On Sat, 28 Dec 2002 18:59:03 -0200
> >Karl Brandt <pascalive at bol.com.br> wrote:
> >
> >
> >
> >> While trying to implement the ListBox/ComboBox under win32 i found
> >>some bugs In TCustomListBox code:
> >>
> >>(1) Some time ago, Martin Smat found that the wrong Items object was
> >>being sent through LM_SORT message (TCustomListBox.UpdateSorted).
> >> The problem is that the FItems is created as TExtendedStringList and
> >>the interface expects a interface list type. The current solution is
> >>wrong because CNSendMessage(LM_GETITEMS, Self, nil) returns a new
> >>instance of the interface list and not the current list (see
> >LM_GETITEMS).>
> >>procedure TCustomListBox.UpdateSorted;
> >>var AMessage : TLMSort;
> >>begin
> >> if not HandleAllocated then exit;
> >> with AMessage do begin
> >> Msg:= LM_SORT;
> >> --> List:= TObject(Pointer(CNSendMessage(LM_GETITEMS, Self, nil)));
> >> IsSorted:= FSorted;
> >> end;
> >> CNSendMessage(LM_SORT, Self, @AMessage);
> >>end;
> >>
> >>In CreateHandle,if UpdateSorted is called after FItems is converted to
> >>a interface list type then we could just send FItems to the interface;
> >>To win32 is necessary that UpdateSelectionMode also come after the
> >>conversion;
> >>
> >>
> >
> >Applied.
> >
> >
> >
> Thanks
>
> >
> >
> >
> >>(2) In LM_SETBORDER message (gtk and win32) there's a explicit typecast
> >
> >>that may be wrong:
> >> (..)
> >> If (TControl(Sender).fCompStyle = csListBox) Or
> >>(TControl(Sender).FCompStyle = csCListBox) Then
> >> Begin
> >> If -> TListBox(Sender)<-.BorderStyle =
> >>TBorderStyle(bsSingle) Then
> >> (..)
> >> If the control is TCListBox the type cast is wrong. It's not causing
> >
> >>errors, but i thing that should be corrected.
> >> I propose to make the BorderStyle property public in TCustomListBox
> >>so we can typecast to TCustomListBox and not to TListBox.
> >> BTW is there any problem to make the Sorted property public in
> >>TCustomListBox?
> >>This would facilitate the implementation of Sorted under win32.
> >>
> >>
> >
> >I changed that (but didn't test a win32 compilation).
> >
> >
> I updated and it's OK(with the ListBox code and the crash).
> But, how about property Sorted being public in TCustomListBox?
> This will make easier/faster to get this property working under win32.
> Is there any problem with this?
Just the normal 'protected' reason. If someone writes a TNotSoMightyListBox,
that does not support 'Sorted', it has to explicitely hide the property. The
VCL/LCL defines the TCustomXXX components, so that new components need just
to write, what they support, not what they do not support. There are many
properties that need visibility cleanup, but with fpc 1.0.x it was of no
use. With 1.1 this becomes more and more important.
Mattias
More information about the Lazarus
mailing list