Re: Blocking for input during a loop?
Re: Blocking for input during a loop?
- Subject: Re: Blocking for input during a loop?
- From: Jens Alfke <email@hidden>
- Date: Mon, 18 Jan 2010 13:47:54 -0800
On Jan 18, 2010, at 3:38 AM, Per Bull Holmen wrote:
> You say my initially proposed loop is a bad idea - but lots of applications use this type of loop. The difference is that they do it only inside one window, and block user access to all other parts of the application (modal windows). They do this for wizards and the like, which are far closer to how the game will eventually be than a "regular" application.
That's not really true. A modal dialog is still running the runloop, it's just a nested runloop. So at the outer level it looks like the app has blocked in order to run the modal dialog, what's actually happening is that the runloop is still in charge and handling events as usual, it's just ignoring mouse clicks outside that window. When the runloop is finished with the modal window it returns control back to the original code.
What you're talking about is an inverted flow of control where your code is in charge and periodically calls the runloop to handle an event. It's possible to write code that way, but it gets really messy in the real world because you're privileging one possible flow of control while ignoring the others. So you may be waiting for the user to press button A or button B, but what happens if the user decides to choose the Quit command? Now your loop has to handle that too. What you'll end up with is an explosion of different cases in your event-handling code, which gets just as messy as the normal flow of control would have been, only worse because all the complexity is in one big switch statement.
By contrast, if you've got a cleanly-factored model, you'll be able to keep track of the state cleanly. The model object(s) will have the state, and the controller code will call the model to change from one state to another.
—Jens_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden