On 02/25/2015 10:16 AM, Marco van de Voort wrote:
But the only state in it is the self of the method to be synchronized. But
that can be enough (as Sven said)
Hadn't occured to me since I'm synchronizing msgs to a certain controller
context though (my "invoke" has a parameter controller and is r
In our previous episode, Michael Schnell said:
> >> will make the instance remoce itself.
> > You need a full queue for that, since the mainthread might not run till the
> > thread next queue()'s.
> The fpc RTL does implement a full blown queue for managing TThread.Queue
> and TThread.Synchronize.
On 02/24/2015 04:38 PM, Marco van de Voort wrote:
In our previous episode, Michael Schnell said:
On this behalf, "Application.QueuAsyncCall" is more versatile.
But it's easy with TThread.Queue, as well.
- define a class (not to be derived from TThread) that holds the data
to be transferred
On 02/24/2015 05:17 PM, Sven Barth wrote:
Internally Closures are implemented as a class implementing an
interface that provides an Invoke method.
Great !
-Michael
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.
Am 24.02.2015 16:38 schrieb "Marco van de Voort" :
>
> In our previous episode, Michael Schnell said:
> > On this behalf, "Application.QueuAsyncCall" is more versatile.
> >
> > But it's easy with TThread.Queue, as well.
> >
> > - define a class (not to be derived from TThread) that holds the dat
Am 24.02.2015 14:41 schrieb "Michael Schnell" :
>
> On 02/24/2015 11:32 AM, Mattias Gaertner wrote:
>>
>> About closures see for example:
>> https://en.wikipedia.org/wiki/Closure_%28computer_programming%29
>>
> Hence the "pure" closure paradigm does not need object-orientation.
>
> For my feeling i
In our previous episode, Michael Schnell said:
> On this behalf, "Application.QueuAsyncCall" is more versatile.
>
> But it's easy with TThread.Queue, as well.
>
> - define a class (not to be derived from TThread) that holds the data
> to be transferred and a procedure without parameters
> -
On 02/24/2015 11:32 AM, Mattias Gaertner wrote:
About closures see for example:
https://en.wikipedia.org/wiki/Closure_%28computer_programming%29
Hence the "pure" closure paradigm does not need object-orientation.
For my feeling it is prone to introduce some contradiction to
object-orientation
Am 24.02.2015 11:24 schrieb "Michael Schnell" :
>
> On 02/24/2015 11:12 AM, Sven Barth wrote:
>>
>>
>>
>> AFAIK Delphi doesn't use the term "closures" though conceptually
anonymous functions (as implemented by Delphi) are one way to achieve them.
>>
> What is the advantage of using a "closure" and/
On Tue, 24 Feb 2015 11:23:41 +0100
Michael Schnell wrote:
> On 02/24/2015 11:12 AM, Sven Barth wrote:
> >
> >
> > AFAIK Delphi doesn't use the term "closures" though conceptually
> > anonymous functions (as implemented by Delphi) are one way to achieve
> > them.
> >
> What is the advantage of u
On 02/24/2015 11:12 AM, Sven Barth wrote:
AFAIK Delphi doesn't use the term "closures" though conceptually
anonymous functions (as implemented by Delphi) are one way to achieve
them.
What is the advantage of using a "closure" and/or an "anonymous
function" instead of just doing "free;" as
Am 24.02.2015 10:55 schrieb "Graeme Geldenhuys" <
mailingli...@geldenhuys.co.uk>:
>
> On 2015-02-24 09:48, Mattias Gaertner wrote:
> > I think what you mean is "closure".
> > The functions don't need to be "anonymous" for that.
>
> Good to know, and thanks for correcting me. I'll read up on both in
On 2015-02-24 09:48, Mattias Gaertner wrote:
> I think what you mean is "closure".
> The functions don't need to be "anonymous" for that.
Good to know, and thanks for correcting me. I'll read up on both in the
Delphi help. These language features are all new to me.
Regards,
- Graeme -
--
fpG
On Tue, 24 Feb 2015 09:30:37 +
Graeme Geldenhuys wrote:
> On 2015-02-23 19:49, Philippe Lévi wrote:
> > if code in thread access a local variable (in stack) of the function
> > where thread is issued ... it may access "something" which does not
> > exist any more. correct?
>
> Good question,
On 02/23/2015 06:58 PM, Graeme Geldenhuys wrote:
Continuing on the TThread.Queue subject - is there any way to pass
parameters (or record structure with basic types) to the Queue() call?
On this behalf, "Application.QueuAsyncCall" is more versatile.
But it's easy with TThread.Queue, as well.
On 02/23/2015 06:50 PM, Graeme Geldenhuys wrote:
Why not add it to the Wiki then, so your efforts would not have been
wasted.
IMHO, as long as there is no commonly agreed and easy and to use
procedure, quickly creating publicly available online and offline usable
help texts for fpc and for Laza
On 02/23/2015 06:50 PM, Graeme Geldenhuys wrote:
On 2015-02-23 11:25, Michael Schnell wrote:
Let me know if you want to have it.
Yeah please. You can email it to this email address.
I hope I sent all necessary files...
have fun,
-Michael
EventTest.tar.gz
Description: GNU Zip compressed d
On 2015-02-23 19:49, Philippe Lévi wrote:
> if code in thread access a local variable (in stack) of the function
> where thread is issued ... it may access "something" which does not
> exist any more. correct?
Good question, and what I was trying to get at with my second question
on TThread.Queue
PC-Pascal users discussions
Assunto: Re: [fpc-pascal] TThread.Queue vs TThread.Synchronize
On Mon, Feb 23, 2015 at 3:23 PM, Sven Barth
mailto:pascaldra...@googlemail.com>> wrote:
[...]=== code begin ===
procedure TMyThread.Execute;
var
s: String;
procedure SyncOnPrint;
begin
fOnPr
mailto:pascaldragon@
>> googlemail.com>>
>> Enviado: segunda-feira, 23 de fevereiro de 2015 16:17
>> Para: fpc-pascal@lists.freepascal.org
>> <mailto:fpc-pascal@lists.freepascal.org>
>> Assunto: Re: [fpc-pascal] TThread.Queue vs TTh
15:23
Para: fpc-pascal@lists.freepascal.org
Assunto: Re: [fpc-pascal] TThread.Queue vs TThread.Synchronize
On 23.02.2015 18:58, Graeme Geldenhuys wrote:
> Continuing on the TThread.Queue subject - is there any way to pass
> parameters (or record structure with basic types) to the Queue() call
On Mon, Feb 23, 2015 at 3:23 PM, Sven Barth
wrote:
[...]=== code begin ===
>
> procedure TMyThread.Execute;
> var
> s: String;
>
> procedure SyncOnPrint;
> begin
> fOnPrint(s);
> end;
>
> begin
> s := 'Hello World';
> Queue(@SyncOnPrint);
> end;
>
> === code end ===
How to compi
On 2015-02-23 11:25, Michael Schnell wrote:
> Let me know if you want to have it.
Yeah please. You can email it to this email address.
> I once wrote a documentation on how the event queue in the fpc RTL
> works, but failed with the attempt to have it included in the fpc help.
Why not add it t
On Mon, Feb 23, 2015 at 2:44 PM, Graeme Geldenhuys
wrote:
> On 2015-02-23 10:56, Mattias Gaertner wrote:
>> Synchronize waits for the main thread.
>> Queue does not.
>> Both are executed by the main thread via CheckSynchronize.
>> Both are useful.
>
>
> Many thanks for that info. It makes sense no
On 2015-02-23 10:56, Mattias Gaertner wrote:
> Synchronize waits for the main thread.
> Queue does not.
> Both are executed by the main thread via CheckSynchronize.
> Both are useful.
Many thanks for that info. It makes sense now.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI
On 2015-02-23 10:52, Michael Schnell wrote:
> TThread.Queue works very similar to Application.QueueAsyncCall in the LCL
I don't use LCL, so I'm not familiar with all its features.
> Obviously TThread.Queue does not hamper the firing thread, while
> TThread.Synchronize stalls it for an undefined
On 02/23/2015 11:08 AM, Graeme Geldenhuys wrote:
I've look at FPC trunk and see we now have a Queue() implementation, and
I adjusted a simple multi-threaded GUI example app I had. But I still
don't really understand what is the benefit of Queue vs Synchronise. I
still had to create a "synchronis
On Mon, 23 Feb 2015 10:08:45 +
Graeme Geldenhuys wrote:
> Hi,
>
> I've recently seen some posts in Delphi groups that the preferred way is
> to use TThread.Queue instead of TThread.Synchronize.
>
> Why is that? What are the benefits?
Synchronize waits for the main thread.
Queue does not.
B
On 02/23/2015 11:08 AM, Graeme Geldenhuys wrote:
Hi,
I've recently seen some posts in Delphi groups that the preferred way is
to use TThread.Queue instead of TThread.Synchronize.
TThread.Queue just "fires" an Event in the main thread. This means a
"mark" is set that the event handler function i
29 matches
Mail list logo
