Event Queue question

[Jerle69]

I've done some research and I'm wondering if there is any way I can do what I'm trying to accomplish.

I have an event within the RH macro that needs to run until another event fires. At this time, it should end and process the pending event queue. My problem is, since it itself is an event, I'd recursively be actuating a /doevents call. This is bad.

What I could use/need is a way to interrogate the event queue to see if a pending event exists; if so, I could then terminate the current event which would return control back to the main loop body, which would eventually process the event via /doevents.

I guess what I'm looking for is a Top Level Object like "EventQueue" with at least one member "Count." I guess this could be expanded upon to allow for examining what exists in the queue also, but I'd find it at least useful to see if any events are at least queued up.

Thanks!

[Drumstix42]

Could you not call a Sub from the event sub itself? Or am I thinking of this to simply?

[Jerle69]

Well, not in this case. I have an event that fires and continues doing something until an exit condition exists. If the exit condition is met, it ends the event and transfers control back to a main loop to process other events and do things based on state shifts while the macro runs. The problem is while this one event is running, I want to be able to handle OTHER events and block (and terminate) the current event.

The main problem here is I'm trying to manufacture a thread handler (so to speak) by timeslicing activities within the macro. Events themsevles come in two forms: state changers or disparate activities. State changers are simple: they change some variables and exit, so the main loop reacts differently once the state-changing event completes. Disparate activity type events run until finished (or electively stopped) and then they return control back ot the main event-checking loop that also does certain activities based on state.

My problem is I have a disparate activity type event that needs to be able to process other events (and end if one pops up).

[Jerle69]

I think I've devised a work-around for my problem, but it's a bit of a hack. I can establish a global variable that contains the name of the event that is currently being run. My "blockable" event will set the value of the variable to it's name when first run and call a /doevents every loop. All *other* events will set the value of the global variable to their own event name. After each event's /doevent call, the value of the variable can be interrogated to see if it matches the name of the current event. If it doesn't, that'd mean the event was just blocked by another event and this event should terminate.

Kinda crude, but it works and only costs me one extra global variable. Still would be nicer if we could peek into the event queue without actually processing the events.