At 11:19 AM -0700 5/12/99, Eric House wrote:
>I'd already tried EvtSysEventAvail. It's working as advertised, as far
>as I can tell. But my "midterm-abort" algorithm still isn't aborting.
Actually, my guess is that it *is* aborting, but then it's getting called again right away.
The problem is that the custom event you're adding to the event queue supersedes the "System" event, so the next time you call EvtGetNextEvent() you get the custom event, and NOT the system event.
This is done by design -- it ensures that any events that get enqueued as the result of some user action are processed before the next user action. That is, if a penDown generates a ctlSelectEvent, which in turn opens a form and generates a winExitEvent and a winEnterEvent, you really want to process all those events before the next pen event is processed.
To work around this, don't try to use a custom event in the queue as your signal that more processing needs to be done. Instead, go ahead and use a global flag when there's more work to do. Call resumeCalculation in response to a nilEvent--which is your signal that there's nothing else to do at that time.
Change your EvtGetNextEvent call to instead call EvtGetEvent and pass 0 as a timeout if the global "moreCalculations" flag is set, and pass -1 otherwise. That way you get the nilEvent right away when there's nothing else pending.
--Bob
- EvtEventAvail and aborting long calculations Eric House
- Re: EvtEventAvail and aborting long calculations rflores
- Re: EvtEventAvail and aborting long calculations Alan Kennington
- Re: EvtEventAvail and aborting long calculations Bob Ebert
- Re: EvtEventAvail and aborting long calculations Bob Ebert
- Re: EvtEventAvail and aborting long calculations Eric House
- Re: EvtEventAvail and aborting long calculations Eric House
- Re: EvtEventAvail and aborting long calculations Bob Ebert
- Re: EvtEventAvail and aborting long calculations Eric House
