Sven Barth wrote:
On 26.11.2014 16:54, Hans-Peter Diettrich wrote:
When the system does not notify all other (running) programs of such an
global change, or when some other stupid program doesn't know how to
deal with changed settings, the user better shuts down and restarts his
system, before a
On 26.11.2014 19:54, Hans-Peter Diettrich wrote:
UTF-16 is not a valid value for CP_ACP in Delphi, because it's a 2-byte
encoding. Even if the Delphi architects may have thought about an common
string type, with a variable element size (1,2,4), this certainly turned
out soon as a stupid idea, so
On 26.11.2014 16:54, Hans-Peter Diettrich wrote:
When the system does not notify all other (running) programs of such an
global change, or when some other stupid program doesn't know how to
deal with changed settings, the user better shuts down and restarts his
system, before and after using that
On 26 November 2014 at 23:54, Hans-Peter Diettrich
wrote:
> Conclusion:
> Proper handling of separators in formatted numbers is essential, or else
> users may run into so big trouble, that they will drop your program as
> unusable.
>
> DoDi
>
(renamed subject due to change in topic)
I hear you,
2014-11-26 5:21 GMT-03:00 Michael Van Canneyt :
> On Tue, 25 Nov 2014, luiz americo pereira camara wrote:
>
>> I went to \packages\fcl-base dir and run make PP="my271compilerpath" and
>> i got:
>>
>> Start compiling package fcl-base for target i386-win32.
>>Compiling BuildUnit_fcl_base.pp
Jonas Maebe schrieb:
On 26/11/14 17:41, Tomas Hajny wrote:
BTW, in this context - can users choose UTF16BE on little endian
platforms (and vice versa)?
No, because we do not have any routines that allow a user to set/change
the codepage of a unicodestring (either at run time or at compile time
Jonas Maebe schrieb:
Technically, that section literally states that they will be
concatenated without data loss and that the result is then converted to
the target string's encoding (except in case the target is
RawByteString). How that is implemented exactly is undefined; again in
the meaning
Michael Schnell schrieb:
So seemingly you could do MyStringType = type
AnsiString(CP_UTF16), and seemingly the size information is set
according to this.
Not in Delphi XE.
DoDi
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http:/
On Wed, 26 Nov 2014 15:34:19 +0100
Hans-Peter Diettrich wrote:
> Mattias Gaertner schrieb:
> > Hi,
> >
> > The page about "FPC Unicode support" mentions what has already been
> > updated to preserve character data.
> > http://wiki.freepascal.org/FPC_Unicode_support#RTL_changes
> >
> > Is there
Mattias Gaertner schrieb:
For example:
CP_ACP=0, DefaultSystemCodePage=1252
That means static code page is always 0, while dynamic code page can be
0 or 1252. Both describe the same encoding.
A *dynamic* encoding *never* can be CP_ACP nor CP_NONE (in Delphi).
These values are allowed only for
Ewald schrieb:
Of the OS/window manager actually. You are of course right in that there
are a certain set of separators that can be used, but the exact
separator to use is dependent on the system.
Sounds easy, but just yesterday I ran into a bunch of related problems.
Even if the following is
Michael Schnell schrieb:
I fail to understand some of the text.
It seems to be unavoidable to use the name "ANSIString" even though I
always though up when seeing a thing called "ANSI" containing Unicode
(e. g. "UTF8String = type AnsiString(CP_UTF8)" ).
Seemingly here the "bytes per chara
Mattias Gaertner schrieb:
Hi,
The page about "FPC Unicode support" mentions what has already been
updated to preserve character data.
http://wiki.freepascal.org/FPC_Unicode_support#RTL_changes
Is there already a page about what has not (yet) been updated aka does
not work with all code pages?
Michael Schnell schrieb:
On 11/26/2014 11:40 AM, Mattias Gaertner wrote:
Ansistring supports only one byte per character code pages.
Even more confused. Am I wrong thinking that with code aware Strings,
for Delphi XE compatibility, in Windows CP_ACP needs to be UTF16 (if not
right, than due
Michael Schnell schrieb:
On 11/26/2014 12:09 PM, Sven Barth wrote:
In Delphi (and FPC) CP_ACP corresponds by default with the current
system codepage (e.g. CP1252 on a German Windows).
OK. So in Delphi XE (in Germany) String(CP_ACP) is the same as
String(CP1252) but different from String wi
Mattias Gaertner schrieb:
On Wed, 26 Nov 2014 11:23:17 +0100
Michael Schnell wrote:
Seemingly here the "bytes per character" setting implicitly is thought
of as a port of the "code-page" definition. correct ?
Code page define bytes per character.
Huh?
Not all codepages have a fixed numbe
On Wed, 26 Nov 2014 17:50:31 +0100
Mattias Gaertner wrote:
> On Wed, 26 Nov 2014 17:23:48 +0100
> Jonas Maebe wrote:
>
> > On 26/11/14 17:21, Sven Barth wrote:
> > > Yes, nevertheless the header record is the same for UnicodeString and
> > > AnsiString and thus it also has a codepage field whic
On 26/11/14 17:41, Tomas Hajny wrote:
> BTW, in this context - can users choose UTF16BE on little endian
> platforms (and vice versa)?
No, because we do not have any routines that allow a user to set/change
the codepage of a unicodestring (either at run time or at compile time).
Jonas
On Wed, 26 Nov 2014 17:23:48 +0100
Jonas Maebe wrote:
> On 26/11/14 17:21, Sven Barth wrote:
> > Yes, nevertheless the header record is the same for UnicodeString and
> > AnsiString and thus it also has a codepage field which is always
> > initialized to CP_UTF16 however.
>
> It can also be CP_U
On 26 Nov 14, at 17:23, Jonas Maebe wrote:
> On 26/11/14 17:21, Sven Barth wrote:
> > Yes, nevertheless the header record is the same for UnicodeString and
> > AnsiString and thus it also has a codepage field which is always
> > initialized to CP_UTF16 however.
>
> It can also be CP_UTF16BE (which
On 26/11/14 16:19, Michael Schnell wrote:
> So seemingly you could do MyStringType = type
> AnsiString(CP_UTF16), and seemingly the size information is set
> according to this.
As several people have told you several times, that is invalid (in the
meaning of "undefined") in both FPC and Delp
On 26/11/14 17:21, Sven Barth wrote:
> Yes, nevertheless the header record is the same for UnicodeString and
> AnsiString and thus it also has a codepage field which is always
> initialized to CP_UTF16 however.
It can also be CP_UTF16BE (which it is on big endian FPC targets right now).
Jonas
_
Am 26.11.2014 15:30 schrieb "Mattias Gaertner" :
>
> On Wed, 26 Nov 2014 15:05:16 +0100
> Sven Barth wrote:
>
> >[...]
> > While both AnsiString and UnicodeString have the current codepage and
the
> > character size in their header record
>
> AFAIK UnicodeString has only a static (fixed) code page
On 26/11/14 13:11, Michael Schnell wrote:
> In section "String concatenations" there is no mentioning about
> auto-conversion.
There is.
> For statically typed Strings it's rather obvious that
> they will be auto-converted if appropriate.
It's probably rather obvious because it is literally ment
On 11/26/2014 03:05 PM, Sven Barth wrote:
>
> OK. So in Delphi XE (in Germany) String(CP_ACP) is the same as
String(CP1252) but different from String without brackets which in
turn is the same as String(CP_UTF16) ? Correct ?
There is no "String with brackets". You can only use "AnsiString"
On 26/11/14 12:53, Michael Schnell wrote:
[CP_NONE]
> Is this "undefined" in the meaning of "not predictable by the user" in
> the "current" version of fpc, or in the meaning of "due to change" when
> updating fpc.
This "undefined" literally means "undefined". It does not mean
"undefined in a mean
On Wed, 26 Nov 2014 15:05:16 +0100
Sven Barth wrote:
>[...]
> While both AnsiString and UnicodeString have the current codepage and the
> character size in their header record
AFAIK UnicodeString has only a static (fixed) code page.
Mattias
___
fpc-d
Am 26.11.2014 12:37 schrieb "Michael Schnell" :
>
> On 11/26/2014 12:09 PM, Sven Barth wrote:
>>
>> In Delphi (and FPC) CP_ACP corresponds by default with the current
system codepage (e.g. CP1252 on a German Windows).
>
>
> OK. So in Delphi XE (in Germany) String(CP_ACP) is the same as
String(CP12
After re-reading yet another question:
In section "String concatenations" there is no mentioning about
auto-conversion. For statically typed Strings it's rather obvious that
they will be auto-converted if appropriate. Technically - if differently
encode - they seem to be converted to Unicode a
On 11/26/2014 12:10 PM, Mattias Gaertner wrote:
"the results of conversions from/to the CP_NONE code page are undefined."
... because CP_NONE is not a real code page.
So you understand "result" as what you would get when printing.
In the context of this wiki page I would understand "result" a
On 11/26/2014 12:13 PM, Mattias Gaertner wrote:
In mode delphiunicode String=UnicodeString.
I see.
So even in Delphi XE where "UnicodeString" is denoted by "CP_UTF16", the
value of the constant CP_UTF16 is not the same as the value of the
(constant or) variable CP_ACP, (while OTOH using the v
On 11/26/2014 12:09 PM, Sven Barth wrote:
In Delphi (and FPC) CP_ACP corresponds by default with the current
system codepage (e.g. CP1252 on a German Windows).
OK. So in Delphi XE (in Germany) String(CP_ACP) is the same as
String(CP1252) but different from String without brackets which in tu
On Wed, 26 Nov 2014 11:52:50 +0100
Michael Schnell wrote:
> On 11/26/2014 11:40 AM, Mattias Gaertner wrote:
> > Ansistring supports only one byte per character code pages.
>
> Even more confused. Am I wrong thinking that with code aware Strings,
> for Delphi XE compatibility, in Windows CP_AC
On Wed, 26 Nov 2014 11:23:17 +0100
Michael Schnell wrote:
>[...]
> 2) I fail to understand how with this explanation that seems to force
> auto conversion for assignments between types with different "code page"
> settings (also for CP_ACP) the "static code page can differ from the
> dynamic c
Am 26.11.2014 11:53 schrieb "Michael Schnell" :
>
> On 11/26/2014 11:40 AM, Mattias Gaertner wrote:
>>
>> Ansistring supports only one byte per character code pages.
>
>
> Even more confused. Am I wrong thinking that with code aware Strings,
for Delphi XE compatibility, in Windows CP_ACP needs to b
On 11/26/2014 11:40 AM, Mattias Gaertner wrote:
Ansistring supports only one byte per character code pages.
Even more confused. Am I wrong thinking that with code aware Strings,
for Delphi XE compatibility, in Windows CP_ACP needs to be UTF16 (if not
right, than due later) ?
What is a "Co
In our previous episode, Mark Morgan Lloyd said:
> >> what else should it be?
> >
> > A shift space. In utf8 that takes two bytes.
>
> How does that look when hand-written on a cheque?
I haven't seen a cheque in a decade, but I assume that depends on the hand
having an utf8 encoding or not.
___
On Wed, 26 Nov 2014 11:23:17 +0100
Michael Schnell wrote:
>[...]
> It seems to be unavoidable to use the name "ANSIString" even though I
> always though up when seeing a thing called "ANSI" containing Unicode
> (e. g. "UTF8String = type AnsiString(CP_UTF8)" ).
Is there a question?
> Seemi
I fail to understand some of the text.
It seems to be unavoidable to use the name "ANSIString" even though I
always though up when seeing a thing called "ANSI" containing Unicode
(e. g. "UTF8String = type AnsiString(CP_UTF8)" ).
Seemingly here the "bytes per character" setting implicitly i
On 11/24/2014 10:45 AM, Michael Schnell wrote:
. I'll post the wiki paper on this tomorrow.
Please see a preliminary version of the text ->
http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support#Three_more_RAW_types
.
(Please use a new thread for any discussion on th
2014-11-26 9:47 GMT+01:00 Michael Schnell :
> On 11/26/2014 01:54 AM, Mark Morgan Lloyd wrote:
>
>>
>> How does that look when hand-written on a cheque?
>>
>> Supposedly this is a non-breaking space, that does not allow to be
> replaced by a line-break ( in HTML)
Precisely.
--
Frederic Da Vi
On 11/26/2014 01:54 AM, Mark Morgan Lloyd wrote:
How does that look when hand-written on a cheque?
Supposedly this is a non-breaking space, that does not allow to be
replaced by a line-break ( in HTML)
-Michael
___
fpc-devel maillist - fpc-devel
On Tue, 25 Nov 2014, luiz americo pereira camara wrote:
Hi,
Until now, when i make changes to RTL units in trunk, i take two pathes to test
and compile:
1) If the unit is self contained, i go to source directory and compile directly
2) If the unit is a dependency of other RTL parts, i rebui
2014-11-26 1:54 GMT+01:00 Mark Morgan Lloyd <
markmll.fpc-de...@telemetry.co.uk>:
> Marco van de Voort wrote:
>
>> In our previous episode, Pierre Free Pascal said:
>>
>>> I am surprised,
>>> for me, as French, I always believed that
>>> the French thousand separator is simply a space,
>>> what el
On Tue, 25 Nov 2014, Gennady Agranov wrote:
Hi,
When can regular FPC user expect 2.7.1 to graduate and be marked as stable
release?
Somewhere in Spring - like 2.6.4?
Forking off 2.8 is going to happen reasonably soon (some people on core prefer sooner,
others a little later).
After tha
45 matches
Mail list logo
