Dreamora, so what you are saying is that as soon as the o/s generates an event and puts it in our queue, the hook is called, regardless of where you are in the main program loop or what else you are doing. So all events pre-empt anything outside of the hook, is what you're saying?
Then, to be friendly, you should do WaitEvent() to give the o/s some CPU time, which is sort of cooperatively letting the events happen. So if you DON'T do that, then your main program is competing with the o/s GUI code, right?
I thought this is how it worked, too, because the whole point of doing a hook is that you need it where the o/s is locked into a modal scenario and normally your app would be shut out from doing any processing while the user is in that modal situation. So the o/s has to be immediately triggering the hook code as and when the event happens, so that you can update things, right?
For example when you resize the window by dragging the corner, your app freezes and nothing happens until you stop moving the mouse, at which point an event is sent, and only that event gets executed, it returns, and then again your app is locked out until the user releases the mouse button.
The odd thing is that if you move the window with the title bar, while you are not moving the mouse it actually does allow TIMERTICK events to trickle through, even though after you've moved the mouse and you stop it also sends WINDOWMOVE events.
So it's kind of confusing.
I need to know exactly when the hook is called and how, and whether it pre-empts/immediately suspends the rest of your app while it's doing so. I'm getting conflicting answers from Skid, from Dreamora and from apparent behavior of actual programs.
(As to your point #6 Dreamora, yes the virtual machine would need to manage how it deals with multiple programs and time allocation and state preservation etc, but it is possible. I have my own system working. I'm just trying to see how it can be incorporated into event-driven stuff).
Then, to be friendly, you should do WaitEvent() to give the o/s some CPU time, which is sort of cooperatively letting the events happen. So if you DON'T do that, then your main program is competing with the o/s GUI code, right?
I thought this is how it worked, too, because the whole point of doing a hook is that you need it where the o/s is locked into a modal scenario and normally your app would be shut out from doing any processing while the user is in that modal situation. So the o/s has to be immediately triggering the hook code as and when the event happens, so that you can update things, right?
For example when you resize the window by dragging the corner, your app freezes and nothing happens until you stop moving the mouse, at which point an event is sent, and only that event gets executed, it returns, and then again your app is locked out until the user releases the mouse button.
The odd thing is that if you move the window with the title bar, while you are not moving the mouse it actually does allow TIMERTICK events to trickle through, even though after you've moved the mouse and you stop it also sends WINDOWMOVE events.
So it's kind of confusing.
I need to know exactly when the hook is called and how, and whether it pre-empts/immediately suspends the rest of your app while it's doing so. I'm getting conflicting answers from Skid, from Dreamora and from apparent behavior of actual programs.
(As to your point #6 Dreamora, yes the virtual machine would need to manage how it deals with multiple programs and time allocation and state preservation etc, but it is possible. I have my own system working. I'm just trying to see how it can be incorporated into event-driven stuff).