YIELD has never worked for me either. I try to execute long running loops in a different thread and send a notification back to the main thread.
John Hickey with ClarionLive has a utility pack that has several useful tools including UltimateNotify with which you can send large chucks of data to any procedure in your app.
For example, something I do is - in the child procedure - I’ll put the return data in a group, create a JSON string from the group, and use UltimateNotity to send that JSON back to the parent procedure. Then load that JSON into identical group and process as required.
You need to change to a Window Timer that processes 20 to 100 records each Event:Timer. Then control returns to the Window Accept loop so other events can process. This is how the Process and Report templates work.
It will run fastest if you update Window controls as little as possible. E.g. only update the Progress control when it changes by 5%. Don’t update/display every record.
suspends execution of the current thread to allow Windows put input messages to the message queue, prepare pending sent messages and to release the remaining quantum of the processor time (=> to reschedule distribution of processor cores between running processes/threads)
calls PeekMessage to dispatch pending sent messages
processes timers for windows and controls in the current thread
invokes an IDLE procedure if any
Windows may grant the new quantum of the the processor time for the thread executed YIELD immediately. In this case it would look like no suspension if there were no pending messages and no IDLE procedure.
Whose message q is this text refering to? Is this the app’s own message Q, an apps thread messageQ, or the messageQ for other apps?
So it looks like all Yield is doing, is terminating the quantum slice for the currently executing thread and then the OS passes the Quantum to another app or background service and one or more threads that might be active.
Clarion, when it handles YIELD, calls the PeekMessage with the second parameter equal to NULL. This means that pending messages are processing by Windows for all windows and controls in the current thread: PeekMessage.Both MsgWaitForMultipleObjects and PeekMessage give the chance to Windows to grant processor time quantum to other processes/threads. The algorithm of processor resources rescheduling takes many factors into account besides nominal thread’s priority.If the thread uses granted quantums completely, Windows increases such thread’s current priority => increases chances for this thread to receive next quantum out of order. You can find some info how Windows shares processor resources between running processes in the book written by David Solomon and Mark Russinovich “Inside Windows 2000”. It is quite old but, I think, it is generally actual in this subject.
AFAIK the quantums and cpu schedulling hasnt changed since 2000. We dont get as much control with cpu scheduling in windows compared to Linux where we have a number of different cpu scheduling algo’s to choose from, which can really benefit and hinder some programs.