Recent

Author Topic: Case sensitivy bug ?  (Read 4666 times)

Blaazen

  • Hero Member
  • *****
  • Posts: 3237
  • POKE 54296,15
    • Eye-Candy Controls
Case sensitivy bug ?
« on: April 14, 2014, 12:05:46 pm »
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 ?
Lazarus 2.3.0 (rev main-2_3-2863...) FPC 3.3.1 x86_64-linux-qt Chakra, Qt 4.8.7/5.13.2, Plasma 5.17.3
Lazarus 1.8.2 r57369 FPC 3.0.4 i386-win32-win32/win64 Wine 3.21

Try Eye-Candy Controls: https://sourceforge.net/projects/eccontrols/files/

Bart

  • Hero Member
  • *****
  • Posts: 5275
    • Bart en Mariska's Webstek
Re: Case sensitivy bug ?
« Reply #1 on: April 14, 2014, 12:16:00 pm »
I think you are right.
A second observation: Utf8CompareText should be used instead of AnsiCompareText, since this is LCL (I guess).

Bart

Blaazen

  • Hero Member
  • *****
  • Posts: 3237
  • POKE 54296,15
    • Eye-Candy Controls
Re: Case sensitivy bug ?
« Reply #2 on: April 14, 2014, 12:22:35 pm »
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.
Lazarus 2.3.0 (rev main-2_3-2863...) FPC 3.3.1 x86_64-linux-qt Chakra, Qt 4.8.7/5.13.2, Plasma 5.17.3
Lazarus 1.8.2 r57369 FPC 3.0.4 i386-win32-win32/win64 Wine 3.21

Try Eye-Candy Controls: https://sourceforge.net/projects/eccontrols/files/

taazz

  • Hero Member
  • *****
  • Posts: 5368
Re: Case sensitivy bug ?
« Reply #3 on: April 14, 2014, 05:03:03 pm »
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.
Good judgement is the result of experience … Experience is the result of bad judgement.

OS : Windows 7 64 bit
Laz: Lazarus 1.4.4 FPC 2.6.4 i386-win32-win32/win64

Bart

  • Hero Member
  • *****
  • Posts: 5275
    • Bart en Mariska's Webstek
Re: Case sensitivy bug ?
« Reply #4 on: April 15, 2014, 09:37:13 am »
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

  • Hero Member
  • *****
  • Posts: 1082
  • Не съм сигурен, че те разбирам.
    • http://sourceforge.net/u/cm630/profile/
Re: Case sensitivy bug ?
« Reply #5 on: April 15, 2014, 10:35:20 am »
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.
Лазар 3,2 32 bit (sometimes 64 bit); FPC3,2,2; rev: Lazarus_3_0 on Win10 64bit.

zeljko

  • Hero Member
  • *****
  • Posts: 1594
    • http://wiki.lazarus.freepascal.org/User:Zeljan
Re: Case sensitivy bug ?
« Reply #6 on: April 15, 2014, 10:58:31 am »
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.

But LCL uses UTF8 and case sensitive patch is valid.

taazz

  • Hero Member
  • *****
  • Posts: 5368
Re: Case sensitivy bug ?
« Reply #7 on: April 15, 2014, 06:24:58 pm »
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.

As I already said AnisCompareSTR is case sensitive while AnsiCompareTEXT is not.
But 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.
Good judgement is the result of experience … Experience is the result of bad judgement.

OS : Windows 7 64 bit
Laz: Lazarus 1.4.4 FPC 2.6.4 i386-win32-win32/win64

 

TinyPortal © 2005-2018