That's how we do it. Of course, we try to handle all this in the
controllers, not in the model, so it propagates up to the controller
from the model via a delegate or something and then we use the state
machine there.
On Jan 28, 2009, at 4:19 PM, Jan Brittenson wrote:
Jerry Krinock wrote:
Does anyone have an idiom or way of appreciating this problem which
does not produce such spaghetti and headaches?
How about a state machine:
enum State { STATE_INIT, STATE_PREPARE, STATE_EXECUTE,
STATE_FINISHED, STATE_DEAD };
State state;
HandleEvent(event)
{
switch (state) {
case STATE_INIT:
// initialize here
state = STATE_PREPARE:
// fallthru
case STATE_PREPARE:
if (need_some_particular_state_first) { break; }
if (need_user_response) { ask_for_it(); break; }
state = STATE_EXECUTE;
// fallthru
case STATE_EXECUTE:
// do stuff
state = STATE_FINISHED; // so when display is dismissed we
continue
display_results();
break;
case STATE_FINISHED:
// wrap up
state = STATE_DEAD;
// fallthru
case STATE_DEAD:
break;
default:
assert(0);
}
}
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/alex%40webis.net
This email sent to a...@webis.net
Alex Kac - President and Founder
Web Information Solutions, Inc.
"I am not young enough to know everything."
--Oscar Wilde
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
