MaxLength property of TMemo

[fedkad]

I think the MaxLength property of TMemo is quite messed up.

On Windows it specifies the number of characters (=codepoints) not bytes. So, using the keyboard, you can enter the characters ÇÖÜçö in a memo with MaxLength of 5. However, programmatically (Memo1.Lines.Text := '1234567890';) you can enter more than MaxLength characters into the same memo; there is no control.

In Linux it is quite different. You can enter only 4 non-ASCII characters (e.g. ÇÖÜç) with the keyboard. And only 2 non-ASCII characters (e.g. ÇÖ) by pasting (CTRL+V) and programmatically (Memo1.Lines.Text := 'öç';). However after entering those two characters you can continue by entering 2 or 3 more characters from the keyboard depending on these being ASCII or non-ASCII:
öçüÖ
öçabc
öçüÖa
etc.

In Linux, programmatically trying to replace the characters in a memo (Memo1.Lines.Text := 'öçü'; //more than allowed?) will clear the memo contents, but will not insert anything; leaving you with a empty memo content.

So, in Windows there is no check on the length of data inserted programmatically (I assume it is left to the programmer); however, in Linux it is somehow checked, but very badly!

[ASerge]

On Windows ...However, programmatically (Memo1.Lines.Text := '1234567890';) you can enter more than MaxLength characters into the same memo; there is no control.

Added bug and patch to it.

[jamie]

The MaxLength effects the USER input not the Assigned text via code..

Its clearly documented in the Delphi Help I have..

Running test here it shows that is what it's doing..

But I did notice an issue, if I set it to 10 for example, I can only type in up to 8

but outside of that it is doing exactly as my Delphi doc's state.

 As for the miss fire of position count, looks like utf8 is getting in the way, maybe the
EM_CHARFROMPOS would report a more accurate value ?

[fedkad]

I may accept the Windows behavior. But, in Linux we have serious troubles. Especially, when your are programmatically trying to replace the characters in a memo with something longer than allowed: Lazarus will clear the memo contents, but will not insert anything; leaving you with a empty memo content (data loss!).

Another problem is also that Linux behaves unreliably for the OnChange event of TMemo (which may be used to test oversized memo contents): When there are no contents in a memo and you try to enter some text to it programmatically, the OnChange event is not fired. In other cases that I have tested (when there is content in the memo and you try to replace or add text in it programmatically or through the keyboard) the OnChange is fired. (Is this another bug in Linux?)

Windows behaves again consistently by firing the OnChange event always (as expected).

[ASerge]

The MaxLength effects the USER input not the Assigned text via code..
Its clearly documented in the Delphi Help I have..

From Lazarus doc:

In Delphi MaxLength only limits user input. The LCL instead restricts the maximum length of the contained text; this simplifies the implementation for non-Win32 widgetsets.

[jamie]

If that being the case then why does the current implementation behave like Delphi with the
exception of the count not be exactly correct but effectively doing the same as Delphi?

  This would cause a porting issue, I thought the goal was to be Delphi compatible ?

  If Buffer size is what LCL is trying to convey then why didn't they add a property called
MaxBuffer ?
 
  What ever, just another compatibility issue..