Upgrade to Lazarus 3.0.2 Unicode

[Eduards]

Hi,

For long time I was holding back from migrating to latest version of Lazarus, because it breaks my code. Well, I am doing it now, and would like your input about least painful way to do it.

My project has data in dozen of text files saved in ANSI, containing Latvian characters. It produces single ICS calendar format file, for later import in some calendar app. It has a lot SysToUTF8, UTF8ToSys, AnsiToUTF8, UTF8ToAnsi functions writen year of two ago. It worked and was forgotten. As I understand Lazarus does at least some of this stuff automatically now. After Lazarus update practically all text on form is broken- hints, stringgrid cellls, button captions etc. A lot of this data comes from data files. I suspect there might be some unnecessary conversions back an forth as well, like read from file as format A, store in array as B, display again as A.

Another example, before in Lazarus 1.4.4 name := UTF8ToAnsi('āaēšķņēp') was displayed correctly, written to file correctly. Now name := 'āaēšķņēp' displays correct, exports to file wrong.

I could, but I am hesitant to convert all my data files manually from ANSI to UTF8 (some script?) because over the years I have lot of them. If that simplifies code, might be worth it.

[Handoko]

You may want to use Fpcupdeluxe. It will perform isolated install and allow you to install many versions of Lazarus/FPC.

http://forum.lazarus-ide.org/index.php/topic,35743.msg236888.html#msg236888

[marcov]

It is possible to use FPC 3 based Lazarus versions as before FPC 3 for existing projects.

It requires some fiddling in the .lpr described here

[JuhaManninen]

I could, but I am hesitant to convert all my data files manually from ANSI to UTF8 (some script?) because over the years I have lot of them.

You wrote you have a dozen of them which is not a lot IMO. Any decent text editor can convert the encoding, including the editor in Lazarus itself.
It is time we get rid of the horrors of Windows system code pages and broken text caused by it. You should convert to Unicode!

If that simplifies code, might be worth it.

Yes it simplifies a lot. Then everything just works. No explicit conversion functions are needed. You can pretty much forget all encoding issues.

[Eduards]

I did convert all files. Turned out to be more than hundred, actually. Some had symbols mixed symbols from different encodings due to bug half a year ago, so I replaced these too. With all data files 100% UTF8 I could completely remove all encoding functions. All of them, and it just worked! Only ones I did not touch was for UTF8ToAnsi for SaveDialog  and OpenDialog file names.

[JuhaManninen]

I did convert all files. Turned out to be more than hundred, actually. Some had symbols mixed symbols from different encodings due to bug half a year ago, so I replaced these too. With all data files 100% UTF8 I could completely remove all encoding functions. All of them, and it just worked!

Cool! I am happy for you!

Only ones I did not touch was for UTF8ToAnsi for SaveDialog  and OpenDialog file names.

Why would you need UTF8ToAnsi there? LCL uses UTF-8 everywhere, including SaveDialog and OpenDialog.

[Eduards]

Why would you need UTF8ToAnsi there? LCL uses UTF-8 everywhere, including SaveDialog and OpenDialog.

I removed these functions, and yes, works as expected.

I am using unit initially written for Delphi which works with no modifications. That unit has a lot of WideStrings and compiler gives may warnings about  "implicit string type conversion with potential data loss from "WideString" to "AnsiString". May I replace them with simple strings in that unit?

[Thaddy]

I am using unit initially written for Delphi which works with no modifications. That unit has a lot of WideStrings and compiler gives may warnings about  "implicit string type conversion with potential data loss from "WideString" to "AnsiString". May I replace them with simple strings in that unit?

What Delphi version? If it was initially written for D2007 and below, you may try

Code: Pascal  [Select][+][-]

1. {$ifdef fpc}{$Mode delphi}{$codepage utf8}{$H+}{$endif}

on top of your unit. Order is important! Mode first, codepage later.
You may also try

Code: Pascal  [Select][+][-]

1. {$mode delphiunicode}

but that can cause other problems because that means strings are UTF16 and Lazarus uses  ...... UTF8.
That should not lead to many conversions that can loose information, though.

You mention WideStrings... well, that's old Delphi and Old FPC. You should use UnicodeString and UnicodeChar where applicable. Also in Delphi.
In DelphiUnicode mode string=unicodestring (UTF16) automatically.

[JuhaManninen]

You should not use {$mode delphiunicode} nor codepage settings.
The UTF8 system used in Lazarus works well, you just must assign a string constant always to type "String" variable and use type UnicodeString explicitly for WinAPI function parameters.
Amazingly the code is then compatible with Delphi at source level despite different encodings.
It is all explained here:
 http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus

The 100% Delphi compatible UTF16 system is still far future. RTL and other libs are under construction.
Using {$mode delphiunicode} now causes trouble.