Though you say “clunky”, there’s a lot to like about what you’ve done here. I never thought of using supernow() to come up with a unique timer name, but that’s quite clever.
I also never thought of using pause/resume with timers, that is also quite clever. However, beware, this is going to fail if you start another pause before the first one is finished. For now, probably the best way to do this is to put the code after the pause statement into the timer code. Or you can just put a return after the starttimer statement, put a label after that, and use farcallwithin in the timer code. This is a technique that I use in many places in the new client/server code. It’s a bit clunky, but totally reliable. (I’m not using it with timers, but with urltask(, so that the code runs after communication with the server is complete.)
You’ll also have to be quite careful in your code after the pause, because you have no guarantee that the same window will be open and active at that point, or even that the database is still open. So make sure you check for that. The next beta version will actually have a great way to check/ensure that the same window is active, this was needed for Panorama Client/Server code.
I’ve been planning for a while to implement an executelater statement that would make your code much less clunky. However, it wouldn’t resolve the other potential problems with using pause/resume.
Could you explain why you want to pause for a short time? The reason could affect what the best implementation is.
BTW, Gary you’re solution is fine if it’s ok to hang Panorama and now allow any other UI to happen during the pause. That’s probably not what Thomas wants to happen for 10 seconds, but that’s one reason why I am asking him what the purpose is.