Zvone wrote:
TBytes was the datatype to be used. However that would break
backwards compatibility since historically string was used
everywhere. That all was no problem, however the rule is: DO NOT
BREAK BACKWARDS COMPATIBILITY and that is where the problems begin.
Well you've already
Hello Zvone,
Yes, the Unicode implementation of the POP3 client is weak.
It converts the bytes received to Unicode with current Ansi
system codepage. This is direct result of ICS rule #1 to not
break backwards compatibility.
However, as long as this codepage was one of the windows-xyz,
single
Zvone wrote:
However, as long as this codepage was one of the windows-xyz,
single byte character sets converting back to Ansi with the
same codepage should work without data loss and give you back
the raw bytes (hopefully). This won't work, for example, with
Japanese locale settings.
But
TBytes was the datatype to be used. However that would break
backwards compatibility since historically string was used everywhere.
That all was no problem, however the rule is: DO NOT BREAK BACKWARDS
COMPATIBILITY and that is where the problems begin.
Well you've already broken this rule by
OK, I have an issue which I don't entirely understand.
The way to check received pop3 message is to create Pop3CliMessageLine event
and then add Pop3Cli.LastResponse to your own buffer (UnicodeString) and
store that as email.
However, this creates a bit of a problem - LastResponse is