On 02/15/2016 12:03 PM, Juha Manninen wrote:
The real complexity of Unicode is beyond encodings
Yep.This I learned from the discussions. E.g. even with a technically
perfect UTF string implementation, the problem that exactly the same
printable text can be encoded in multiple ways can't be over
On Mon, Feb 15, 2016 at 12:20 PM, Michael Schnell wrote:
> Sorry I did not intend to express any negative attitude, but on the
> contrary am very happy that Lazarus/fpc can provide exactly that
> functionality (8 bit Strings - including TStrins, pos , etc - in a 64 Bit
> application) that (AFAIK
On 02/12/2016 06:13 PM, Juha Manninen wrote:
On Fri, Feb 12, 2016 at 6:52 PM, Michael Schnell wrote:
I think that it is *very* desirable to provide configuration options to
provide full backwards compatibility (while still allow to use as many of
the new features as possible when explicitly wri
Am 12.02.2016 17:37 schrieb "Dmitry Boyarintsev" :
>
> On Fri, Feb 12, 2016 at 11:24 AM, Sven Barth
wrote:
>>
>> Am 12.02.2016 17:16 schrieb "Dmitry Boyarintsev" <
skalogryz.li...@gmail.com>:
>> >
>> > On Fri, Feb 12, 2016 at 9:16 AM, Michael Van Canneyt <
mich...@freepascal.org> wrote:
>> >>
>> >
On Fri, Feb 12, 2016 at 6:52 PM, Michael Schnell wrote:
> I think that it is *very* desirable to provide configuration options to
> provide full backwards compatibility (while still allow to use as many of
> the new features as possible when explicitly writing coding for this).
Uhhh...
Michael Sc
On 02/12/2016 05:23 PM, Mattias Gaertner wrote:
If your friend use string literals in Delphi they are encoded in
system code page. Here might be some traps.
He will easily be able to handle this .
Thanks a lot !
-Michael
--
___
Lazarus mailing lis
This does sound good. :-)
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
On 02/12/2016 05:37 PM, Dmitry Boyarintsev wrote:
In this particular case (of porting Delphi 7 code straight to FPC
3.0.0) is a matter of backward compatibility.
Yep.
Not only to D7, but also to legacy fpc and Lazarus versions, that (as we
all know) were modeled after D7 (and friends).
I t
On Fri, 12 Feb 2016 17:16:29 +0100 (CET)
Michael Van Canneyt wrote:
>[...]
> >> {$define String:=RawByteString}
>[...]
> Type
>T = Type Ansistring(850);
AFAIK this was introduced with Delphi 2009. Not available in Delphi 7.
Mattias
--
___
Lazarus
On Fri, Feb 12, 2016 at 11:24 AM, Sven Barth
wrote:
> Am 12.02.2016 17:16 schrieb "Dmitry Boyarintsev" <
> skalogryz.li...@gmail.com>:
> >
> > On Fri, Feb 12, 2016 at 9:16 AM, Michael Van Canneyt <
> mich...@freepascal.org> wrote:
> >>
> >> {$define String:=RawByteString}
> >>
> >> and you are do
On Fri, 12 Feb 2016, Sven Barth wrote:
Am 12.02.2016 17:16 schrieb "Dmitry Boyarintsev"
:
On Fri, Feb 12, 2016 at 9:16 AM, Michael Van Canneyt <
mich...@freepascal.org> wrote:
{$define String:=RawByteString}
and you are done.
How to achieve the same effect from command line?
Just do
Am 12.02.2016 17:16 schrieb "Dmitry Boyarintsev" :
>
> On Fri, Feb 12, 2016 at 9:16 AM, Michael Van Canneyt <
mich...@freepascal.org> wrote:
>>
>> {$define String:=RawByteString}
>>
>> and you are done.
>
>
> How to achieve the same effect from command line?
Just don't. There are things that are n
On Fri, 12 Feb 2016 16:53:12 +0100
Michael Schnell wrote:
>[...]
> > even without the new UTF-8 mode.
> How to set this mode when compiling with Lazarus ?
See here
http://wiki.freepascal.org/Lazarus_with_FPC3.0_without_UTF-8_mode
> What mode do you think is more appropriate when most work is
On Fri, Feb 12, 2016 at 9:16 AM, Michael Van Canneyt wrote:
> {$define String:=RawByteString}
>
> and you are done.
>
How to achieve the same effect from command line?
thanks,
Dmitry
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
htt
On Fri, 12 Feb 2016, Mattias Gaertner wrote:
On Fri, 12 Feb 2016 15:16:38 +0100 (CET)
Michael Van Canneyt wrote:
[...]
{$define String:=RawByteString}
and you are done.
Won't compile when calling RTL functions with var parameters.
I fail to see why RawByteString should do less conversio
On Fri, 12 Feb 2016 16:41:23 +0100
Michael Schnell wrote:
> On 02/12/2016 03:54 PM, Juha Manninen wrote:
> > Sure there is hope. See the new UTF-8 support:
> >http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus
> >
> This page says:
>
> "This page covers Unicode support in Lazarus p
On 02/12/2016 03:53 PM, Mattias Gaertner wrote:
Your friend can use the LCL for the GUI with disabled UTF-8 mode.
Sounds great !
He has to check (convert) the strings between his TCP/IP code and the
LCL controls (e.g. UTF8ToSys). As he has only a small GUI this should
be easy.
No problem. The
On 02/12/2016 03:55 PM, Mattias Gaertner wrote:
True, although the wording might be misleading.
FPC 3.0+ does not arbitrarily change encoding of strings.
That's why the LCL can use UTF-8 in AnsiStrings even without the new
UTF-8 mode.
It then works pretty similar to FPC 2.6.4.
This is exactly
On 02/12/2016 03:54 PM, Juha Manninen wrote:
Sure there is hope. See the new UTF-8 support:
http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus
This page says:
"This page covers Unicode support in Lazarus programs (console or
server, no GUI) and applications (GUI with LCL) using f
On 02/12/2016 03:54 PM, Juha Manninen wrote:
Both Delphi and FPC now support 64-bit. I don't know how that relates
to dynamic String encoding.
.
http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus
AFAIK, any 64 bit Delphi forces UTF-16 Unicode and cant do what is
described in t
On Fri, 12 Feb 2016 15:16:38 +0100 (CET)
Michael Van Canneyt wrote:
>[...]
> {$define String:=RawByteString}
>
> and you are done.
Won't compile when calling RTL functions with var parameters.
I fail to see why RawByteString should do less conversions than using
AnsiString, when porting a Delp
On 02/12/2016 03:54 PM, Juha Manninen wrote:
Sure there is hope. See the new UTF-8 support:
http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus
I'll let him know...
And of course I will take read this myself, too.
In fact he does not want "Better_Unicode_Support" but
*no_unicode_
On Fri, Feb 12, 2016 at 4:18 PM, Michael Schnell wrote:
> Now a friend of mine is faced by a similar task. But here he wants to keep a
> (small) GUI and he does not want to go for Linux but for 64 Bit.
Both Delphi and FPC now support 64-bit. I don't know how that relates
to dynamic String encodin
On Fri, 12 Feb 2016 15:38:49 +0200
Juha Manninen wrote:
> On Fri, Feb 12, 2016 at 3:25 PM, Michael Schnell wrote:
> > Any automatic type conversion would kill the application.
> > [...]
> > will this be possible with future versions of Lazarus ,as well ?
>
> I guess you mean automatic encoding
On Fri, 12 Feb 2016 14:25:43 +0100
Michael Schnell wrote:
>[...]
> A friend of mine wants to port an application from Delphi 7 to a be a
> Lazarus 64 Bit Windows application.
>
> This (huge) application only features a very limited GIU, but uses
> strings lot for "uncoded" characters, going in
On Fri, 12 Feb 2016, Michael Schnell wrote:
On 02/12/2016 03:16 PM, Michael Van Canneyt wrote:
On Fri, 12 Feb 2016, Michael Schnell wrote:
On 02/12/2016 02:38 PM, Michael Van Canneyt wrote:
Just use RawByteString as stringtype for all parameters and variables
in calls where you don't w
On 02/12/2016 03:16 PM, Michael Van Canneyt wrote:
On Fri, 12 Feb 2016, Michael Schnell wrote:
On 02/12/2016 02:38 PM, Michael Van Canneyt wrote:
Just use RawByteString as stringtype for all parameters and variables
in calls where you don't want code page conversions to occur.
This would
On 2016-02-12 14:16, Michael Van Canneyt wrote:
> {$define String:=RawByteString}
>
> and you are done.
Awesome!
FPC:1
Delphi: 0
:)
Regards,
G.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepasc
On 02/12/2016 03:16 PM, Michael Van Canneyt wrote:
Tish...
{$define String:=RawByteString}
and you are done.
I'll let him know...
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailma
On 02/12/2016 02:57 PM, Juha Manninen wrote:
And yes, often the same arguments were repeated by the same person who
started this thread.
At the time I did those researches and discussions, my colleagues here
were interested in porting their Delphi application to Linux using
Lazarus and I trie
On Fri, 12 Feb 2016, Michael Schnell wrote:
On 02/12/2016 02:38 PM, Michael Van Canneyt wrote:
Just use RawByteString as stringtype for all parameters and variables
in calls where you don't want code page conversions to occur.
This would mean rewriting the complete application. This obvio
On 02/12/2016 02:38 PM, Juha Manninen wrote:
The automatic conversion is NOT a feature of Lazarus. It is a feature
of FPC 3.0+.
Of course I do know this. That is why I ask. AFAIK, fpc can be
configured to use the new string type or not to use it.But will this be
possible for a Lazarus applica
On 02/12/2016 02:38 PM, Michael Van Canneyt wrote:
Just use RawByteString as stringtype for all parameters and variables
in calls where you don't want code page conversions to occur.
This would mean rewriting the complete application. This obviously is
not desired .
-Michael
--
__
On Fri, Feb 12, 2016 at 3:42 PM, Kostas Michalopoulos
wrote:
> is it possible for now and the foreseeable future to have FPC (3.0+, not
> just 2.x) make the "string" type (not rawbytestring or anything else) behave
> as it was behaving always since the beginning of time without any source
> code c
I suppose a more clear question would be...
is it possible for now and the foreseeable future to have FPC (3.0+, not
just 2.x) make the "string" type (not rawbytestring or anything else)
behave as it was behaving always since the beginning of time without any
source code changes but (say) via some
On Fri, Feb 12, 2016 at 3:38 PM, Michael Van Canneyt
wrote:
> Just use RawByteString as stringtype for all parameters and variables
> in calls where you don't want code page conversions to occur. The compiler
> will not touch the codepage then.
Ok, true. That works, too. :)
Juha
--
___
On Fri, Feb 12, 2016 at 3:25 PM, Michael Schnell wrote:
> Any automatic type conversion would kill the application.
> [...]
> will this be possible with future versions of Lazarus ,as well ?
I guess you mean automatic encoding conversion for strings. (?)
The automatic conversion is NOT a feature
On Fri, 12 Feb 2016, Michael Schnell wrote:
Hi Experts,
A friend of mine wants to port an application from Delphi 7 to a be a Lazarus
64 Bit Windows application.
This (huge) application only features a very limited GIU, but uses strings
lot for "uncoded" characters, going in and out via T
Hi Experts,
A friend of mine wants to port an application from Delphi 7 to a be a
Lazarus 64 Bit Windows application.
This (huge) application only features a very limited GIU, but uses
strings lot for "uncoded" characters, going in and out via TCP/IP. Any
automatic type conversion would kill
39 matches
Mail list logo
