Your comments are absolutely vague and meaningless.
Sorry, but this was discussed already several times, so I supposed that
the problems I see are known to the discussion members:
But here a simple example Lazarus project with all options left in
standard setting:
procedure
if compiled using *none* utf8 mode.
I did not find a way to set none utf8 mode with Lazarus, so that I
just can use ANSIString (and WideString) like I did in the previous version.
Did I miss this option ?
If it exists, why not set same as default so that it works for someone
ignoring
It is works for win32 only for now. Only system unit is finished. Work
in progress...
Sounds great so far !
Is there a document on how exactly it is going to work (will a common
String type get a dynamic coding specification or will there be
different String types for any coding variants
Martin Friebe wrote:
I must agree with the FPC can not to it all automatically line (as
much as I regret, and admit the beauty there was, if fpc could).
What I mean is:
1) Any Application/Program, that currently compiles and works (using
none utf8, never mind if ascii or ansi) will keep
On Mon, Nov 24, 2008 at 3:55 PM, Jeff Wormsley [EMAIL PROTECTED] wrote:
such as SetLength, Length, stringvar[index], copy(string, index, count), pos
etc. cannot work 100% reliably. You don't know what the programmer wants
when he says stringvar[3]. Does he mean the third character in the
With plain strings, or Ansi strings, we have code that works today.
If you change any of those to UTF*, then code that uses things such as
SetLength, Length, stringvar[index], copy(string, index, count), pos
etc. cannot work 100% reliably. You don't know what the programmer
wants when he
From: Michael Schnell [EMAIL PROTECTED]
It is works for win32 only for now. Only system unit is finished.
Work in progress...
Sounds great so far !
Is there a document on how exactly it is going to work (will a
common String type get a dynamic coding specification or will there
be
In our previous episode, Mark Morgan Lloyd said:
Looking at 2.2.3 on sparc-linux I see that libc.ppu etc. is no longer
being built, it is however built for i386 and arm and for 2.2.0 and
older. Is this intentional?
To be honest I can't remember why I needed this but I've got notes to
In our previous episode, Florian Klaempfl said:
Of course if OS provides functions, use them! they should be properly
implemented and will be even faster without memory serious impact, but
I'm quite sure that not all functions will be provided by all OSs.
Maybe a small subset should be
On 24 Nov 08, at 21:49, Marco van de Voort wrote:
In our previous episode, Florian Klaempfl said:
Of course if OS provides functions, use them! they should be properly
implemented and will be even faster without memory serious impact, but
I'm quite sure that not all functions will be
10 matches
Mail list logo
