On 01/05/2013 12:28 PM, Jonas Maebe wrote:
Using whatever #xx#xx or #xx#xx#xx sequence represents the UTF-8
encoding of that character.
Sorry, I can't follow. Does #xx not just define a numerical
representation of an 8 bit entity ?
The interpretation in any code might be done later by any
On 01/05/2013 01:35 PM, Jy V wrote:
I do vote for UTF-8
-1
Regarding that conversions in the RTL (or LCL) are a rather seldom
runtime-task, GUI performance issues are not really necessary to be
considered.
Viable issues seem to be Delphi compatibility, backward compatibility,
usability,
Once upon a time, on 01/07/2013 12:39 PM to be precise, Michael Schnell
said:
On 01/05/2013 12:28 PM, Jonas Maebe wrote:
Using whatever #xx#xx or #xx#xx#xx sequence represents the UTF-8
encoding of that character.
Sorry, I can't follow. Does #xx not just define a numerical
representation of
On Mon, January 7, 2013 13:28, Ewald wrote:
Once upon a time, on 01/07/2013 12:39 PM to be precise, Michael Schnell
said:
On 01/05/2013 12:28 PM, Jonas Maebe wrote:
Using whatever #xx#xx or #xx#xx#xx sequence represents the UTF-8
encoding of that character.
Sorry, I can't follow. Does #xx
So the ambiguity with _filling_ a string with data in fact arises when
_not_ using the #nn notation :-) . With #nn the effect (i.e. the
resulting binary) is obvious.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 01/07/2013 02:01 PM, Tomas Hajny wrote:
(also just my understanding of what Jonas wrote)
I feel you are wrong. The string does not know about the code it's
content is to be interpreted in (other than with Delphi XE).
-Michael
___
fpc-devel
Once upon a time, on 01/07/2013 02:17 PM to be precise, Michael Schnell
said:
So the ambiguity with _filling_ a string with data in fact arises
when _not_ using the #nn notation :-) . With #nn the effect (i.e. the
resulting binary) is obvious.
Well, if there is literally the sequence $C7, $BE
On Mon, January 7, 2013 14:19, Michael Schnell wrote:
On 01/07/2013 02:01 PM, Tomas Hajny wrote:
(also just my understanding of what Jonas wrote)
I feel you are wrong. The string does not know about the code it's
content is to be interpreted in (other than with Delphi XE).
Sorry, your way of
Once upon a time, on 01/07/2013 05:05 PM to be precise, Tomas Hajny said:
On Mon, January 7, 2013 14:19, Michael Schnell wrote:
On 01/07/2013 02:01 PM, Tomas Hajny wrote:
(also just my understanding of what Jonas wrote)
I feel you are wrong. The string does not know about the code it's
Tomas Hajny wrote:
On Mon, January 7, 2013 13:28, Ewald wrote:
Once upon a time, on 01/07/2013 12:39 PM to be precise, Michael Schnell
said:
On 01/05/2013 12:28 PM, Jonas Maebe wrote:
Using whatever #xx#xx or #xx#xx#xx sequence represents the UTF-8
encoding of that character.
Sorry, I can't
On Mon, Jan 7, 2013 at 6:05 PM, Mark Morgan Lloyd
markmll.fpc-de...@telemetry.co.uk wrote:
Tomas Hajny wrote:
On Mon, January 7, 2013 13:28, Ewald wrote:
Once upon a time, on 01/07/2013 12:39 PM to be precise, Michael Schnell
said:
On 01/05/2013 12:28 PM, Jonas Maebe wrote:
Using
Michael Van Canneyt schrieb:
IMO resource strings are for display purposes, so that UTF-8/16
encoding is expected by an OS API. AFAIR Win32 string resources are
stored in UTF-16,
You are very much wrong.
Not really. I was talking about Win32 resources, not about what FPC
makes from
Paul Ishenin schrieb:
05.01.13, 23:54, Michael Van Canneyt пишет:
You are very much wrong.
To start with, resource strings are not stored as Win32 resources.
I personally think that resources should be stored in their native
formats where is possible. This will allow to change them using
On Sun, 6 Jan 2013, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
IMO resource strings are for display purposes, so that UTF-8/16 encoding
is expected by an OS API. AFAIR Win32 string resources are stored in
UTF-16,
You are very much wrong.
Not really. I was talking about
On Saturday 05 January 2013 11:30:42 Jonas Maebe wrote:
[...]
For example, I said that basically nothing changed in 2.7.x compared to
2.6.x, except that certain string constants are no longer automatically
converted to utf-16 at compile time, and then you ask Or should we not
touch the theme
On 05 Jan 2013, at 12:12, Martin Schreiber wrote:
Thank you very much for the detailed explanation. What I could not found in
all the answers (probably it is my ignorance of the English language), is,
does #n mean a utf16 code unit as in Delphi XE3 or does it denote something
other?
It
On 05.01.2013 12:28, Jonas Maebe wrote:
And again, sorry for the impertinence, how do resource strings fit in the
string handling scenario of Free Pascal trunk?
Unicode support for resourcestrings is still not available in FPC trunk. They
can currently still only be used safely for ASCII
On 05 Jan 2013, at 12:36, Sven Barth wrote:
On 05.01.2013 12:28, Jonas Maebe wrote:
And again, sorry for the impertinence, how do resource strings fit in the
string handling scenario of Free Pascal trunk?
Unicode support for resourcestrings is still not available in FPC trunk.
They can
On Saturday 05 January 2013 12:28:03 Jonas Maebe wrote:
Alternatively, in both cases you can instead define a
unicodestring/widestring constant instead of an ansistring/shortstring
constant by embedding widechar constants in the character sequence. Such
widechar constants are of the form
05.01.13, 19:40, Jonas Maebe пишет:
You can put anything in it and it may or may not work depending on the current
system code page, but afaik the only thing that is guaranteed to work at this
time is plain ASCII.
ResourceStrings are stored as AnsiString type with 0 codepage (as I
On 05 Jan 2013, at 12:53, Martin Schreiber wrote:
So compiled with -Fcutf8
unicodestringvar:= 'Best'#228'tigung';
produces a different result on fixes_2_6 and trunk? I assume in trunk there
will be a compile error?
No. In both cases it results in a widestring with this content:
.short
On 05 Jan 2013, at 12:53, Paul Ishenin wrote:
ResourceStrings are stored as AnsiString type with 0 codepage (as I
remember). Delphi now stores ResourceStrings as UnicodeString type. I think
FPC will follow this in m_default_unicodestring modeswitch.
It would probably even be better to
On Sat, 5 Jan 2013, Jonas Maebe wrote:
On 05 Jan 2013, at 12:53, Paul Ishenin wrote:
ResourceStrings are stored as AnsiString type with 0 codepage (as I remember).
Delphi now stores ResourceStrings as UnicodeString type. I think FPC will
follow this in m_default_unicodestring modeswitch.
On 05 Jan 2013, at 13:10, Michael Van Canneyt wrote:
On Sat, 5 Jan 2013, Jonas Maebe wrote:
On 05 Jan 2013, at 12:53, Paul Ishenin wrote:
ResourceStrings are stored as AnsiString type with 0 codepage (as I
remember). Delphi now stores ResourceStrings as UnicodeString type. I think
On Saturday 05 January 2013 12:57:44 Jonas Maebe wrote:
On 05 Jan 2013, at 12:53, Martin Schreiber wrote:
So compiled with -Fcutf8
unicodestringvar:= 'Best'#228'tigung';
produces a different result on fixes_2_6 and trunk? I assume in trunk
there will be a compile error?
No. In
On 05 Jan 2013, at 13:33, Martin Schreiber wrote:
On Saturday 05 January 2013 12:57:44 Jonas Maebe wrote:
On 05 Jan 2013, at 12:53, Martin Schreiber wrote:
So compiled with -Fcutf8
unicodestringvar:= 'Best'#228'tigung';
produces a different result on fixes_2_6 and trunk? I assume in
Yes, the exception is probably UTF-8 on Unix systems, but is that really
worth it to complicate the compiler and RTL? Resourcestings are generally
not used in performance-critical code, I'd assume. Always using UTF-8 is
however also fine for me,
I do vote for UTF-8
btw. I just don't
On Sat, 5 Jan 2013, Jonas Maebe wrote:
On 05 Jan 2013, at 13:10, Michael Van Canneyt wrote:
On Sat, 5 Jan 2013, Jonas Maebe wrote:
On 05 Jan 2013, at 12:53, Paul Ishenin wrote:
ResourceStrings are stored as AnsiString type with 0 codepage (as I remember).
Delphi now stores
On 05.01.2013 14:16, Michael Van Canneyt wrote:
On Sat, 5 Jan 2013, Jonas Maebe wrote:
On 05 Jan 2013, at 13:10, Michael Van Canneyt wrote:
On Sat, 5 Jan 2013, Jonas Maebe wrote:
On 05 Jan 2013, at 12:53, Paul Ishenin wrote:
ResourceStrings are stored as AnsiString type with 0
On Sat, 5 Jan 2013, Sven Barth wrote:
On 05.01.2013 14:16, Michael Van Canneyt wrote:
On Sat, 5 Jan 2013, Jonas Maebe wrote:
On 05 Jan 2013, at 13:10, Michael Van Canneyt wrote:
On Sat, 5 Jan 2013, Jonas Maebe wrote:
On 05 Jan 2013, at 12:53, Paul Ishenin wrote:
ResourceStrings
Michael Van Canneyt schrieb:
On Sat, 5 Jan 2013, Jonas Maebe wrote:
On 05 Jan 2013, at 12:53, Paul Ishenin wrote:
ResourceStrings are stored as AnsiString type with 0 codepage (as I
remember). Delphi now stores ResourceStrings as UnicodeString type. I
think FPC will follow this in
On Sat, 5 Jan 2013, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
On Sat, 5 Jan 2013, Jonas Maebe wrote:
On 05 Jan 2013, at 12:53, Paul Ishenin wrote:
ResourceStrings are stored as AnsiString type with 0 codepage (as I
remember). Delphi now stores ResourceStrings as
05.01.13, 23:54, Michael Van Canneyt пишет:
You are very much wrong.
To start with, resource strings are not stored as Win32 resources.
I personally think that resources should be stored in their native
formats where is possible. This will allow to change them using software
designed for
On Sat, 5 Jan 2013, Paul Ishenin wrote:
05.01.13, 23:54, Michael Van Canneyt пишет:
You are very much wrong.
To start with, resource strings are not stored as Win32 resources.
I personally think that resources should be stored in their native formats
where is possible. This will allow
34 matches
Mail list logo
