EmitEvent - custom Events
BlitzMax Forums/BlitzMax Programming/EmitEvent - custom Events
| ||
| As I have recognized when trying to help Grisu in the linux section I need some help/ideas: Problem: If I allocate a custom event and then emit it... a loop containing "WaitEvent" will not recognize it as soon as fired/emitted. It is recognized if a system event happens (mouse movement, keypress...) - because then the event queue is checked for new items. "Solution": I circumvented it with a triggering timer - so you can force events to happen (eg every 10ms) but this is contraproductive to the design approach of event based systems. (in the case of grisu it only is used in the case of some loader threads having some work - so that should only be the case on gui startup) Ideas? bye Ron Last edited 2013 |
| ||
| Hiya, Have you tried PostEvent ? |
| ||
| Think you meant PollEvent... thought I tried it yesterday but today it seems to decrease the time the apps waits until the custom event is recognized. So: never mind :D. Thank. bye Ron |
| ||
| I don't think col meant PollEvent, so not sure. When using WaitEvent PostEvent is normally the right way to store a new event in the internal event queue. EmitEvent is used to trigger the hooked functions, that means without queue and with the chance to flood the system if you don't take care yourself (own queue) or to hang the system in case of a loop. PollEvent doesn't wait and makes the event system a bit useless and raises the cpu power, but can still be useful in some cases. |
| ||
| like you stated: postevent posts a new event to an managed queue. But the problem here is: WHEN does that queue get processed. It gets processed as soon as something like an mousemovement or app-mode-change happens. I want to emit/trigger/fire... a custom event which should be get recognized as soon as possible. The problem was gone using "PollEvent" - or a Timer-Instance with a short interval which emits TimerTick-Events. bye Ron |
| ||
| I did mean PostEvent. Heres an example using a custom user event with PostEvent which is detected as you're expecting. Edit:- Or if you want a slightly different logic :- Last edited 2013 |
| ||
| It appears to be a bug in the event system, that it doesn't actually cause an emitted event to post as a sychronize op on the internal event code (within brl.system). BRL.Timer does do this, of course, sending a bbSystemPostSyncOp() which triggers all the core stuff to cause the WaitEvent to unlock and process events. On Linux for my QtMaxGUI module, I also had to plug into this low-level code so that my Qt event-loop would process both UI and non-UI (eg. timers) events. Of course, being low-level, it's all rather undocumented ;-) |
| ||
| Dave, in your code you are assuming that the custom event will somehow (by itself) trigger the waitevent() to process it. I believe that assumption is false, and that it so happens that your clicking of the mouse button is still settling down as your event is posted. In fact, if you look at PostEvent, all it does is add the event to a queue. It doesn't trigger anything after that to cause the queue to be reprocessed. Only some low-level event (system/UI/timer) will bring it back to life… |
| ||
| How do we prove the bug? with a delay before or after posting the event maybe? But the Delay may also trigger an internal system event that in turn gets picked up by BMax. Even when clicking and leaving the mouse alone it still gets picked up. Hmm. Edit: tut codetags :) Jeez. I get it now. Never noticed or come across it before. Just goes to show that you learn something new every day eh!! Last edited 2013 |
| ||
| In fact, if you look at PostEvent, all it does is add the event to a queue. It doesn't trigger anything after that to cause the queue to be reprocessed But isn't that enough? PostEvent adds is to the queue (from somewhere in the code) and after processing of whatever the program does it comes back to the Repeat loop and goes into WaitEvent(), which checks if there is something in the queue, finds the event, does all the checks... When working with the queue there is no instant action like with the hooked functions. Is there something I overlooked? |
| ||
| If WaitEvent() is waiting, it doesn't "see" any new non-system events added to the queue. When WaitEvent() starts, it does poll the queue for outstanding events, but once it is in wait-state an EmitEvent will not wake it up. Only system-level events will do that. |
| ||
| Brucey: thanks for backing my post ... it is exactly the problem I stated in the first posting of that thread. bye Ron |
| ||
| I see what you mean, but then from where should the PostEvent come from? As Mark said the event system is not thread safe, so the main thread can not stay in the WaitEvent/WaitSystem state and at the same time emit a PostEvent. And when it has just emitted an PostEvent it will come to the WaitEvent() and check the queue. So then there should be no problem. For multithread the event system is not usable, which is a shame because waking up other threads by event is quite normal, this really should be fixed. @ron So I assume the event was sent by another thread? (That was not mentioned in the first post). |
| ||
| Yes, sorry I forgot it to mention (that the event is emitted from a thread). I thought of simulating an event so the "waitEvent" will recognize it. bye Ron |
   |