In Panorama 6 you could sometimes, eventually, stop a running procedure with command-. So far all I’ve found to manually stop procedures in Panorama X is to Force Quit the application, which sometimes feels like overkill. It’s a minor point, but am I missing something?
There is no way to stop a running procedure in Panorama X. Try to write your procedures such that they don’t need to be aborted.
The ability to abort a procedure is a nice safety valve if you write an endless loop into a procedure, but there is a possible drawback – someone can abort a procedure before it is finished and a task is left only partially done. This can cause serious problems. For this reason most programming languages don’t allow manual aborts other than force quit, and I decided that Panorama X should not either.
I figured as much and certainly understand the problems from having data in limbo. I don’t miss manual aborts in done, working procedures. It’s while I’m writing them and having error > trial that I miss them. But getting the code done is a continuum with no good point at which to toggle manual breaks so your choice is right. At least Panorama X generally Force Quits gracefully and relaunches quickly. And I can test my trial code with stop or rtn thrown in after the questionable code.
I don’t think anybody tries to write code that needs to be aborted.
A possible compromise might be to implement the
enableabort statement that would support the Command-Period aborting so that you could include it at the beginning of a procedure while developing it. It would enable the abort scheme as long as the procedure is running or until a
disableabort is issued. This would be the reverse logic as Panorama 6 were the Command-Period was automatically enforce unless the
disableatort statement deactivated it.
Since code in Panorama 6 would use the
enableabort statements in that order it should not effect their code at all. The
disableabort would have no effect since it is disabled already by default and the
enableabort was used when it was specifically requested and it would be automatically dismissed at the end of the procedure.
I really like Gary’s suggestion. I had not recognized the inability to do a Command-. to abort a endless loop issue. I’m typically have several databases open at one time and the thought that I will have to lose any edits made to unSaved open databases is not a pleasant thought. I was not thinking that the ‘average’ user would know that they could abort a procedure while it was running and have never experienced a problem aborting my own code in progress.