Thanks for the suggestions, but as I mentioned in my post back on the 1st, I have got it working OK....
Henry, I looked at that, and while your idea works, (I think, I didn't test it) it is a balancing act that doesn't really fit...- if the delay is to short you get multiple cycles if the button is still pushed, if to long you have to wait for the delay before it will see the next push. If I want to see a particular state (I found there were problems when reaching the top and bottom of the channel range in the main code) I might want to cycle the button really fast to skip over the parts that aren't of interest, which I don't think your method would reliably allow...
Craig - I think we are both doing the same thing, just backwards - I put the wait-for-button-push code in the function call, and the do-the-task code in the main loop... Last step in the main loop is to call the function - which sits until the button is pushed, when it returns and lets the main loop run another cycle.
The only thing that's tricky is to get the function call in the right place if there is an "inner loop" in the main function, in which case you need to put it inside that loop. Also it might be an issue if you have branching code that jumps around, similar deal...
I also have a bunch of serial print statements in the main code so I can see just what it's doing, but that aren't really needed otherwise.
As it sits, I can run the sketch in "single pas" or "normal" mode just by commenting out the function call. When I am ready for "production" code, I will just trim out the function call, and delete the function, along with all the diagnostic serial print lines...
IMHO my cleanup is a little easier, but there isn't enough difference to worry about...
ex-Gooserider