On 03/07/17 21:00, Bo Berglund wrote:
> On Sun, 2 Jul 2017 12:27:45 +0000, Mark Morgan Lloyd<[hidden email]> wrote:
>> You were asking a few days ago about Application.ProcessMessages but >didn't respond to my attempt to tease out your understanding of what was >happening. Have you sorted that out to your satisfaction?
> I made a Lazarus GUI program to convert a serial stream to TCP to aremote server where it was again converted to serial.The question was raised because I have used APM inside the main loopof the application in order for it to process stuff like mouse clicksetc while running the main task.Then I figured that I should make a console program with the samefunctions, but APM is part of the Forms unit and this is not used by aconsole. So I was thinking that maybe the data handling wouyld notwork if it was missing...
> Now I decided to keep the GUI app and use it interactively when I needto run against the remote system.
What's happening there is that an LCL-based program is single threaded,
and if you're in any sort of tight loop you need to call APM to get any
of the usual GUI stuff to work.
When I coded those two extra reads the Linux/Solaris implementation had
a comparatively tight loop, so I added the callback so that if they were
being used in the main thread the GUI would carry on working. The
Windows implementation isn't so careful with that.
If they were instead being called from a background thread you'd
obviously /not/ call APM, since in general that can only be safely
called from the main (foreground) thread. However they can still be
called usefully to put a Sleep(0) in the loop, i.e. a hint to the kernel
that it can reschedule if it wants to.
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
On 04.07.2017 00:06, Mark Morgan Lloyd wrote:
> ... if you're in any sort of tight loop you need to call APM to get
> any of the usual GUI stuff to work.
Including any messages sent by worker threads such as "TThread.Queue",
"TThread.Synchronize", "Application.QueueAsnycCall" and
With the additional afterthought that TThread.Synchronize will stall the
worker thread until the event is able to be handled in the GUI Thread.