On 02/12/2016 06:13 PM, Juha Manninen wrote:
On Fri, Feb 12, 2016 at 6:52 PM, Michael Schnell <[email protected]> wrote:
I think that it is *very* desirable to provide configuration options to
provide full backwards compatibility (while still allow to use as many of
the new features as possible when explicitly writing coding for this).
Uhhh...
Michael Schnell, how is it possible you behave like a complete newbie
with FPC's String encoding issues, after so many years of arguing
about it in various mailing lists?
because of this:
On 02/12/2016 03:50 PM, Michael Van Canneyt wrote:
Then you are, as they say, f*d...
On 02/12/2016 06:13 PM, Juha Manninen wrote:
... were answered in the wiki pages I linked to you, and they are
obvious after just minimal testing.
This is what I did assume and just wanted a confirmation for, so that I
can send this information in a compact and approved form to the said
friend .
If you find a bug then let us know, otherwise please show some
positive attitude. The new UTF-8 system "just works" in most
situations.
Sorry I did not intend to express any negative attitude, but on the
contrary am very happy that Lazarus/fpc can provide exactly that
functionality (8 bit Strings - including TStrins, pos , etc - in a 64
Bit application) that (AFAIK ) is not possible with Delphi (which I
don't have).
I remember you repeated the same arguments against FPC's new String
type in FPC lists during many years again and again.
Let's not do the same here.
IMHO your memory is incomplete on that behalf. On the contrary I
argumented against the "intermediate" Lazarus way of using UTF8
*without* "new strings" (which - as you correctly say, seemingly is
exactly hat my said friend would like to use (but here, he does not care
about the LCL GUI functions). In fact I always was pro "New Strings",
Later I argumented against the way New Strings have been implemented
(very close to the "sloppy" way Delphi does this), which (among other
IMHO not really good stuff) does not provide for using TStrings for
"uncoded" / "unkowinly coded / "transparently coded" 8 bit strings. As
you might know I did a description of an IMHO better way to do this
here:
http://wiki.lazarus.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support
.
-Michael
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus