Tcombobox.Style not Delphi compatible and causing Tcomboxex to fail.

[jamie]

I just reported this issue..

I know how much a very few around here are so conscience about keeping Delphi compatible
but after attempting to use the TComboboEx and finding that non of the editing features you get in csDropDown work, I then did some experimenting.. Its seems the style property in the standard TComboBox has had some changes done to it which is now causing issues with descendant controls and its absolutely not Delphi compliant. Code here would never work in Delphi..

 Its an issue with using OwnerDraws, the key values do not align with those used in the TcomboboxEx..
 What you get is a csDropDownList instead of a csDropDown to the ancestor combobox.

Oh well, QA I guess.

[wp]

What you get is a csDropDownList instead of a csDropDown to the ancestor combobox

TComboboxEx does not publish the ancestor's Style at all, it introduces a new TComboboxExStyle = (csExDropDown, csExSimple, csExDropDownList). And the declaration is Delphi is TComboBoxExStyle = (csExDropDown, csExSimple, csExDropDownList) - the same. So what is the problem?

Something is screwed up, though,  in Lazarus TComboboxEx with Style = csExDropdown or csExSimple because it is not possible to type text here while it is possible in Delphi (I just checked with 10.3). But this must be a very old issue: The component was introduced 2014 in the v1.4 series. I still have Laz 1.4.4, and here the component already has the bug. It is definitely not related to the recent removal of the ReadOnly property of TCombobox.

... standard TComboBox has had some changes done to it which is now causing issues with descendant controls and its absolutely not Delphi compliant.

Nonsense. TsCellCombobox of fpspreadsheet does not exist in Delphi. TChartCombobox never was intended to be compatible with TeeChart. Probably, there exist some more. When there is an issue then the maintainers have the same problem that I had with TsCellCombobox: I used a property that had long been deprecated and forgot to take care of the time when the property would disappear.

[JuhaManninen]

I know how much a very few around here are so conscience about keeping Delphi compatible
but after attempting to use the TComboboEx and finding that non of the editing features you get in csDropDown work, I then did some experimenting.. Its seems the style property in the standard TComboBox has had some changes done to it which is now causing issues with descendant controls and its absolutely not Delphi compliant. Code here would never work in Delphi..

Be more precise please. Which change in TComboBox exactly broke descendant controls?
Did you verify it with a revision control tool?

Its an issue with using OwnerDraws, the key values do not align with those used in the TcomboboxEx..
 What you get is a csDropDownList instead of a csDropDown to the ancestor combobox.

Did you study the code or how did you come to those conclusions?

Oh well, QA I guess.

Questions and answers. Ok, answer my questions then.
I feel you are in a write-only mode, ignoring what other people write. Please switch to read-write mode.
Your write-only problem was especially apparent in this issue :
 https://bugs.freepascal.org/view.php?id=36899

[jamie]

 1. it isn't disputable that the Style property in the TComboBox Not the EX is not Delphi compatible. The extra feature that is an optional EDIT ownerdraw really does not work well because it is basically using a non owner draw Edit box which does not get drawn during the drawing cycle, the -1 index does appear there but this box is getting overlaid with it so before you jump all over me I think you should have a closer look at that option. Because I tried to fix the TComboBoxEX by using that option and hence that is when I noticed that issue. Most likely why Delphi does not have it.


 2. There is a problem with the TcomboboxEX. and I have got it down to a problem with the implementation of it in code. I want you to take note that recently a discussion about a READONLY property was basically squashed out, so be it. I'll just use Window messages and restrict my ambitions. But, putting that aside, the TComboBoxEX does use the READONLY property because it is actually setting it to TRUE, so what ever effect it use to have before as it was quoted as never being implemented correctly in the first place, it must of done something because its in the code..

Code: Pascal  [Select][+][-]

1. constructor TCustomComboBoxEx.Create(TheOwner: TComponent);
2. begin
3.   inherited Create(TheOwner);
4.   FAutoCompleteOptions:=cDefAutoCompOpts;
5.   FItemsEx:=TComboExItems.Create(self, TComboExItem);
6.   FNeedMeasure:=True;
7.   ReadOnly:=True;
8.   inherited Style:=csOwnerDrawFixed;
9.   FStyle:=cDefStyle;
10.   FStyleEx:=[];
11. end;
12.  
13.  

 
Here is the constructor of the control. As you can see READONLY is being used, don't ask me why I have no idea..
 Also you'll note it is setting the inherited Drawing style to csOwnerDrawFixed
etc
  So there is trouble on both sides of the street

 The TCombobox implementing features that don't exist in Delphi, which I may add aren't really working that well.

 The TComboBoxEX is using a Dead property, most likely means nothing here but it also isn't populating the Stringlist in the base class the TcustomCombobox, which is why the AutoCompleteText does not work!

 Currently I am looking at that block of code the author spent lot of time on implementing a TCollection to support the list instead if using the ITEMS stringlist in the base class. This is why the basic word search does not work!

 Unless someone else has a quick idea to fix it, it may take me a little to comeup with a proper solution.

   Have a nice day and may your bugs be many,  more..
                            

[jamie]

This corrects the problem as a test jig.. how to get this into the actual control code is another issue..
 
  This code below would need to be in several places or a Method put in that can be called in several place..

Code: Pascal  [Select][+][-]

1. procedure TForm1.ComboBoxEx1Enter(Sender: TObject);
2. var
3.   I:TCollectionItem;
4. begin
5.   with TComboBoxEx(Sender) do
6.     begin
7.       Items.Clear;
8.      For I in ItemsEx do Items.Add(TComboExItem(I).Caption);
9.     end;
10. end;                                                                    
11.  

as you can see, I first clear the base class list and then add the sub class list so that the base combobox will have a populated list.

 Also I think this method should only be called while not in DesignerMode otherwise it will just waste space or could cause some other issues..

[JuhaManninen]

Here is the constructor of the control. As you can see READONLY is being used, don't ask me why I have no idea..

Are you surely looking at the latest trunk sources?
The ReadOnly property was recently removed completely.

[jamie]

Its there, Just doesn't do anything anymore..

I am taking this from the latest release, 2.0.8. I don't do trunk work but I do look at the files and possibly make suggestion changes when I can, tested locally of course

[JuhaManninen]

I am taking this from the latest release, 2.0.8. I don't do trunk work but I do look at the files and possibly make suggestion changes when I can, tested locally of course

Uhhh...
No trunk work but you look at the files? What does that mean?

[ASerge]

I think what jamie wanted to say is that the behavior of TComboxBoxEx differs from the behavior of TComboBox in that the editing field is not available for Style=csExDropDown, although in TComboBox the field is available for Style=csDropDown. In Delphi, the edit field is available in both cases. It blames this on the Lazarus implementation and specifically the ReadOnly property, which in TComboBoxEx by default = True.

I can add more differences from Delphi: the ItemIndex property is published and plays an important role in Lazarus TComboBoxEx, and the Text property is almost always empty. In Delphi, almost the opposite is true and the ItemIndex property is left public for compatibility (but not published), but Text property always actual.

[jamie]

I have this just about completed, I will consider loading the trunk on the machine and set up the differ utility operations.

 But for now there is no difference in the trunk file verses what I have it seems..

 Currently I resolved the index out of bounds with the Sort feature, they forgot to test for index -1 when the combobox has not yet selected any content.

  I have added a line to ensure the List in the combobox base class gets updated with the sub class list per itemEx created. That seems to take care of new items coming and and also deleted items.
 
 All I need to do now is just do a clean update of the base class list after a Sort operation to make sure it reflects the current ItemsEX list order.

  if any one is interested in what I am doing I can post the INC file here, that is the only file I have changed so far.