Hi,
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?
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.
OF EVENT:Timer
LOOP 20 TIMES
NEXT(File)
IF ERRORCODE() THEN
AllDone=true
BREAK
END
DO ProcessOne
END
IF AllDone THEN
0{PROP:Timer}=''
DO EndProcessing
ELSE
! Update Progress Bar code
END
!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.
And this is the reg setting which needs a reboot before changes take effect.
HKEY_LOCAL_MACHINE / SYSTEM / CurrentControlSet /
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.
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
It was me who rewrote the implementation of event queues for C6 and added the code to eliminate duplicates of some events
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. or we misunderstand you.
If you lower the Timer interval, you will see LESS WM_Timer messages when you subclass and count
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 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
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.
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 [ https://clarionhub.com/faq ] 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
or we misunderstand you.