Hi,
"official" Unicode support in FPC has been discussed for so long
(years), that I came up with my own solution for fpGUI since 2007 (LCL
did the similar) and it still works 100% and well tested. But now I want
to learn what the FPC team finally came up with in FPC 3.0.
Is there some white pape
Graeme Geldenhuys wrote on Thu, 10 Dec 2015:
Is there some white paper, blog post, awesome MvC article that explains
it all. And how it compares to Delphi's Unicode support (if this is
important - though I don't use Delphi at all any more).
http://wiki.freepascal.org/FPC_New_Features_3.0#Supp
Hello,
in a couple of programs I'm using this idiom:
FMyThread:=TMyTread.Create;
FMyThread.FreeOnTerminate:=false;
FMyThread.OnTerminate:=@MyThreadTerminate
procedure TMyForm.MyThreadTerminate(Sender:TObject);
begin
//do something with FMyThread then
FreeAndNil(FMyThread);
end;
With fpc
Am 10.12.2015 11:05 schrieb "Luca Olivetti" :
>
> Hello,
>
> in a couple of programs I'm using this idiom:
>
>
> FMyThread:=TMyTread.Create;
> FMyThread.FreeOnTerminate:=false;
> FMyThread.OnTerminate:=@MyThreadTerminate
>
> procedure TMyForm.MyThreadTerminate(Sender:TObject);
> begin
> //do some
On 2015-12-10 09:50, Jonas Maebe wrote:
>
> Graeme Geldenhuys wrote on Thu, 10 Dec 2015:
>
>> Is there some white paper, blog post, awesome MvC article that explains
>> it all. And how it compares to Delphi's Unicode support (if this is
>> important - though I don't use Delphi at all any more).
>
On Thu, Dec 10, 2015 at 10:26:29AM +0100, Luca Olivetti wrote:
> Hello,
>
> in a couple of programs I'm using this idiom:
>
>
> FMyThread:=TMyTread.Create;
> FMyThread.FreeOnTerminate:=false;
> FMyThread.OnTerminate:=@MyThreadTerminate
>
> procedure TMyForm.MyThreadTerminate(Sender:TObject);
>
2015-12-10 11:18 GMT+01:00 Graeme Geldenhuys
:
> On 2015-12-10 09:50, Jonas Maebe wrote:
> >
> > Graeme Geldenhuys wrote on Thu, 10 Dec 2015:
>
> Tried to compile that with FPC (yes, I included the new "Character" unit
> in uses clause) and I get a couple of compiler errors. I tried first
> with
Graeme Geldenhuys wrote on Thu, 10 Dec 2015:
On 2015-12-10 09:50, Jonas Maebe wrote:
http://wiki.freepascal.org/FPC_New_Features_3.0#Support_for_codepage-aware_strings
Thanks, but here's the problem. The wiki says FPC 3.0 is now Delphi 2009
string compatible. So I starting reading the "Delp
On 2015-12-10 10:22, Vincent Snijders wrote:
> And mode DelphiUnicode?
Oh, yet another compiler mode. Okay, just tried, and got these warnings,
but the project at least compiled and generated a binary.
Compile Project, Target: project1: Success, Warnings: 5
project1.lpr(37,47) Warning: Implicit s
On 2015-12-10 10:29, Jonas Maebe wrote:
> The language feature is implemented in a Delphi 2009-compatible way
> (although some Delphi-specific behaviour is only activated in {$mode
> delphiunicode}).
Okay, so forget Delphi 2009 compatibility for the moment (I don't use
Delphi). So does this me
On 2015-12-10 10:35, Graeme Geldenhuys wrote:
> Now I try and run the binary and get the following error.
>
> [t2]$ ./project1
> This binary has no unicodestrings support compiled in.
> Recompile the application with a unicodestrings-manager in the program
> uses clause.
> An unhandled exception o
On Thursday 10 December 2015 12:01:49 Graeme Geldenhuys wrote:
>
> ===
> program project1;
>
> {$mode delphiunicode}{$H+}
>
Try {$codepage utf8}.
Martin
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.free
El 10/12/15 a les 11:13, Sven Barth ha escrit:
Am 10.12.2015 11:05 schrieb "Luca Olivetti" mailto:l...@ventoso.org>>:
>
> Hello,
>
> in a couple of programs I'm using this idiom:
>
>
> FMyThread:=TMyTread.Create;
> FMyThread.FreeOnTerminate:=false;
> FMyThread.OnTerminate:=@MyThreadTermi
Graeme Geldenhuys wrote on Thu, 10 Dec 2015:
On 2015-12-10 10:29, Jonas Maebe wrote:
The language feature is implemented in a Delphi 2009-compatible way
(although some Delphi-specific behaviour is only activated in {$mode
delphiunicode}).
Okay, so forget Delphi 2009 compatibility for the mom
Martin Schreiber wrote on Thu, 10 Dec 2015:
On Thursday 10 December 2015 12:01:49 Graeme Geldenhuys wrote:
===
program project1;
{$mode delphiunicode}{$H+}
Try {$codepage utf8}.
That won't change anything, because {$mode delphiunicode} implies "use
the default s
On Thu, 10 Dec 2015 12:17:28 +0100
Jonas Maebe wrote:
>[...]
> > Try {$codepage utf8}.
>
> That won't change anything, because {$mode delphiunicode} implies "use
> the default system code page to interpret the source code", and that's
> UTF-8 on his system.
Does that mean a {$mode delphiuni
On 2015-12-10 11:10, Martin Schreiber wrote:
> Try {$codepage utf8}.
It made no difference to the console output.
Regards,
- Graeme -
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/f
On 2015-12-10 11:16, Jonas Maebe wrote:
> There is no such thing as "official FPC Unicode". We added support for
> codepage-aware ansistrings. We added unicodestring overloads for a
Does the type UnicodeString always mean UTF-16 encoded text (like it's
Delphi counterpart)? If so, that unfortun
Mattias Gaertner wrote on Thu, 10 Dec 2015:
On Thu, 10 Dec 2015 12:17:28 +0100
Jonas Maebe wrote:
That won't change anything, because {$mode delphiunicode} implies "use
the default system code page to interpret the source code", and that's
UTF-8 on his system.
Does that mean a {$mode delph
On Thu, 10 Dec 2015 12:02:31 +
Graeme Geldenhuys wrote:
> On 2015-12-10 11:16, Jonas Maebe wrote:
> > There is no such thing as "official FPC Unicode". We added support for
> > codepage-aware ansistrings. We added unicodestring overloads for a
>
> Does the type UnicodeString always mean
Mattias Gaertner wrote on Thu, 10 Dec 2015:
If you have a working Unicode solution there is no reason to abandon it.
Exactly. There is absolutely no point in changing your code to
unicodestring in reaction to these changes (nor in reaction to future
changes an sich, if we can help it). Th
On 2015-12-10 12:18, Mattias Gaertner wrote:
> If you have a working Unicode solution there is no reason to abandon it.
> The FPC team did a great job keeping compatibility (contrary to Delphi).
Indeed - from what I have tested and seen using FPC 3.0 with fpGUI. So
kudos to the FPC team for that!
I use a four method pattern with threads, while reusing the same thread
class everywhere.
1) define a status method to update your user interface based on feedback
from the thread
2) define a terminate method to do clean up when a thread finishes
3) define a work method where the thread does its e
Am 10.12.2015 12:15 schrieb "Luca Olivetti" :
> It's obvious that you cannot free the thread from inside a "normal"
Synchronize call, it's no so obvious you cannot do it in the OnTerminate
method, so maybe a note could be added in
>
> http://wiki.freepascal.org/User_Changes_3.0
>
> The new implemen
On Thu, Dec 10, 2015 at 02:49:50PM +0100, Sven Barth wrote:
> Am 10.12.2015 12:15 schrieb "Luca Olivetti" :
> > It's obvious that you cannot free the thread from inside a "normal"
> Synchronize call, it's no so obvious you cannot do it in the
> OnTerminate method, so maybe a note could be added in
Am 10.12.2015 15:06 schrieb "Henry Vermaak" :
>
> On Thu, Dec 10, 2015 at 02:49:50PM +0100, Sven Barth wrote:
> > Am 10.12.2015 12:15 schrieb "Luca Olivetti" :
> > > It's obvious that you cannot free the thread from inside a "normal"
> > Synchronize call, it's no so obvious you cannot do it in the
On Thu, Dec 10, 2015 at 05:23:41PM +0100, Sven Barth wrote:
> Am 10.12.2015 15:06 schrieb "Henry Vermaak" :
> > Is it worthwhile mentioning that OnTerminate gets called with
> > Synchronize()? I had to dig into the source to verify this.
>
> That would indeed be worth mentioning, but that would b
I am experiencing a weird issue regarding threading and shared libraries
under Linux. I've boiled it down to a very simple test case in hopes you
can help me understand what I'm doing wrong.
I'm running this test with FPC 3.0 (built from source) on x86_64 Debian
Linux.
First, I have this shared l
Interesting: playing around with it some more, if I put an empty try/except
block inside my library's function from the example I posted, it leaks the
memory whether or not I'm using cmem.
-SG
--
Seth Grover
Be kind to all of your neighbors
Because they're just like you.
And you're nothing speci
29 matches
Mail list logo