There are a few reasons why a MaxGUI application might want to use an event queue as opposed to an event hook.
Firstly, with repeated events like EVENT_MOUSEMOVE and EVENT_TIMERTICK, it is easy to make your program lag if the events are being fired more rapidly than the time it takes to process them. The stack gets longer and longer, your app begins to lag and may eventually crash if the stack becomes too large. By using an event-queue, you poll the events when you are ready, and as repeated events come in, they typically replace any now redundant messages in the queue (for example, a EVENT_MOUSEMOVE to (5,10) when added to the queue will replace any existing EVENT_MOUSEMOVE events). Therefore, if your app get's behind for whatever reason, it is only dealing with the most recent and up-to-date events.
Secondly, if you are emitting events yourself, when using hooks the new event you emitted will be processed before the original calling function has finished which, while in some cases is desirable, in others it can be quite confusing.
Thirdly, you may experience unexpected results when you alter the gadgets you receive an event for from a hook - for example, say you have a combobox, and on EVENT_GADGETSELECT you modify the number of items - in some circumstances, because the code is executed the moment the item changes some parts of the control still haven't updated yet and things might start to go a bit strange. Although these cases are rare, and can be considered a MaxGUI bug, you should be aware that such cases do exist.
If you are careful, you can account for these problems. I tend to use event hooks because I need to debug MaxGUI events at the moment they are emitted, and I like to be able to update my programs as they happen, but MaxIDE uses an event queue which avoids quite a lot of complications that event hooks would bring, thus making it more predictable and stable.
|
