On Wed, 06 Apr 2016 15:05:02 +0200
tobiasgie...@gmail.com wrote:
> Hello,
>
> Jonas wrote:
> > If you get ASCII, it means that one of the LC_ALL, LC_CTYPE and/or LANG
> > environment variables is set to
> > a setting that corresponds to ASCII (such as "C"), or set to a value that
> > is not re
tobiasgiesen wrote on Wed, 06 Apr 2016:
Jonas wrote:
If you get ASCII, it means that one of the LC_ALL, LC_CTYPE and/or
LANG environment variables is set to
a setting that corresponds to ASCII (such as "C"), or set to a
value that is not recognised as or translatable into
a Windows code pa
Hello,
Jonas wrote:
> If you get ASCII, it means that one of the LC_ALL, LC_CTYPE and/or LANG
> environment variables is set to
> a setting that corresponds to ASCII (such as "C"), or set to a value that is
> not recognised as or translatable into
> a Windows code page number.
That was it - o
On 04/04/2016 06:23 AM, tobiasgie...@gmail.com wrote:
OK, I just confirmed. Adding clocale to my 5-line test program doesn't
affect the DefaultSystemCodePage result, but as soon as I add cwstring to
the uses clause, then DefaultSystemCodePage returns 65001.
On Mac, not even cwstring does that.
tobiasgiesen wrote on Mon, 04 Apr 2016:
> Terminal has LC_CTYPE=UTF-8.
What about LC_ALL?
My Mac OS installations do not have LC_ALL.
But I just noticed that Carbon GUI programs do not get LC_CTYPE in their
environment either.
If none of the environment variables related to code pages are
> > Terminal has LC_CTYPE=UTF-8.
>
> What about LC_ALL?
My Mac OS installations do not have LC_ALL.
But I just noticed that Carbon GUI programs do not get LC_CTYPE in their
environment either.
So maybe cwstring needs to be fixed for Carbon GUI Mac OS X programs.
What I see in the environment
tobiasgiesen wrote on Mon, 04 Apr 2016:
How did you get a codepage 20127 Mac?
The Mac is UTF-8,
This statement makes no sense. There is no "UTF-8" or "non-UTF-8" Mac.
The Unix environment on OS X can use any OS-supported code page.
but cwstring or whatever does not realize it.
cwstri
> How did you get a codepage 20127 Mac?
The Mac is UTF-8, but cwstring or whatever does not realize it.
Since I cannot easily step into it with the debugger, I can't tell you
why.
Terminal has LC_CTYPE=UTF-8.
Well I will just set the default codepages manually.
Cheers,
Tobias
On Mon, 4 Apr 2016 11:34:18 +0100
Graeme Geldenhuys wrote:
> On 2016-04-04 11:23, tobiasgie...@gmail.com wrote:
> > On Mac, not even cwstring does that. It sets the DefaultSystemCodePage
> > to 20127.
>
> I just installed FPC 3.0 on my Macbook Pro (bought in the UK) and did
> the same test. Here
On 2016-04-04 11:23, tobiasgie...@gmail.com wrote:
> On Mac, not even cwstring does that. It sets the DefaultSystemCodePage
> to 20127.
I just installed FPC 3.0 on my Macbook Pro (bought in the UK) and did
the same test. Here DefaultSystemCodePage returned 65001. So I guess it
depends on your OSX
> OK, I just confirmed. Adding clocale to my 5-line test program doesn't
> affect the DefaultSystemCodePage result, but as soon as I add cwstring
> to the uses clause, then DefaultSystemCodePage returns 65001.
On Mac, not even cwstring does that. It sets the DefaultSystemCodePage
to 20127.
So, on
On 2016-04-04 11:07, Michael Van Canneyt wrote:
> if you are dealing with UTF8/UnicodeString and other codepages, it is
> quite likely, and preferred, that you have unit cwstring included.
OK, I just confirmed. Adding clocale to my 5-line test program doesn't
affect the DefaultSystemCodePage resul
On Mon, 4 Apr 2016, Graeme Geldenhuys wrote:
On 2016-04-04 10:39, tobiasgie...@gmail.com wrote:
It says "On Linux and Mac OS X UTF-8 is typically the system codepage, so the
RTL uses
here by default CP_UTF8."
Not on my Mac. DefaultSystemCodePage is 20127 before I set it to 65001.
Indeed,
13 matches
Mail list logo
