On Fri, 5 May 2017, Mattias Gaertner via Lazarus wrote:
I simply can't see myself moving past FPC 2.6.4 at this point. FPC 3.x just
doesn't make any sense.
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
On Thu, 4 May 2017 23:20:33 +0100
Graeme Geldenhuys via Lazarus wrote:
>[...]
> Since FPC 3.0 you must add the flag -FcUTF8 or add {$codepage UTF8} at the
> beginning of the unit.
>
> * Note: This changes all string literals to UTF-16, increasing the size of
> the binary and slowing it down.
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 mus
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, it is part of LazUtils package j
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. I
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 that is attributed to Henry For
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 can have a car painted any color t
On 04/05/17 12:00, Graeme Geldenhuys via Lazarus wrote:
On 2017-05-04 11:18, Mark Morgan Lloyd via Lazarus wrote:> In case it helps anybody
avoid wasted time: looking carefully at what > I've been doing, it turns out that
it's not possible to make an > LCL-based program running on unix (i.e. wi
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 as
On 2017-05-04 11:18, Mark Morgan Lloyd via Lazarus wrote:
> In case it helps anybody avoid wasted time: looking carefully at what
> I've been doing, it turns out that it's not possible to make an
> LCL-based program running on unix (i.e. with X11 etc.)
And it wouldn’t be right if I didn’t offer
On Thu, 4 May 2017, Mark Morgan Lloyd via Lazarus wrote:
On 11/04/17 09:30, Mark Morgan Lloyd via Lazarus wrote:
Apologies if this is an FAQ.
Is there an orthodox way that a Lazarus program can very early on look
at how it's been started and decide whether it can usefully fall back to
a text
On 11/04/17 09:30, Mark Morgan Lloyd via Lazarus wrote:
Apologies if this is an FAQ.
Is there an orthodox way that a Lazarus program can very early on look
at how it's been started and decide whether it can usefully fall back to
a text mode, e.g. to display help info on stdout rather than a messa
On 13/04/17 07:30, Mark Morgan Lloyd via Lazarus wrote:
On 12/04/17 21:30, Carlos E. R. via Lazarus wrote:> Hi,> I'm new on this
list, so if I should post this to a different place,> just tell me.> I
want to find a function that I can use on Linux to write a memory> block
to an arbitrary position
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 overhead to have a simple codepage c
On 2017-05-04 09:56, 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's simple, STOP using index arrays into strings. It doesn't work for
Unicode! Use specialised code-point iterators or somethin
On 2017-05-04 10:15, Graeme Geldenhuys via Lazarus wrote:
> * A "character seen on the screen" could be made up of multiple code
> points. eg: U+0065 (e) + U+0302 (^) gives you ê. So it might look like
> one "character", it is *not*.
Applying better typography to that representation would yield:
I have suggestion for scaling hi-dpi for Speedbuttons with icons
Now: icons scale by any scale, e.g. by 175% if OS scale is 175%
It looks bad for 16x16 ide icons. they are looking broken.
Suggestion:
- until scale <200%, don't zoom icons, paint 16x even on bigger buttons
- scale is >=200%, <300%,
On 03/05/17 17:53, Sven Barth via Lazarus wrote:
Am 03.05.2017 14:37 schrieb "Tony Whyman via Lazarus"
mailto: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.) ASCI
On Thu, May 4, 2017 at 12:55 AM, Graeme Geldenhuys via Lazarus
wrote:
> 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
19 matches
Mail list logo
