From 73daff393722196bf48244ca95dd4f64a351a473 Mon Sep 17 00:00:00 2001 From: Simon Tatham Date: Sun, 19 Jun 2011 13:43:35 +0000 Subject: Changed my mind about midend_is_solved: I've now reprototyped it as midend_status(), and given it three return codes for win, (permanent) loss and game-still-in-play. Depending on what the front end wants to use it for, it may find any or all of these three states worth distinguishing from each other. (I suppose a further enhancement might be to add _non_-permanent loss as a fourth distinct status, to describe situations in which you can't play further without pressing Undo but doing so is not completely pointless. That might reasonably include dead-end situations in Same Game and Pegs, and blown-self-up situations in Mines and Inertia. However, I haven't done this at present.) [originally from svn r9179] --- midend.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) (limited to 'midend.c') diff --git a/midend.c b/midend.c index 0c8b3c0..8f4e4c9 100644 --- a/midend.c +++ b/midend.c @@ -1336,7 +1336,7 @@ char *midend_solve(midend *me) return NULL; } -int midend_is_solved(midend *me) +int midend_status(midend *me) { /* * We should probably never be called when the state stack has no @@ -1347,8 +1347,10 @@ int midend_is_solved(midend *me) * practically, a user whose midend has been left in that state * probably _does_ want the 'new game' option to be prominent. */ - return (me->statepos == 0 || - me->ourgame->is_solved(me->states[me->statepos-1].state)); + if (me->statepos == 0) + return +1; + + return me->ourgame->status(me->states[me->statepos-1].state); } char *midend_rewrite_statusbar(midend *me, char *text) -- cgit v1.1