Subclassing is a way of intercepting messages sent from the OS, Clarion runtime & addon’s, and other programs to your program.
You can intercept these before the Clarion runtime gets them and process them yourself, choosing to destroy the message or pass it on to the runtime to process (if its a message it would process).
You can learn alot about how the runtime process these messages, which will explain why @MarkGoldberg says what he says.
For a few reasons, you cant guarantee the order the messages will be sent in from various sources, but you will always get a message, it will never be dropped like a network TCP packet due to congestion at a switch by the switch.
However a seperate problem exists with Notify() and Notification(), in that the Notification() buffer is a FILO buffer and imo should be a FIFO buffer. I’ve tried various work arounds like popping them into my own buffer but you cant tell when a message is a from first batch or second batch of messages, unless this is coded into the message. MS also suggestions a message queue should be FIFO (see here)
At that point you’ll likely seek the route of least resistance, like electricity does, and use the Window API’s.
When you subclass and trap messages, you can trap a range of messages, and ignore others.
These are the sort of messages defined by Windows, which the runtime will handled for you in the main where applicable.
The problem is with Notification and its buffer, if you only send one message periodically from a thread it wont be a problem, but if you send a series of messages from a thread in a short burst, it will be a problem because you’ll need to build some sort of encoding into the messages. This problem shows up very easily on slow computers so it helps to test on the slowest cheapest computer you can find.
IF you need to send a message across threads or programs or user security access levels and have the receiving app respond immediately, I would suggest using this api. When an object is sent from one program to another windows goes into a sort of windowless modal state, so you can then have your app/code act immediately. It seems to affect CPU thread switching/scheduling (which is interesting because there is only one Windows Scheduler and yet Linux have a few different CPU schedulers to hand) and the usual rules of CPU thread processing which is discussed briefly here.
The only caveat with using this WaitForMultipleObjectsEx api, is it will pause a simple loop or accept loop until something is recieved, which may not be something you want, in which case use the Window’s api’s for sending and recieving messages mentioned above. This API also doesnt translate to Linux C either, as seen here, here and here.
You can find it in use in clarion code here.