TMemo's empty last line

[Graeme]

I guess it's because its backend, which is a TStrings descendant, behaves that way.

Rubbish! When you create a new TStrings or TStringList, the line count is 0 (no text at all).  It is VCL or LCL that injects text into the Memo.Lines property at creation of the Memo component.

[jc99]

Rubbish! When you create a new TStrings or TStringList, the line count is 0 (no text at all).  It is VCL or LCL that injects text into the Memo.Lines property at creation of the Memo component.

Hey keep the temper down.
Have you even tried, what you caim ?
I tried, they behave EXACTLY the same on adding text.
The only difference is, that you can't get rid of the last CRLF with trimright.
In TStringList the LineEnding seems to be hard-coded the "End-of-the-Line".

[..]
If you do the following on a newly created Memo (as shown above) and execute the following code...

Code: [Select]

procedure TMainForm.ButtonClicked(Sender: TObject);
begin
  Memo1.Clear;
  ShowMessage(IntToStr(Memo1.Lines.Count));
  Memo1.Lines.Add('new line');
  ShowMessage(IntToStr(Memo1.Lines.Count));
end;

The results would be 0 and then 1.

The results are 0 and then 1.
But ...
Memo1.Lines.Text is 'new line'+LineEnding; !!
You see 2 lines, but you actually have only one, with LineEnding at the end.
 
By the way that stupid 'Memo1' as a start is not added by default of the wigetset, it is inserted because you didn't cleared Lines property in the Designer. YOU can put there whatever you like, even rubbish or nothing.

[Graeme]

Have you even tried, what you caim ?

Yes I did.

Memo1.Lines.Text is 'new line'+LineEnding; !!
You see 2 lines, but you actually have only one, with LineEnding at the end.

If you bothered to try it in fpGUI you would have noticed that what you said is NOT true with fpGUI. If you run the sample code I listed, you have exactly 1 line of text in the memo. To get to line 2, YOU the user need to press the Enter key. Simply clicking with the mouse, you will only be able to place the cursor on line 1, because there is only one line of text.

By the way that stupid 'Memo1' as a start is not added by default of the wigetset,

It is inserted by the VCL or LCL forms designer - forcing the developer to manually go and clear something that the form designer inserted. Such a stupid idea - hence the fpGUI UI Designer does NOT insert such pointless lines of text.

[jc99]

If you had read my reply right I was not referring to fpGUI but to TStringList.

You are right, I didn't use fpGui, but i never said, I did.
I used delphi, win32, win64, in lazarus, all with the same result.
maybe fpGui has a compatibility-issue here.

And as I said before, please keep your tamper down.

BTW. Inserting the Name of the Control as default text is also done in all of these,
  maybe there is a compatibility issue here too.

[eny]

And as I said before, please keep your tamper down.

http://learning.colostate.edu/guides/guide.cfm?guideid=4

[lagprogramming]

   As I understand, this behaviour is implemented in Lazarus in order to be compatible with Delphi. Unlike Lazarus, fpGui acts differently, probably mseIDE, too. Each project implements it's own philosophy and it's good to know that there is diversity. There is a single situation where Lazarus's behaviour doesn't fit very well the needs: form with multiple vertically arranged Memos that have vertical scrollbars and approximately the same number of lines as memo's rows. This is an unpleasant situation(situation that I've encountered), but it's a situation with few chances to be encountered by other developers.
   Thank you very much for your replies, they cleared things up to me.

[Graeme]

If you had read my reply right I was not referring to fpGUI but to TStringList.

Then please take a look at the implementation of TStringList in Free Pascal. The TStringList.Add(...) boils down to the following code:

Code: [Select]

Procedure TStringList.InsertItem(Index: Integer; const S: string; O: TObject);
begin
  Changing;
  If FCount=Fcapacity then Grow;
  If Index<FCount then
    System.Move (FList^[Index],FList^[Index+1],
                 (FCount-Index)*SizeOf(TStringItem));
  Pointer(Flist^[Index].Fstring):=Nil;  // Needed to initialize...
  Flist^[Index].FString:=S;
  Flist^[Index].FObject:=O;
  Inc(FCount);
  Changed;
end;

Nowhere in there do you see a LineEnding character being appended to the S parameter contents. So if a LineEnding character is added to the TMemo, then it is LCL that injects that extra text, not the TStringList.

[jc99]

No, but it's in TStrings.GetTextStr
file: stringl.inc (line 463 ff)

Code: [Select]

Function TStrings.GetTextStr: string;

Var P : Pchar;
    I,L,NLS : Longint;
    S,NL : String;

begin
  CheckSpecialChars;
  // Determine needed place
  Case FLBS of
    tlbsLF   : NL:=#10;
    tlbsCRLF : NL:=#13#10;
    tlbsCR   : NL:=#13;
  end;
  L:=0;
  NLS:=Length(NL);
  For I:=0 to count-1 do
    L:=L+Length(Strings[i])+NLS;
  Setlength(Result,L);
  P:=Pointer(Result);
  For i:=0 To count-1 do
    begin
    S:=Strings;
    L:=Length(S);
    if L<>0 then
      System.Move(Pointer(S)^,P^,L);
    P:=P+L;
    For L:=1 to NLS do
      begin
      P^:=NL[L];
      inc(P);
      end;
    end;
end;


[Graeme]

No, but it's in TStrings.GetTextStr
file: stringl.inc (line 463 ff)

That is only if you reference all the content via the Text property. How else is TStrings supposed to differentiated between individual lines of text, if you ask for all the data return at once.

Alternatively, you can query the data line by line in a loop, which means there will be no LineEnding character appended for each line returned. The point is, by adding text it doesn't add a LineEnding character. On returning data, you as a developer have a choice - all in one go (which means it needs to somehow delimit each line), or line by line.

Regards,
  Graeme