Windows TMemo makes linebreaks on word wraps

[edvard]

OK, this is weird.  I had a friend test my new app on his Windows machine, and this is what he discovered: When loading the contents of a TMemo into a stringlist, word wraps will become newlines, and sometimes extra text will be added.  I have 'WordWrap' set to true in the properties of the TMemo, but it still does it.
Try this test:
Put a TMemo and a Button on a form.  Set the TMemo Width to 150.
For Button1 'OnClick" put in this code:

Code: [Select]

procedure TForm1.Button1Click(Sender: TObject);
var
  MemoTxt: TStringList;
  i: integer;
begin
  MemoTxt:= TStringList.Create;
  Try
    for i:= 0 to Memo1.Lines.Count do
    MemoTxt.Add(Memo1.Lines[i]);
    MemoTxt.SaveToFile('C:\Temp\test.txt');
  finally
    MemoTxt.Free;
  end;
end;
Then type in some nonsensical line that wraps around the window a couple times, and open the text file in C:\Temp.  Just for this test, I typed in "Momma told me there'd be days like this, but I never believed her, so here I am today"
What I got when I opened C:\Temp\test.txt:

Momma told me there'd be
days like this, but I never
believed her, so here I am
today.
●oday.

I don't know what the deal is with the last repeating line with a unicode "Black Circle" replacing the first character, different phrases sometimes came up with no extra lines, some came up with other characters, all in the first position like that.
My point is that this breaks my program for Windows; in Linux it works just fine.  Does anybody have any suggestions, workarounds, or am I just doing this wrong?
Thanks.

[User137]

You don't need a TStringList step as they are both inherited from TStrings. You can use this:

Code: [Select]

memo1.Lines.SaveToFile(...);

[Bart]

When words are wrapped onto a new line, then Windows reports this as a separate Line in TMemo (this, btw is Delphi compatible).
Other widgetsets may not do that.
So: a TMemo with 1 long line and WordWrap = False:
Lines.Count = 1
Lines[0] = the long line

Now set WordWrap :=  True
Lines.Count = 2 //maybe more, depending on how long the line actually is
Lines[0] = the first part of the long line
Lines[1] = the second part of the long line

(Again: as in Delphi)

In e.g. Linux/GTK2 it is diferent (see this bugreport).
There Count will remain 1 and Line[0] holds the entire (wrapped) text.

If you want to have the Lines in a TStringList try

Code: [Select]

  MyStringList.Strings.Assign(Memo1.Lines);
  //or
  MyStringList.Text := Memo1.Text; //The Text property of the TMemo will not have the line-endings for wrapped lines

Or use a TTextStrings as a container (IIRC it "compensates" for this TMemo behaviour)

Code: [Select]

var
  TS: TTextStrings;
begin
  TS := TTextString.Create;
  TS.Strings.Assign(Memo1.Lines);
  //do stuff with TS
  TS.Free
end;

Anyway: why the need to have the Lines in another container?
As pointed out, it is not necessary for SaveToFile, nor for manipulating the strings.

Bart

[edvard]

When words are wrapped onto a new line, then Windows reports this as a separate Line in TMemo (this, btw is Delphi compatible).

That's the intended behavior?   

In e.g. Linux/GTK2 it is diferent (see this bugreport).

Hmmm... seems breaking lines where you didn't intend to would more likely be a bug to me.  In my opinion, it should keep whatever formatting you put in without creating unexpected 'additions'.

Anyway: why the need to have the Lines in another container?

Hard to explain here, but basically I am doing URL encoding on the lines, and it's easier to read (maintain) if I do the processing on a variable with a shorter, more descriptive name.  Also, I like to keep the 'GUI' and 'Engine' in separate units, and I don't like to make circular 'Uses', so I do a lot of passing to functions.  The test code is more reflective of what's happening, not how I actually coded this particular bit.

Thanks for the workaround, I'll be using that.   

[typo]

That's the intended behavior?   

Yes, of course. It is an OS feature, AFAIK.

[edvard]

Hehe, feature <> bug