So this seems to be a project that can be done in a no-GUI way by
"manually" calling *CheckSynchronize* and implementing *WakeMainThread*,
so that the event queue can be managed and feed the queue by
TThread.Synchronize and/or TThread.Queue.
Let us know when you get it working.
-Michael
--
__
Michael Schnell wrote:
On 01/07/2014 06:11 PM, Mark Morgan Lloyd wrote:
IMHO, the Pascal way of handling such task is using a thread.
That's in the main code, not a background thread, and I have good
reasons for wanting to do it like that.
OK. There are decent reasons in certain projects.
On 01/07/2014 06:11 PM, Mark Morgan Lloyd wrote:
IMHO, the Pascal way of handling such task is using a thread.
That's in the main code, not a background thread, and I have good
reasons for wanting to do it like that.
OK. There are decent reasons in certain projects. But Generally the
"Pasc
Michael Schnell wrote:
On 01/07/2014 04:25 PM, Mark Morgan Lloyd wrote:
The OP, i.e. I, did not mention doing any I/O in threads.
He said: "I'm reading stdin directly with a tight timeout"
IMHO, the Pascal way of handling such task is using a thread.
That's in the main code, not a backgrou
On 01/07/2014 04:25 PM, Mark Morgan Lloyd wrote:
The OP, i.e. I, did not mention doing any I/O in threads.
He said: "I'm reading stdin directly with a tight timeout"
IMHO, the Pascal way of handling such task is using a thread.
-Michael
--
___
Laz
On 01/07/2014 04:16 PM, Paul Breneman wrote:
So please share what you can. Thanks!
Right now I am too busy with completely unrelated things to do the
planned "active NoGui" Widget Type :-( .
I just can provide some thoughts and offer to reply to any questions if
anybody wants to get on th
Michael Schnell wrote:
On 01/07/2014 03:11 PM, Michael Van Canneyt wrote:
WakeMainThread may or may not be implemented. You should not count on
that.
Right you are.
If you want to have "decent event oriented Pascal programming" (i.e. by
using TThread.Synchronize and/or TThread.Queue for hand
On 01/07/2014 08:22 AM, Michael Schnell wrote:
On 01/07/2014 03:11 PM, Michael Van Canneyt wrote:
WakeMainThread may or may not be implemented. You should not count on
that.
Right you are.
If you want to have "decent event oriented Pascal programming" (i.e. by
using TThread.Synchronize and/or
On 01/07/2014 03:11 PM, Michael Van Canneyt wrote:
WakeMainThread may or may not be implemented. You should not count on
that.
Right you are.
If you want to have "decent event oriented Pascal programming" (i.e. by
using TThread.Synchronize and/or TThread.Queue for handling the issues
the OP
On Tue, 7 Jan 2014, Michael Schnell wrote:
On 01/07/2014 02:22 PM, Michael Van Canneyt wrote:
I think you misunderstand TThread.Queue. It does not notify the main
thread.
Yes it does (from the view of the user), when the environment is decently
crafted (in fact it does the same as TThread.s
On 01/07/2014 02:22 PM, Michael Van Canneyt wrote:
I think you misunderstand TThread.Queue. It does not notify the main
thread.
Yes it does (from the view of the user), when the environment is
decently crafted (in fact it does the same as TThread.synchronize only
that the thread does not wait
On Tue, 7 Jan 2014, Michael Schnell wrote:
On 01/07/2014 02:05 PM, Marc Santhoff wrote:
Graeme G. once posted the source of or a link to a unit called
"ThreadTimer", in which there is TfpTimer. That one is independant from
LCL.
Unfortunately it only helps if thread communication (e.g. by TTh
On 01/07/2014 02:05 PM, Marc Santhoff wrote:
Graeme G. once posted the source of or a link to a unit called
"ThreadTimer", in which there is TfpTimer. That one is independant
from LCL.
Unfortunately it only helps if thread communication (e.g. by
TThread.Queue) is used to notify the main thread)
On Tue, 7 Jan 2014, Marc Santhoff wrote:
On Di, 2014-01-07 at 11:55 +0100, Michael Schnell wrote:
In fact without a GUI binding currently you even can't use TTimer.
Graeme G. once posted the source of or a link to a unit called
"ThreadTimer", in which there is TfpTimer. That one is independ
On Di, 2014-01-07 at 11:55 +0100, Michael Schnell wrote:
> In fact without a GUI binding currently you even can't use TTimer.
Graeme G. once posted the source of or a link to a unit called
"ThreadTimer", in which there is TfpTimer. That one is independant from
LCL.
I don't know if the unit is par
Michael Schnell wrote:
On 12/28/2013 10:07 PM, Mark Morgan Lloyd wrote:
Thanks, I'm reading stdin directly with a tight timeout using fpselect
so it sounds like I should be able to manage something.
This of course requests for a multithreaded application. (i.e. the
threads that handle the b
On 12/28/2013 10:07 PM, Mark Morgan Lloyd wrote:
Thanks, I'm reading stdin directly with a tight timeout using fpselect
so it sounds like I should be able to manage something.
This of course requests for a multithreaded application. (i.e. the
threads that handle the blocking pipes communicat
On 28.12.2013 22:07, Mark Morgan Lloyd wrote:
Michael Van Canneyt wrote:
On Sat, 28 Dec 2013, Mark Morgan Lloyd wrote:
Can TThread.Synchronize() be used in a non-graphical program (i.e.
invoked from a unix shell and interacting with the user by typed
commands) or does it rely on some LCL magic
Michael Van Canneyt wrote:
On Sat, 28 Dec 2013, Mark Morgan Lloyd wrote:
Can TThread.Synchronize() be used in a non-graphical program (i.e.
invoked from a unix shell and interacting with the user by typed
commands) or does it rely on some LCL magic in the main thread which
can't easily be rep
On Sat, 28 Dec 2013, Mark Morgan Lloyd wrote:
Can TThread.Synchronize() be used in a non-graphical program (i.e. invoked
from a unix shell and interacting with the user by typed commands) or does it
rely on some LCL magic in the main thread which can't easily be replicated?
Synchronize reli
Can TThread.Synchronize() be used in a non-graphical program (i.e.
invoked from a unix shell and interacting with the user by typed
commands) or does it rely on some LCL magic in the main thread which
can't easily be replicated?
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinion
21 matches
Mail list logo
