Trap application (not responding) looping records

Hello everybody.
sometime in loops the application shows that it is not responding (although it running in background).

Yield is the solution when I put it to be executed every certain number of record. but is there a way to let the application recognize that it is not responding and execute the Yield command.

Any suggestion is highly appreciated.


Yields never worked for me, you need to find something else to stop the application, maybe better coding or design?

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.

This is what I am doing now but I try always to keep all actions in the same procedure.


I tried it once but it didn’t work, but may be I was not doing it correctly so I will try again.
Regarding display, I usually use “prompt” to avoid using display and save time.



  • 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.

1 Like

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.

I see a process can be a thread in this text.

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.