Hi,
My attempt at a hook example:
A couple of points:
* The 'MyEventHook' function is the 'hook' and gets called *every time* an event occurs (from within WaitEvent - or more precisely, WaitSystem, which is called by WaitEvent).
* Hooks should check the 'data' param to make sure it's valid. In this example it always will be, but it's a good idea in general.
* Hooks should generally return the 'data' param they are passed - this is so other hooks can look at the data too. So if you want to 'block' other hooks, return Null.
Both polled input (KeyDown, KeyHit etc) and the event queue are built on top of hooks - check out the source code to really confuse yourselves!
Why use hooks? Why not just stick with WaitEvent? Well, hooks are mainly useful for dealing with 'modal actions' - actions which involve the user holding down the mouse and doing something, like resizing a window or dragging a scroller.
When the user is performing a modal action, the OS goes into a loop and notifies your app of events via a 'callback function'. Hooks are really just a generalization of such callback functions.
BlitzPlus got around this using a complex system of mirrors and pulleys, but I was nervous about using the same trick on multiple platforms, much to skid's disappointment.
Hope this helps a bit!
My attempt at a hook example:
Strict Function MyEventHook:Object( id,data:Object,context:Object ) Local ev:TEvent=TEvent(data) If ev Print "Event="+ev.ToString() Return data End Function AddHook EmitEventHook,MyEventHook window=CreateWindow( "A window!",0,0,640,480 ) While WaitEvent()<>EVENT_WINDOWCLOSE Wend
A couple of points:
* The 'MyEventHook' function is the 'hook' and gets called *every time* an event occurs (from within WaitEvent - or more precisely, WaitSystem, which is called by WaitEvent).
* Hooks should check the 'data' param to make sure it's valid. In this example it always will be, but it's a good idea in general.
* Hooks should generally return the 'data' param they are passed - this is so other hooks can look at the data too. So if you want to 'block' other hooks, return Null.
Both polled input (KeyDown, KeyHit etc) and the event queue are built on top of hooks - check out the source code to really confuse yourselves!
Why use hooks? Why not just stick with WaitEvent? Well, hooks are mainly useful for dealing with 'modal actions' - actions which involve the user holding down the mouse and doing something, like resizing a window or dragging a scroller.
When the user is performing a modal action, the OS goes into a loop and notifies your app of events via a 'callback function'. Hooks are really just a generalization of such callback functions.
BlitzPlus got around this using a complex system of mirrors and pulleys, but I was nervous about using the same trick on multiple platforms, much to skid's disappointment.
Hope this helps a bit!