On Jun 30, 2006, at 3:49 PM, Tomas Zahradnicky wrote:
but have to use RNE because I could not use nested
RunAppModalLoopForWindow. IIRC one QuitEventLoop quitted all
nested RunAppModalLoopForWindows so I had to choose a different
option.
Hmm, I wouldn't expect that to be a problem, actually. We should
reset that state after the current event loop has returned.
I believe that Navigation Services should eat the quit event as it
borrowed the current event loop from the app and the app does not
expect to quit according to RNE's documentation.
Possibly. We'd need to see a test case and debug it to see what
exactly is going on here.
In any case, I think the proper approach is generally just to
ignore a return value of eventLoopQuitErr from ReceiveNextEvent,
and loop around to call ReceiveNextEvent again.
So it is preferred to have a custom message to quit rather than
obeying eventLoopQuitErr?
Yes. In general, your custom event loop should be something like this:
while ( !gQuitNow )
{
if ( ReceiveNextEvent( ..., &event ) == noErr )
HandleEvent( event );
}
and then you set gQuitNow somewhere in your code where you determine
that your event loop should quit. Note that I never do anything
special with the return value from ReceiveNextEvent; if it's noErr,
then I've got an event to handle, and if not, then I don't.
QuitEventLoop is _not_ meant as a general "quit the app now"
mechanism. It's really just meant to cause the current call to the
event loop to return back to the caller. It's up to the caller to
know, via other mechanisms, whether it should actually quit the app
at that point.
-eric
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
