On 07.05.2017 12:17, Florian Klaempfl via Lazarus wrote:
> Am 07.05.2017 um 12:11 schrieb Sven Barth via Lazarus:
>> Am 07.05.2017 12:07 schrieb "Florian Klaempfl via Lazarus"
>> >:
>>>
>>> Am 07.05.2017 um 11:57 schrieb Graeme
On 2017-05-07 11:17, Florian Klaempfl via Lazarus wrote:
> Then something is wrong/broken :)
I rest my case. :-P
Regards,
Graeme
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus
Am 07.05.2017 um 12:11 schrieb Sven Barth via Lazarus:
> Am 07.05.2017 12:07 schrieb "Florian Klaempfl via Lazarus"
> >:
>>
>> Am 07.05.2017 um 11:57 schrieb Graeme Geldenhuys via Lazarus:
>> > On 2017-05-07 09:10, Florian
Am 07.05.2017 um 11:57 schrieb Graeme Geldenhuys via Lazarus:
> On 2017-05-07 09:10, Florian Klaempfl via Lazarus wrote:
>>> Yeah, that would be the logical thing to do.
>>
>> Why? What makes a string literal UTF-8?
>>
>
> As Mattias said, the fact that the source unit is UTF-8 encoded.
>
Am 07.05.2017 12:07 schrieb "Florian Klaempfl via Lazarus" <
lazarus@lists.lazarus-ide.org>:
>
> Am 07.05.2017 um 11:57 schrieb Graeme Geldenhuys via Lazarus:
> > On 2017-05-07 09:10, Florian Klaempfl via Lazarus wrote:
> >>> Yeah, that would be the logical thing to do.
> >>
> >> Why? What makes a
On 2017-05-07 09:10, Florian Klaempfl via Lazarus wrote:
>> Yeah, that would be the logical thing to do.
>
> Why? What makes a string literal UTF-8?
>
As Mattias said, the fact that the source unit is UTF-8 encoded.
Defined by a BOM marker, or -Fcutf8 or {$codepage utf8}. If the source
unit is
Am 07.05.2017 um 10:30 schrieb Mattias Gaertner via Lazarus:
> On Sun, 7 May 2017 10:10:26 +0200
> Florian Klaempfl via Lazarus wrote:
>
>> Am 05.05.2017 um 13:35 schrieb Graeme Geldenhuys via Lazarus:
>>> On 2017-05-05 12:17, Mattias Gaertner via Lazarus wrote:
On Sun, 7 May 2017 10:10:26 +0200
Florian Klaempfl via Lazarus wrote:
> Am 05.05.2017 um 13:35 schrieb Graeme Geldenhuys via Lazarus:
> > On 2017-05-05 12:17, Mattias Gaertner via Lazarus wrote:
> >> I wonder if it would help if FPC would store UTF-8 string
Am 05.05.2017 um 13:35 schrieb Graeme Geldenhuys via Lazarus:
> On 2017-05-05 12:17, Mattias Gaertner via Lazarus wrote:
>> I wonder if it would help if FPC would store UTF-8 string literals as
>> UTF-8
>
> Yeah, that would be the logical thing to do.
Why? What makes a string literal UTF-8?
>
On Fri, 5 May 2017 16:36:51 +0300
Juha Manninen via Lazarus wrote:
> On Fri, May 5, 2017 at 4:21 PM, Mattias Gaertner via Lazarus
> wrote:
> > Oops. Which one?
>
> The FAQ says:
> "Since FPC 3.0 you must add the flag -FcUTF8 or
On Fri, May 5, 2017 at 4:21 PM, Mattias Gaertner via Lazarus
wrote:
> Oops. Which one?
The FAQ says:
"Since FPC 3.0 you must add the flag -FcUTF8 or add {$codepage UTF8}
at the beginning of the unit."
The same page in "String Literals" section says:
"In most
On Fri, May 5, 2017 at 3:56 PM, Sven Barth via Lazarus
wrote:
> That is mainly due to the compiler not supporting surrogate pairs for the
> UTF-8 -> UTF-16 conversion. If it would support them, then there wouldn't be
> a problem anymore...
That is a serious bug.
On Fri, 5 May 2017 14:12:05 +0300
Juha Manninen via Lazarus wrote:
>[...]
> Then Mattias adds FAQs contradicting the earlier texts ...
Oops. Which one?
Mattias
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
Am 05.05.2017 13:50 schrieb "Juha Manninen via Lazarus" <
lazarus@lists.lazarus-ide.org>:
>
> On Fri, May 5, 2017 at 2:29 PM, Michael Van Canneyt via Lazarus
> wrote:
> > Then what is still the problem ?
>
> With BOM you get:
> Error: UTF-8 code greater than 65535
On 2017-05-05 12:49, Juha Manninen via Lazarus wrote:
> A wrong information easily propagates, thus it is important to get this right.
No worries, I agree. Thanks for correcting my terminology.
Regards,
Graeme
--
___
Lazarus mailing list
On Fri, May 5, 2017 at 2:02 PM, Graeme Geldenhuys via Lazarus
wrote:
> If so, when why does LCL also call the above two functions?
Graeme, they are called by LazUtils package, LazUTF8 unit, not by LCL.
It is not limited to GUI programming.
A wrong information
On Fri, May 5, 2017 at 2:29 PM, Michael Van Canneyt via Lazarus
wrote:
> Then what is still the problem ?
With BOM you get:
Error: UTF-8 code greater than 65535 found
which is counter-intuitive when the file and the string literal are both UTF-8.
It is related to
On 05.05.2017 13:02, Graeme Geldenhuys via Lazarus wrote:
On 2017-05-05 10:41, Ondrej Pokorny via Lazarus wrote:
Just use "DefaultSystemCodePage := CP_UTF8" and every single-byte string
is unicode enabled.
So does that mean you don't have to also call the following two functions
(which LCL
On 2017-05-05 12:17, Mattias Gaertner via Lazarus wrote:
> I wonder if it would help if FPC would store UTF-8 string literals as
> UTF-8
Yeah, that would be the logical thing to do. FPC not doing that is what
really confused me.
Regards,
Graeme
--
On Fri, 5 May 2017, Mattias Gaertner via Lazarus wrote:
On Fri, 5 May 2017 12:52:48 +0200 (CEST)
Michael Van Canneyt via Lazarus wrote:
[...]
I propose to let the compiler observe the BOM.
But I don't think more is needed.
FPC observes the BOM. Same as
On Fri, 5 May 2017 12:52:48 +0200 (CEST)
Michael Van Canneyt via Lazarus wrote:
>[...]
> I propose to let the compiler observe the BOM.
> But I don't think more is needed.
FPC observes the BOM. Same as Delphi.
I wonder if it would help if FPC would store UTF-8
On 05.05.2017 12:16, Graeme Geldenhuys via Lazarus wrote:
In the end it’s about supporting Unicode. Does it really matter
what internal encoding it is to achieve the “Unicode support”
goal?
Yep it does.
There are ways around that issue (i.e. code aware strings) but in fact
these trigger a
On 2017-05-05 11:55, Jürgen Hestermann via Lazarus wrote:
> I use UTF-8 internally and
> convert to/from UTF-16 for all Windows API functions and
> I never found any problem with it.
> The time that the API functions requires is so much longer than the
> time for string conversion that it does not
On Fri, May 5, 2017 at 1:20 AM, Graeme Geldenhuys via Lazarus
wrote:
> A case in point. Looking at the Wiki page you listed, I read the following:
> "
> Since FPC 3.0 you must add the flag -FcUTF8 or add {$codepage UTF8} at the
> beginning of the unit.
> ...
Uhhh,
On 2017-05-05 10:41, Ondrej Pokorny via Lazarus wrote:
> Just use "DefaultSystemCodePage := CP_UTF8" and every single-byte string
> is unicode enabled.
So does that mean you don't have to also call the following two functions
(which LCL does).
SetMultiByteConversionCodePage(CP_UTF8);
On 05.05.2017 12:01, Michael Van Canneyt via Lazarus wrote:
On Fri, 5 May 2017, Ondrej Pokorny via Lazarus wrote:
Believe me, I use it in production without any problems: I have
unicode-aware TStrings, I can read files with unicode names, I can do
everything with plain FPC trunk.
I am aware
Am 2017-05-05 um 12:16 schrieb Graeme Geldenhuys via Lazarus:
> In the end it’s about supporting Unicode. Does it really matter
> what internal encoding it is to achieve the “Unicode support”
> goal?
From a performance perspective it may be unwanted
to convert string encodings back and forth all
On Fri, 5 May 2017, Juha Manninen via Lazarus wrote:
On Fri, May 5, 2017 at 9:43 AM, Michael Van Canneyt via Lazarus
wrote:
What tricks do you still need in 3.0.x ?
The annoying tricky part with our UTF-8 solution is the assignment of
Unicode string
On Fri, 5 May 2017 12:17:22 +0200
Ondrej Pokorny via Lazarus wrote:
>[...]
> Embarcadero realized they made a mistake when they disabled (yes, only
> disabled not removed) 8-byte strings from NEXTGEN compilers. UTF8String
> and RawByteString are back for all
On Fri, 5 May 2017 12:01:47 +0200 (CEST)
Michael Van Canneyt via Lazarus wrote:
>[...]
> > Believe me, I use it in production without any problems: I have
> > unicode-aware TStrings, I can read files with unicode names, I can do
> > everything with plain FPC
On 2017-05-05 11:01, Michael Van Canneyt via Lazarus wrote:
> We claim Delphi compatibility.
> So IMHO we must provide a UTF-16 Delphi compatible RTL.
In the end it’s about supporting Unicode. Does it really matter
what internal encoding it is to achieve the “Unicode support”
goal?
Regards,
On Fri, 5 May 2017 10:56:41 +0100
Graeme Geldenhuys via Lazarus wrote:
>[...]
> > or work with large amount of 8-bit strings.
>
> Why would you want to? Unicode supports all languages,
Maybe there is a misunderstanding. Let me rephrase my question:
What string
On 2017-05-05 10:41, Mattias Gaertner via Lazarus wrote:
> I wonder what they do when you need to access the raw 8-bit file names,
OSX, iOS, Android and Linux all use UTF-8 as standard, so filename access
is not going to be any problem. Windows is moving more and more towards
UTF-16 everywhere,
On Fri, 5 May 2017 10:01:24 +0100
Graeme Geldenhuys via Lazarus wrote:
>[...]
> > AFAIK you are using UTF-8 in AnsiString in FPC 2.6.4. That works in
> > many cases, because of double fooling the compiler. This trick does not
> > work on Windows with RTL file
On Fri, 5 May 2017, Ondrej Pokorny via Lazarus wrote:
On 05.05.2017 11:17, Michael Van Canneyt via Lazarus wrote:
On Fri, 5 May 2017, Graeme Geldenhuys via Lazarus wrote:
On 2017-05-05 07:43, Michael Van Canneyt via Lazarus wrote:
As far as I know, you don't need any tricks to work with
On 2017-05-05 10:17, Michael Van Canneyt via Lazarus wrote:
>> Something like:
>>
>> sl.LoadFromFile('some_utf8_file.txt', CP_UTF8);
>> sl.LoadFromFile('some_utf16_file.txt', CP_UTF16);
>> sl.LoadFromFile('some_latin1_file.txt', CP_Latin1);
>
> Not yet. These are the exceptions I was talking
On 2017-05-05 10:17, Ondrej Pokorny via Lazarus wrote:
> I don't know about 3.0.x but you can do it in trunk 3.1.1. I posted a
> patch for it (r34475).
Fantastic! Glad to see somebody was thinking in the same train of thought
as I did. :)
Is that scheduled to be back-ported to FPC 3.0.x?
On 05.05.2017 11:17, Michael Van Canneyt via Lazarus wrote:
On Fri, 5 May 2017, Graeme Geldenhuys via Lazarus wrote:
On 2017-05-05 07:43, Michael Van Canneyt via Lazarus wrote:
As far as I know, you don't need any tricks to work with unicode
filenames or output in 3.0.2. Maybe with exception
On Fri, 5 May 2017, Ondrej Pokorny via Lazarus wrote:
On 05.05.2017 11:06, Graeme Geldenhuys via Lazarus wrote:
On 2017-05-05 07:43, Michael Van Canneyt via Lazarus wrote:
As far as I know, you don't need any tricks to work with unicode
filenames or output in 3.0.2. Maybe with exception of
On 2017-05-05 09:59, Michael Schnell via Lazarus wrote:
> (Most obvious drawback: not flexibly typed TStrings.)
I know not everybody likes Generics, but that is where I see
Generics could come in very handy. A single TStrings implementation
that supports multiple string types.
Or just implement
On Fri, 5 May 2017, Graeme Geldenhuys via Lazarus wrote:
On 2017-05-05 07:43, Michael Van Canneyt via Lazarus wrote:
As far as I know, you don't need any tricks to work with unicode
filenames or output in 3.0.2. Maybe with exception of TStrings and
TFileStream.
Again, I didn't have time to
On 05.05.2017 11:06, Graeme Geldenhuys via Lazarus wrote:
On 2017-05-05 07:43, Michael Van Canneyt via Lazarus wrote:
As far as I know, you don't need any tricks to work with unicode
filenames or output in 3.0.2. Maybe with exception of TStrings and
TFileStream.
Again, I didn't have time to
On 2017-05-05 09:31, Kostas Michalopoulos via Lazarus wrote:
> After all, BMP does include practically all languages used today.
The bottom line:
Unicode Standard <> BMP only!
If you think that, then rather promote your application as a UCS-2
compliant application, not a Unicode compliant
On 2017-05-05 07:43, Michael Van Canneyt via Lazarus wrote:
> As far as I know, you don't need any tricks to work with unicode
> filenames or output in 3.0.2. Maybe with exception of TStrings and
> TFileStream.
Again, I didn't have time to follow FPC 3.x development much, and I was too
confused
On 2017-05-05 00:15, Mattias Gaertner via Lazarus wrote:
> I added a FAQ:
> http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus#What_happens_when_I_use_.24codepage_utf8.3F
Ah, thanks for that explanation.
> AFAIK you are using UTF-8 in AnsiString in FPC 2.6.4. That works in
> many
On 04.05.2017 16:56, Juha Manninen via Lazarus wrote:
I believe everybody is happy to get rid of the horrendous Windows
If if this is true, there is a decent need for backwards compatibility.
That is why, theoretically, code aware strings is a good idea.
Unfortunately the implementation of
On Fri, 5 May 2017 11:31:00 +0300
Kostas Michalopoulos via Lazarus wrote:
>[...]
> To play the devil's advocate, the fact that ALL reviews said that it has
> excellent support for Unicode means that characters outside the BMP *are*
> rare. After all, BMP does
On 2017-05-04 21:53, Juha Manninen via Lazarus wrote:
> It is briefly explained here:
I haven't been following FPC 3.x development much because I think the Unicode
changes are terribly confusing.
A case in point. Looking at the Wiki page you listed, I read the following:
"
Since FPC 3.0 you
On Thu, May 4, 2017 at 8:53 PM, Graeme Geldenhuys via Lazarus
wrote:
> You made me curious, so I want to take a look. Hopefully it doesn’t
> depend too heavily on the rest of LCL, so I’ll be able to use it in
> other projects of mine.
It has no dependency for LCL,
On 2017-05-04 15:56, Juha Manninen via Lazarus wrote:
> I have seen comments saying that treating UTF-16 as fixed width
> encoding is OK because the characters outside BMP are so rare. It is
> like saying that a buggy spreadsheet app is OK because it calculates
> the sums wrong only sometimes.
On 05/04/2017 10:56 AM, Juha Manninen via Lazarus wrote:
On Thu, May 4, 2017 at 2:47 PM, wkitty42--- via Lazarus
wrote:
On 05/03/2017 05:21 AM, Juha Manninen via Lazarus wrote:
Encoding does not matter any more, as long as it is Unicode.
reminds me of a saying
On Thu, May 4, 2017 at 2:47 PM, wkitty42--- via Lazarus
wrote:
> On 05/03/2017 05:21 AM, Juha Manninen via Lazarus wrote:
>> Encoding does not matter any more, as long as it is Unicode.
>
> reminds me of a saying that is attributed to Henry Ford...
> Any customer
On 05/03/2017 05:21 AM, Juha Manninen via Lazarus wrote:
Encoding does not matter any more, as long as it is Unicode.
reminds me of a saying that is attributed to Henry Ford...
Any customer can have a car painted any color that he wants so long as it is
black.
:)
--
NOTE: No off-list
On Thu, 4 May 2017 09:56:18 +0100
Tony Whyman via Lazarus wrote:
>[...]
> I don't believe that string indexing even works for UTF8 strings at
> present - at least not in a simple s[i] way.
It exists the same as for UTF-16 strings.
> Is it really that much
On 03/05/17 17:53, Sven Barth via Lazarus wrote:
Am 03.05.2017 14:37 schrieb "Tony Whyman via Lazarus"
>:
> On the other hand, AnsiString and UnicodeString are still separate
types. Why? Why should there not be a single
On Wed, May 3, 2017 at 6:13 AM, Ondrej Pokorny via Lazarus
wrote:
> Not if you need pre-unicode Delphi support :)
>
> (Well, Marcos didn't specify what Delphi version he wants to target but he
> stated "If Delphi sources don't use UTF8 [...]", which applies to
>
On 2017-05-03 20:47, Juha Manninen via Lazarus wrote:
> If you share and edit the sources between Delphi and Lazarus then you
> cannot use the full Unicode.
Quite comical considering that the FPC team always makes such a big fuss
about "we want Delphi compatibility", and now it seems to be
On 03.05.2017 21:47, Juha Manninen via Lazarus wrote:
> Why Delphi adds the BOM? Why can't it just read the file and
> understand it is UTF-8?
Probably for the same reason as FPC: the default code page if no BOM is
available and no command line option is set and no $codepage directive
is found is
On 03.05.2017 21:47, Juha Manninen via Lazarus wrote:
How many people are editing their sources in both Delphi and Lazarus?
Me, but I keep the files ASCII-only because I need to target all Delphi
versions down to D5 :/ My customers really demand it, unfortunately. I'd
like to kill these
Am 03.05.2017 14:37 schrieb "Tony Whyman via Lazarus" <
lazarus@lists.lazarus-ide.org>:
> On the other hand, AnsiString and UnicodeString are still separate types.
Why? Why should there not be a single unified string type with (e.g.)
ASCII, UTF8 and UTF-16 (or MS Unicode) being just another code
Am 03.05.2017 11:34 schrieb "Graeme Geldenhuys via Lazarus" <
lazarus@lists.lazarus-ide.org>:
> For example, take a look at ConEmu for Windows.
> * Tab support built-in
> * Resizeable console windows
While not point and click you can resize console windows (and the window
buffer) without
Am 03.05.2017 um 11:03 schrieb Juha Manninen via Lazarus:
> How could this thing be communicated so that people understand?
It would probably help if there weren't three different pages about "Unicode
Support" on the wiki, all saying slightly different and conflicting things
(because they talk
On Wed, 3 May 2017 13:37:24 +0100
Tony Whyman via Lazarus wrote:
>[...]
> On the other hand, AnsiString and UnicodeString are still separate
> types. Why? Why should there not be a single unified string type with
> (e.g.) ASCII, UTF8 and UTF-16 (or MS Unicode)
On 03/05/17 09:52, Graeme Geldenhuys via Lazarus wrote:
[rant]
ps:
Both FPC and Delphi is in such a messed up state when it comes to
string and character types. It is the laughing stock of programming
languages at the moment. At least EMBT is heading in the right
direction with their
On Wed, May 3, 2017 at 5:59 AM, Graeme Geldenhuys via Lazarus
wrote:
> On 2017-05-03 01:21, Marcos Douglas B. Santos via Lazarus wrote:
>> Sorry about that. I stopped using Delphi at version 7, that uses ANSI.
>> I thought that Delphi nowadays was using UTF16.
>
>
On Wed, 3 May 2017 12:03:41 +0300
Juha Manninen via Lazarus wrote:
>[...]
> Please also look at program LazUnicodeTest in components/lazutils/test/.
> It does advanced Unicode stuff and works in both Delphi and Lazarus.
I tried it:
First it did not compile in
Am 2017-05-03 um 11:34 schrieb Graeme Geldenhuys via Lazarus:
> I don't know why anybody would still want to run the standard Windows
> console - it is 20 years behind everybody else.
The reason: It is available on every Windows machine.
The alternatives need to be installed first
so scripts
On Wed, May 3, 2017 at 12:13 PM, Ondrej Pokorny via Lazarus
wrote:
> Not if you need pre-unicode Delphi support :)
Ok, true. IMO such old Delphi versions should not be used any more for new code.
Maintenance tasks only I think.
Fortunately there is again a free
On 03.05.2017 11:21, Juha Manninen via Lazarus wrote:
Windows already supports Unicode in everything ... except for console
output! Why is that?
You can start the console with UTF-8 codepage:
http://stackoverflow.com/questions/14109024/how-to-make-unicode-charset-in-cmd-exe-by-default
Then
On 2017-05-03 10:25, Ondrej Pokorny via Lazarus wrote:
> You can start the console with UTF-8 codepage:
> http://stackoverflow.com/questions/14109024/how-to-make-unicode-charset-in-cmd-exe-by-default
>
> Then you have full unicode (utf-8) support.
Or use the much better console alternatives.
On Wed, May 3, 2017 at 11:52 AM, Graeme Geldenhuys via Lazarus
wrote:
> At least EMBT is heading in the right direction with their
> Linux Delphi compiler - they completely removed AnsiString.
I must agree with you. I hope it will be removed in (far) future when
On 03.05.2017 11:03, Juha Manninen via Lazarus wrote:
I am puzzled why there were so many misleading and confusing replies,
also from knowledgeable Lazarus developers.
Remember, the question was about making sources compatible with Delphi.
The person (Marcos Douglas) did not know details of how
Marcos Douglas B. Santos wrote:
> I am develop on Windows. What problems do you mean?
Unicode is recommended also on Windows. No worries. You don't need to
use the old system codepages.
People who need them must convert them explicitly because the Unicode
system of Lazarus does not support them
On 2017-05-02 09:30, Juha Manninen via Lazarus wrote:
> From FPC's point of view our UTF-8 solution is a hack.
FPC's point of view or Marco's point of view? Just curious - so what is
FPC’s “correct” solution then for using UTF-8 and the preferred
encoding? What's the alternative they offer?
On Tue, May 2, 2017 at 5:30 AM, Juha Manninen via Lazarus
wrote:
>>> 1. Assign a constant always to a type String variable.
>>
>> What do you mean? Instead of create a constant, is it better create a
>> String variable and assign the string to it?
>
> From FPC's
On Tue, May 2, 2017 at 5:58 AM, Juha Manninen via Lazarus
wrote:
> On Sun, Apr 30, 2017 at 7:37 PM, Marcos Douglas B. Santos via Lazarus
> wrote:
>> If Delphi sources don't use UTF8, how is the best way to mantain sources
>> that need
On Tue, May 2, 2017 at 2:30 AM, Marcos Douglas B. Santos via Lazarus
wrote:
> So, as Mattias said, we should code using ANSI chars and everything will be
> Ok.
No, you can use all the Unicode freely.
The source files are saved as UTF-8 by default. Delphi does the
On Mon, May 1, 2017 at 11:06 AM, Juha Manninen via Lazarus
wrote:
> On Mon, May 1, 2017 at 12:30 PM, Tony Whyman via Lazarus
> ...
>
> No! The good idea is to use "String".
I agree.
>> 5. Take care when using string literals.
>> I added
>> {$IFDEF FPC}
>>
On Mon, May 1, 2017 at 8:47 AM, Mattias Gaertner via Lazarus
wrote:
> Option a) You can use English in sources and load all non ASCII
> constants via resourcestrings or similar. Then the codepage is
> irrelevant.
> Option b) You can store all files as UTF-8 with
On Mon, May 1, 2017 at 6:30 AM, Tony Whyman via Lazarus
wrote:
> Marcos,
>
> When I originally created the Firebird Pascal API package, I wrote it with
> FPC as the only intended target. However, I then got feedback asking for
> Delphi compatibility and I couldn't
On Mon, May 1, 2017 at 7:40 PM, Tony Whyman via Lazarus
wrote:
> I am not sure how much your second post rows back from this but I do think
> that false is a bit harsh.
Yes, sorry, it was correct when using the default types in FPC 3.
However making it compatible
Am 01.05.2017 18:50 schrieb "Tony Whyman via Lazarus" <
lazarus@lists.lazarus-ide.org>:
>
>
>
> On 01/05/17 16:33, Sven Barth via Lazarus wrote:
>>
>> Would you please elaborate on these and which FPC version you targeted?
>>
>> Regards,
>> Sven
>>
>>
>>
> I am working with FPC 3.0.x and an
On 01/05/17 16:33, Sven Barth via Lazarus wrote:
Would you please elaborate on these and which FPC version you targeted?
Regards,
Sven
I am working with FPC 3.0.x and an example of the solution I used
follows. Note that with FPC, there is no problem calling a constructor
from a
On 01/05/17 15:18, Juha Manninen via Lazarus wrote:
On Mon, May 1, 2017 at 12:30 PM, Tony Whyman via Lazarus
wrote:
When I originally created the Firebird Pascal API package,
Now I realize your code may have been for FPC but not for Lazarus.
Even then the
On Mon, May 1, 2017 at 12:30 PM, Tony Whyman via Lazarus
wrote:
> When I originally created the Firebird Pascal API package,
Now I realize your code may have been for FPC but not for Lazarus.
Even then the solution provided by LazUtils (2 files there) is good
Marcos,
When I originally created the Firebird Pascal API package, I wrote it
with FPC as the only intended target. However, I then got feedback
asking for Delphi compatibility and I couldn't resist the challenge of
seeing how easy it would be to convert the source code. In the end, it
was
It months ago I realized that Lazarus was saving the sources like that:
1- If there is only ANSI chars, save it as ANSI encode;
2. If there is more than ANSI chars, save it as UTF8 encode;
(correct me if I'm wrong about that)
I think this was changed when I updated my FPC to 3.* and Lazarus
87 matches
Mail list logo