Re: Keeping program flow moving nicely
- From: "Eric M. Monsler" <emonsler beamreachnetworks com>
- To: "Timothy M. Shead" <tshead k-3d com>
- Cc: Dave Neary <dneary eircom net>, gtk-list gnome org
- Subject: Re: Keeping program flow moving nicely
- Date: Sat, 10 Feb 2001 16:34:44 -0800
"Timothy M. Shead" wrote:
> Use gtk_timeout_add() to create a 'timeout' signal that gets called,
> say, every 100 milliseconds or so. In your handler for the timeout
> event you decide whose turn it is and call process_move().
What is the gtk behavior in this situation, if it takes more than 100 ms
to do process_move()? I have no idea if this game does so, but I'm
curious what would happen.
Some frameworks promise that a periodic callback function will get
called the correct number of times, even if the callback (or other code)
causes them to occur far later than they ought. In those situations, if
the periodic callback does not have sufficient state awareness to either
deinstall future calls, or do a quick-return, the result could be
disastrous (or, in this case, a UI lockup identical to the initial
Another option would be to manually allow gtk to process its events
between loops. I think it's on the order of:
while (gtk_events_pending ())
The above was from a previous post on a similar topic; I'm not sure
that's correct, but there is definitely a was to do this, basically
substituting your own loop for the main loop.
So, in the computer's-turn loop, after processing a computer move, deal
with all gtk events (which would presumably give the operator a chance
to pause or suspend the game), and then check if the next move was a
computer's. If so, loop, if not, terminate until whatever GUI callback
signals that the player has moved (or released the "Pause" feature).
] [Thread Prev