Logan,
Thanks for the reply. It sounds a bit more complicated than I'd hoped.
Let me explain exactly what I'm trying to accomplish.
My application is a board game where the user makes a move, then waits
for the program to compute a counter-move. If the user sets the skill
level very high, the counter-move calculation could take a long time,
perhaps 45 seconds to a minute.
During the calculation, it's not valid for the user to do anything else
with the application itself, like select another function or open a
menu. So I don't care about throwing away application events.
However, I want to allow things like system alerts to show; if the user
presses the Find button, I want that to interrupt the calculation; if
the phone rings, I want them to be able to answer it; and if the user
decides to give up and exit (by selecting another application or
pressing the Home key) then I want to abort and let my application
exit.
I have part of that working now by doing this:
EventType event;
EvtGetEvent(&event, 0);
while ((event.eType != nilEvent) && (event.eType != appStopEvent)) {
SysHandleEvent(&event);
EvtGetEvent(&event, 0);
}
return (event.eType == appStopEvent);
The function in which this occurs returns "true" to force the game
algorithm to end early. Doing this does cause the Find dialog to pop-up
while the app is otherwise in its busy loop. However, pressing the Home
button does not generate the appStopEvent that I was expecting. It does
generate a few pen up/down events, but that's about it.
Let me know what you think. Thanks.
--- Logan Shaw <[EMAIL PROTECTED]> wrote:
> Frank LaRosa wrote:
> > In the documentation it talks about polling for events periodically
> if
> > you need to do something that would otherwise keep the CPU busy for
> a
> > long time. But it doesn't give an example. I'm assuming this means
> I
> > should call EvtGetEvent(&EventType, 0) and then send the event to
> > SysHandleEvent, and if it's not handled there, then just ignore it.
> Is
> > that right?
>
> Another model is to just do your big processing in response
> to any nilEvent you may receive. You can call EvtGetEvent() with
> a non-zero timeout in your main event loop, and when the timeout
> expires, you will receive a nilEvent. If you do a little bit
> of processing (say, less than 5 seconds, and preferably more like
> 1 second or less) when you get a nilEvent (if there is processing
> left to do), then everything works reasonably well.
>
> However, I think if you went with the model you're describing,
> you'd want to do the whole cascading chain of things you do
> in your main event loop, which works out to be basically this:
>
> SysHandleEvent (&event) || MenuHandleEvent (&event)
> || AppHandleEvent (&event) || FrmDispatchEvent (&event)
>
> This ensures that menus are handled and that your form event handlers
> get the events. (And no, I don't *really* write my main event loop
> with lazy "or" operators, in case you were wondering.)
>
> > I'm also assuming that the OS wouldn't start a new application
> before
> > it shut my application down, which couldn't happen during my
> > long-running calculation if I ignored the appStopEvent message.
>
> The OS doesn't shut your application down. It just sends you an
> appStopEvent and waits for you to handle it. In other words, the
> application shuts down as soon as your return from the PilotMain()
> function.
>
> > What happens if I get an event for my own application during this
> time?
> > Do I put it back on the queue?
>
> Probably the best thing to do would be to handle the events in the
> exact same way that you handle them in your normal event loop. You
> could define a function that handles events for your whole
> application,
> then call that function in the main event loop and any subsidiary
> event
> loops that you run while you're doing other computation. The only
> thing
> to be aware of in that case is that some of your code may actually
> need
> to be reentrant if it is called from your main event loop and then
> called again from your subsidiary event loop that happens while
> you're processing other stuff.
>
> Bottom line is, you can do the method you're talking about, or you
> can just have one and only one event loop. Either can be made to
> work, but I prefer the one and only one model because it makes
> the code less complicated (assuming whatever computation you are
> trying to do doesn't start to become really ugly when you have
> to make it part of the main event loop, which basically means
> making it into a state machine).
>
> Of course, all this will become easier once OS 6 comes out and
> threads exist. Whenever that is... :-)
>
> - Logan
>
> --
> For information on using the Palm Developer Forums, or to
> unsubscribe, please see http://www.palmos.com/dev/support/forums/
>
>
--
For information on using the Palm Developer Forums, or to unsubscribe, please
see http://www.palmos.com/dev/support/forums/
