Are timer events queued?

I have a hand written process procedure that uses the window timer to allow access to the OS. Basically the process runs through a given number of records and exits. Then on the next EVENT:TIMER, I call YIELD and then continue processing the records from where I was the previous time. This repeats until all the records are processed.

I have the TIMER set to 1.

The process works fine, except for one thing. The window doesn’t seem to be yielding to the OS. I can’t move the window with the mouse, and I can’t cancel the process by pressing the button I have for this purpose.

I don’t know what could be the problem, but the only explanation I have is that the TIMER events are getting queued, and thus interfere with other events such as moving the window or pressing a button on the window.

Are timer events queued? Or can you guys think of another cause?


Not sure if they’re getting queued, but I usually shut off the timer while I’m processing through “a given number of records”.

Perhaps it would help you to rule that out.


   0{PROP:Timer} = 0
   DO ProcessRecords
   0{PROP:Timer} = MyTimerSetting
1 Like

Hi Jeff,
Excellent idea! I will try that. Thanks.

BTW, I had a question I wanted to ask you about your sqlite memory table example, but I will post as a new question so it can be better referenced by others.

There should be no need to YIELD(). That may be causing you problems. Post an except of your code.

Each Event:Timer you process a reasonable number of records, say 20 to 50, it depends on how complex and large of files. Will it be on a LAN or WAN.

      DO ProcessOne
   IF AllDone THEN 
       DO EndProcessing
       ! Update Progress Bar code
    !Timer event ends so other events can process

I dont know what API the Clarion Yield is using. It might be this one
SwitchToThread function (processthreadsapi.h) - Win32 apps | Microsoft Docs
the easy way to find out would be fire up the debugger, set a breakpoint on Yield and then switch to the disassembler window and look at the Yield to see what its calling in windows.

Now you might also be interested in altering the thread priority for your app.
This is a good article on the cpu time slicing and threading etc but technical.
Processes, Threads, and Jobs in the Windows Operating System | Microsoft Press Store

Some more on multi tasking on windows
Multitasking - Win32 apps | Microsoft Docs

This explains the quantum time slice in particular
Thread Scheduling and Benchmarking (

And this is the reg setting which needs a reboot before changes take effect.
Control / PriorityControl / Win32PrioritySeparation

They can be, it depends on what you are doing in your loop. My success with Yield has been variable so like others have suggested, I disable the timer when a timer event is fired, do the work, then enable the timer again. Another way is to start a new thread when the event timer is fired but these threads can queue up if they are being blocked, paused or whatever but at least you can see all these threads queued up. And if starting a thread from the timer event, you might have to factor handling messages from the OS thats its shutting down, so subclassing a hidden window thats running on the new thread is one way to handle those situations.

It can get complicated, but a timer event ever 1ms is quite alot for low end cpu’s that are using spin disks and not alot of ram. You dont say what spec machine it is and what else is running on the machine at the same time. Some machines I’ve seen in the past have so much running, its a wonder the user cant actually use it for anything other than looking at a screen. Low spec laptops are worse than low spec desktops in this situation.

Things like AntiVirus scanning files in realtime can also add an overhead which could see threads and file writes getting queued up very quickly. So if you have some sort of file writing work taking place in the timer event, see if AV’s can be setup to ignore certain file extensions and/or certain folders, in order to remove that delay, some AV’s have this options others dont, but in my experience most people dont use that AV option and can sometimes see tps file corruptions as a result, but you dont say what sort of work is being done in the timer event, so its difficult to really say what the problem is as there could also be other factors at play.

Following events are not queued:

  • EVENT:Timer
  • EVENT:NewSelection
  • EVENT:Moved
  • EVENT:Sized

The window’s event queue can contain the only event of every of these kinds.

Do you mean:

The Clarion event queue can only contain one instance or event from these events

  • EVENT:Timer
  • EVENT:NewSelection
  • EVENT:Moved
  • EVENT:Sized

There is no “Clarion event queue”. Every OPENed window has its own queue. If new event has been generated or posted, the RTL performs some checkings before add it to the event queue of the top window of the current thread (or one specified by the 3rd parameter of POST or 2nd parameter of NOTIFY). Among other things, if new event has one of 4 kinds listed earlier and the event queue already contains event of the same kind,

  • the RTL replaces information from the new event to already queued one if event code is EVENT:NewSelection and newly selected control is other then in the queued event
  • discards new event otherwise.
1 Like

Your comments are most appreciated.

Thanks a lot!
Best regards,

It was me who rewrote the implementation of event queues for C6 and added the code to eliminate duplicates of some events :slight_smile:

Clarion events are not Windows messages. Any number can be presented as 0x0400 + some n.

This is not true. The Clarion RTL uses some internal messages but they are processing in windows’ functions as well as normal Windows messages without any specific filtering. Also, most control-specific messages declared in COMMCTRL.H have codes greater than WM_USER.



But it’s nearly impossible it was you who wrote it.
As you are incorrect. :wink: or we misunderstand you.

  1. If you lower the Timer interval, you will see LESS WM_Timer messages when you subclass and count

  2. We subclass all the time Listboxes and other controls, and its fully driven upon WM_User plus messages. Numbers in between 10000 and 14000. We can show you the prove. It contradicts what you write.

The methods pointed at by the Prop:VLBVal and Prop:VLBProc handle the source input and back to the gdi renderer (commctrl)

From indeed within the normal Windows OS message queue. (not a clarion internal queue) (Of the ?listbox(prop:handle) wndproc ) as listbox = a window on its own. We see the messages with our own eyes :slight_smile: on the subclassed listbox.

And the prove of it is when you subclass the listbox and click here and there.

We know, because we worked on the listbox subclassing for over a year and use prop:vlbproc a lot (which is not driven by internal clarion queued events but by methods sending wm_user messages to the components) (as its needed also for tools for blind people and so on, and the tab to a next control etc, its all wm_user driven. Even the selects in listboxes

Its very strange you have written this while the events are really ending up in the message queues

Maybe some pre cache for deduplication purposes but still ending up in the normal windows message queue

Or we misunderstand you, please explain :slight_smile:

Once again. Clarion events ARE NOT Windows messages and Clarion event queues ARE NOT Windows message queues.

Of course, the Clarion RTL both sends/posts messages to Windows and processes messages sent/posted by Windows. Particularly, to implement the TIMER attribute on WINDOWs or controls the RTL

  • creates the timer by call to the SetTimer API function
  • processes WM_TIMER messages posted by Windows for that timer and adds the EVENT:Timer event to corresponding WINDOW’s event queue

The event queue can discard some events if it contains more earlier instances of events having the same type.

The Clarion RTL creates timers for other purposes besides handling of the TIMER attribute. For example, timers are using verify whether the mouse hook must be removed.

The Clarion RTL does not use Windows standard list and combo controls. Their implementation is completely Clarion own. Yes, the RTL uses some LB_* and CB_* message codes for the same purposes as Windows standard lists and combos, for example, LB_SETSEL or CB_SHOWDROPDOWN. But the “GDI renderer” is not using.

It would be very strange to not handle Wndows messages in programs running in Windows OS.


It sounds strange for me that several new forum users don’t understand the difference between Windows messages and Clarion events.

Let this statement be on your conscience.

Reread my previous posts. Every Clarion WINDOW has its own event queue. I never wrote about "Clarion internal message queue.

Meaningless set of words.

From ClarionHub Admin

As a reminder, ClarionHub was created to be a community space for people
who work with Clarion to get help, teach, learn, offer related products and services, find releated work, communicate.

We do expect you to keep the guidelines [ ] in mind when posting
Such as “ *Be Agreeable, Even When You Disagree.”

If you feel the need to criticize something,
please find a way to do so constructively

Keep your posts useful for someone to read,
instead of venting your frustrations here.

note: I have better things to do than to moderate these forums
I’m losing my patience; I will suspend silence users who cannot be civil


Thank you for your explanation…

Then all is cleared.

You mean Post Message vs Send Message?

We had read it wrongly then.

You worked at softvelocity as you wrote!
Thats amazing.

We thought, then maybe wm_timer is issued twice and picking up the internal clarion messages.

For how long you worked up there? With Diego? With Russ Eggen?

Thanks so much for your clarification.

Thanks ! Great info.

Great !

I don’t understand your question.

I worked for TopSpeed over 3 years and then 21 years for SoftVelocity. I left the company on February 18, 2022.

Russell worked for TopSpeed, not for SV, and as most other TS/TSDC employees passed to (renamed later to Seisint).

Have you retired then?

No. There were 2 reasons for that but this is off-topic.