Recent

Author Topic: Issues with new strings of FPC trunk  (Read 27038 times)

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4459
  • I like bugs.
Re: Issues with new strings of FPC trunk
« Reply #60 on: July 05, 2015, 01:56:48 pm »
I'd be willing to port LCL to UTF16 aswell as WIN32SDK.

Good.
Mostly Lazarus trunk and FPC 3.2 on Manjaro Linux 64-bit.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Issues with new strings of FPC trunk
« Reply #61 on: July 05, 2015, 01:59:34 pm »
So there is a conversion going inside in the LCL from UTF8 <> UTF16? How often are these conversions?
everytime you talk to any windows api.

A string using or producing winapi function.

taazz

  • Hero Member
  • *****
  • Posts: 5368
Re: Issues with new strings of FPC trunk
« Reply #62 on: July 05, 2015, 02:10:00 pm »
So there is a conversion going inside in the LCL from UTF8 <> UTF16? How often are these conversions?
everytime you talk to any windows api.

A string using or producing winapi function.
well isn't that a common sense if the api call does not use strings only numbers then there is no string convertion needed or something as trivial as that needs to be clarified too? Sorry this is the second comment with the same logic so I need to make sure.
Good judgement is the result of experience … Experience is the result of bad judgement.

OS : Windows 7 64 bit
Laz: Lazarus 1.4.4 FPC 2.6.4 i386-win32-win32/win64

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Issues with new strings of FPC trunk
« Reply #63 on: July 05, 2015, 02:11:21 pm »
I'd be willing to port LCL to UTF16 as well as WIN32SDK.

What do you mean with win32sdk?

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4459
  • I like bugs.
Re: Issues with new strings of FPC trunk
« Reply #64 on: July 05, 2015, 02:14:52 pm »
Code: [Select]
procedure TForm1.Button1Click(Sender: TObject);
var ws: widestring;
var s: string;
begin
  ws := 'test';
  s := UTF8Encode(ws);
  ShowMessage('CP=' + IntToStr(StringCodePage(s)));
  s := s + ' finished';
  ShowMessage('CP=' + IntToStr(StringCodePage(s)));
end;

The first value is CP_UTF8=65001, but the second one is back again 1252 (if 1252 is your Windows active code page).

Correction: you also need -dEnableUTF8RTL. Only -FcUTF8 is not enough because FPC will convert the UTF-8 constant to the native encoding of type String which is then Ansi codepage 1252.
This has been the source of complication and confusion all the time in your experiments. You try to use Lazarus with FPC 3.x without using -dEnableUTF8RTL. Sure you can experiment with it but now you make things look very complicated for people who only want to find the simplest way to use Unicode with Lazarus.
The simplest way is -dEnableUTF8RTL!
For example the new user "otoien" is completely confused now (thread "How to use new RTL unicode string support with ANSI (CP1252) file input/output?").
In future please open separate threads for issues with -dEnableUTF8RTL and without it. When experimenting without it, you should mention that it is not a supported nor recommended way!
Using Lazarus with FPC 3.x without -dEnableUTF8RTL is a swamp. You are on your own then.
-dEnableUTF8RTL was created by clever Lazarus developers (mostly Mattias) just to prevent the problems you are facing in your experiments.
« Last Edit: July 05, 2015, 02:44:36 pm by JuhaManninen »
Mostly Lazarus trunk and FPC 3.2 on Manjaro Linux 64-bit.

rtusrghsdfhsfdhsdfhsfdhs

  • Full Member
  • ***
  • Posts: 162
Re: Issues with new strings of FPC trunk
« Reply #65 on: July 05, 2015, 03:03:56 pm »
I'd be willing to port LCL to UTF16 as well as WIN32SDK.

What do you mean with win32sdk?

WIN32SDK headers? AFAIK FPC isn't even VISTA ready while WIN10 is about to get released..

I don't know why such fuss about this UTF8. QT / Windows has been UTF16 since the 90's
« Last Edit: July 05, 2015, 03:07:37 pm by Fiji »

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Issues with new strings of FPC trunk
« Reply #66 on: July 05, 2015, 03:33:07 pm »

Quote
What do you mean with win32sdk?

WIN32SDK headers? AFAIK FPC isn't even VISTA ready while WIN10 is about to get released..

Calls and structs are added on a need basis, so there is no milestone concept to be "ready" for.

Winapi mutations are usually merged back with new FPC point releases, whose long term average is about 9months. The current 3.x headers can already be recompiled to have the -W headers and structures by default.

Just post improvement in not too big batches that don't change anything unnecessarily to the bugtracker, and I'll take care of them.

Quote
I don't know why such fuss about this UTF8. QT / Windows has been UTF16 since the 90's

The webpeople are UTF8 obsessed, simply because of their open source *nix origin which never warmed to utf16, simply because they can't manage big changes, only gradual ones.

And the other people systematically confuse preferred encoding for documents (including html) with API and application internal encodings.
« Last Edit: July 05, 2015, 05:49:02 pm by marcov »

wp

  • Hero Member
  • *****
  • Posts: 11857
Re: Issues with new strings of FPC trunk
« Reply #67 on: July 05, 2015, 05:02:21 pm »
Quote from: JuhaManninen
You try to use Lazarus with FPC 3.x without using -dEnableUTF8RTL. Sure you can experiment with it but now you make things look very complicated for people who only want to find the simplest way to use Unicode with Lazarus.
The simplest way is -dEnableUTF8RTL!
Sorry to confuse people with this thread, but my initial question was on a bug in fpspreadsheet. Since this is a library I do not have the option to force users to use fpc 3.x with EnableUTF8RTL on. fpspreadsheet must work in every reasonable environment, and in fact it now does from Laz 1.5/fpc 3.0x EnableUTF8RTL on/off back to Laz1.0/FPC 2.6.0, thanks to this discussion.

I do confirm that everything is fine with fpc3.x / EnableUTF8RTL active.

 

TinyPortal © 2005-2018