Case sensitivy bug ?
lazarus / 31-LCL

----------------------------------------------------------------------
Blaazen · 2014-04-14 10:05

Maybe I think too much but can someone look to this LCL code ?
Code: [Select]procedure TCustomComboBox.AddHistoryItem(const Item:
string; AnObject: TObject;
  MaxHistoryCount: integer; SetAsText, CaseSensitive: boolean);
var i: integer;
begin
  // insert as first
  if (Items.Count=0)
  or (CaseSensitive and (AnsiCompareText(Items[0],Item)<>0))
  or (not CaseSensitive and (Items[0]<>Item)) then
  begin
    Items.InsertObject(0,Item,AnObject);
  end;
  // delete old
  for i:=Items.Count-1 downto 1 do begin
    if (CaseSensitive and (AnsiCompareText(Items[i],Item)=0))
    or (not CaseSensitive and (Items[i]=Item)) then
      Items.Delete(i);
  end;
  // delete overflow items
  while Items.Count>MaxHistoryCount do
    Items.Delete(Items.Count-1);
  // set as text
  if SetAsText then
    Text:=Item;
end;        

Case sensitivity in IT means that "WORD", "Word" and "word" are
different strings and case INsensitivity (i.e. not CaseSensitive)
should mean that "WORD", "Word" and "word" are same.
Is it bug ?

----------------------------------------------------------------------
Bart · 2014-04-14 10:16

I think you are right.
A second observation: Utf8CompareText should be used instead of
AnsiCompareText, since this is LCL (I guess).

Bart

----------------------------------------------------------------------
Blaazen · 2014-04-14 10:22

So it should look like this:
Code: [Select]if (Items.Count=0)
  or (not CaseSensitive and (UTF8CompareText(Items[0],Item)<>0))
  or (CaseSensitive and (Items[0]<>Item)) then

I will report it with patch.

----------------------------------------------------------------------
taazz · 2014-04-14 15:03

Personally  I wouldn't use utf8 based procedures at this point.
AnsiCompare uses the widestringmanager to do the compare which means
if you want to do utf8 comparison you just replace the relevant
procedures in the manger and you are done. To go from plugable to
static is not wise espesialy with the unicodestring change in fpc that
is coming and will require attention. In any case ansicompareTEXT
suppose to be case insensitive while ansicomparestr case sensitive so
it does require correction.

----------------------------------------------------------------------
Bart · 2014-04-15 07:37

If this is part of LCL then UTF8 functions should be used.
The entire LCL is UTF8 based.
And UTF8 functions do not depend on WS manager (so they work in Win9x
as well).

Bart

----------------------------------------------------------------------
CM630 · 2014-04-15 08:35

If utf8 is not to be used, this code
or (not CaseSensitive and (UTF8CompareText(Items[0],Item)<>0)) might
become
or (not CaseSensitive and (AnsiCompareText(lowercase(Items[0]),
lowercase (Item))<>0))
or maybe even
 or (not CaseSensitive and (lowercase(Items[0])<>lowercase(Item))<>0))
A reasonable question is which one is faster.

----------------------------------------------------------------------
zeljko · 2014-04-15 08:58

Quote from: paskal on April 15, 2014, 10:35:20 amIf utf8 is not to be
used, this code
or (not CaseSensitive and (UTF8CompareText(Items[0],Item)<>0)) might
become
or (not CaseSensitive and (AnsiCompareText(lowercase(Items[0]),
lowercase (Item))<>0))
or maybe even
 or (not CaseSensitive and (lowercase(Items[0])<>lowercase(Item))<>0))
A reasonable question is which one is faster.

But LCL uses UTF8 and case sensitive patch is valid.

----------------------------------------------------------------------
taazz · 2014-04-15 16:24

Quote from: paskal on April 15, 2014, 10:35:20 amIf utf8 is not to be
used, this code
or (not CaseSensitive and (UTF8CompareText(Items[0],Item)<>0)) might
become
or (not CaseSensitive and (AnsiCompareText(lowercase(Items[0]),
lowercase (Item))<>0))
or maybe even
 or (not CaseSensitive and (lowercase(Items[0])<>lowercase(Item))<>0))
A reasonable question is which one is faster.

As I already said AnisCompareSTR is case sensitive while
AnsiCompareTEXT is not. Quote from: zeljko on April 15, 2014, 10:58:31
amBut LCL uses UTF8 and case sensitive patch is valid.
I would expect that the moment a unicode aware version of FPC is
released that LCL will revert to the more logical use of the
WideStringManager for its unicode needs (at least in memory) which
will give us a small but needed speed bust when dealing with system
unicode APIs.