As probably all users here, we have a Delphi background

I just lost quite some time to find out, why two strings, that are the
same are not the same.

My EWB app communicates with a server written in Delphi / Indy.
Basically I post values as TStringList to the server and create the
response as a TStringList on the server as well.

In Delphi, the default line separator is CRLF, but if you assign a
value to TStringList.Text, Delphi handles both (CRLF and LF) if the
LineSeparator is CRLF.

In EWB the default line separator is LF. So when I read the
ResponseContent, every string has a CR at the end. And you don't see
this CR if you use LogOutput or in the Chrome debugger:

str1   :   'TEST'
str2   :   'TEST'#A

Now I understand, that Web comes from Linux and there the LF is
common. But EWB is close to Delphi and runs on Windows, so I ask
myself, if the default line separator shouldn't be CRLF as well. Or at
least a similar behaviour as Delphi in SetText(): Treat CRLF and LF
the same way.

cu Christian


BTW Tim: I noticed that there are two implementations for
TStrings.SetText in the code. Shouldn't the compiler complain about
that?

> Now I understand, that Web comes from Linux and there the LF is
> common. But EWB is close to Delphi and runs on Windows, so I ask
> myself, if the default line separator shouldn't be CRLF as well. Or
> at
> least a similar behaviour as Delphi in SetText(): Treat CRLF and LF
> the same way.

I fell over this with Trim, which doesn't trim the linefeeds. I think that I'd
suggest that EWB framework should automatically strip the CR character from lines
if present in the source data. Or at least have a "tidy" function that can be
called when you have assigned new data from another source.

/Matthew Jones/

Christian,

<< Now I understand, that Web comes from Linux and there the LF is common.
But EWB is close to Delphi and runs on Windows, so I ask myself, if the
default line separator shouldn't be CRLF as well. >>

This was a decision that was made early on to be compatible with the way
that memo controls worked.  Unfortunately, I can't really change it until a
subsequent minor release, but I'll consider doing so.

<< BTW Tim: I noticed that there are two implementations for
TStrings.SetText in the code. Shouldn't the compiler complain about that? >>

Yes, it should.  In fact, this was reported once before, so I'm not sure why
it's doing that again.  The problem may be in the automatic overload code.

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com