Question RE Returning Null or 'Data' from Hook FN
BlitzMax Forums/BlitzMax Beginners Area/Question RE Returning Null or 'Data' from Hook FN
| ||
| Hey everyone, Thanks for taking the time to read my question. I'll keep things short: What's the best way to keep hook functions from ignoring emitted events? I understand that returning null effectively bleeps out the event, but it seems that all the other hook functions still take the time to 'look' at this nullified event. I have a program with 5 or 6 hook functions, but only one of them is called frequently. Instead of all 6 functions checking the event's data per emitted event, I'd much rather have the 'frequent' hook function check all events first, and completely intercept them if they are the appropriate type of event: This would mean that 95% or more of all emitted events would be intercepted by that first hook function, requiring only 1 conditional for every event instead of requiring 6 conditional checks for every event. This becomes significant because I am emitting tens of events per second. I know this could be done quite easily through a hierarchical Select-Case block, acting as a 'Master Hook Function', but I'd like to keep my hook functions as separate as possible for reusability purposes. Any advice? |
| ||
| Oh yea, one more question -- is it possible to 'subscribe' to forum threads, and receive email notification when replies are made?? |
| ||
| Haven't really thought about it but I probably would go with a single object which check events. Other object resgister for 'special' events and are informed by the 'registrar'. Maybe a list of object is kept for each event in a TMAP and their 'registered' method is called which contains its own SELECT block. I might have misunderstood the question though so post a simple example of your current solution and ay why it's not good enough. . You can't subscribe to threads. |
| ||
| IIRC i tried it as well and found the same behavior. When an event is 'in progress' it will be checked by any hook. I used then instead a WaitEvent() loop with MyType.OnEvent handler which can easily switched during runtime. Sometimes it worked also for me to peek the event in the queue and kill it before it reached the 'in progress' state or may kill all of them, depends on what you want to achieve:
Function KillAllPendingEvents ()
While PollEvent()
Wend
End Function
Did you measure a performance hit? Because 5-6 hooks with 10-30 events per second doesn't sound too heavy if nothing is done actually. |
| ||
Creating a "Master Event Hooker" object sounds like a viable solution. Instead of calling Addhook EmitEventHook, ThisHookFunction I would call "TMasterHooker.RegisterHook(TMyType)" with some parameters to control hook direction. Then, I would simply add a single hook for the "TMasterHooker", and call TMasterHooker.RegisterHook(TMyType) for each type to be hooked in order of most common to least common. The MasterHooker would iterate through its internal list of registered hooks, checking IDs, and then make the appropriate function call. After returning from that function call, I would simply break out of the iteration loop to prevent the other conditional checks. Not sure how expensive the custom type overhead in Blitzmax can be. This solution may be more trouble than it's worth. JSP - no, at this moment it's more of an intellectual exercise. I have not sought to measure a performance hit. This is all a fairly low priority on my todo list. I was simply wondering if there was an easy or common way to shed a few conditionals. Thank you all for your responses! |
   |