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;

(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.

Karl Brandt

Applied.

I changed that (but didn't test a win32 compilation).

Mattias

Thanks

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?

Mattias

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