Wallace wrote:
RobA wrote:
The simplest way I've found to kill badly behaving scripts is to delete the layer they are working on. This usually causes them to fail, and then you can undo the layer delete (as long as the undo stack wasn't disabled by the stack author, that is...)
That's a good suggestion RobA, but wouldn't it be easier to just click on the 'cancel' button in the script's dialog box? Being able to click 'cancel in the script's dialog box' would just stop whatever the script is from running, nothing else need be done after this, script canceled end of story.
What's so difficult about this procedure that I'm not getting? 
Disclaimer: I'm not an expert on the Operating System/Gimp Programs architecture/interaction.
Try thinking of it this way.
My guess is that when you initiate the script running by clicking on the menu item, the Gimp process initiates script-fu.exe to start in a new process and passes it the script name as an parameter. At completion, the Gimp process receives the status of success or error details if the script ends abnormally.
What you are requesting is that on every computer cycle, script-fu.exe stop what it is doing to see if the Cancel is currently being pressed/clicked, if not continue for another cycle, then check again.
This would slow things down so much - redundantly checking for the rare occasions that there actually was a key press/mouse-click.
Or the script-fu software would have to be written in a way to have multiple processes running. One process that controls everything, initiating the script-fu.exe process running and receiving it's completion state, and another to checking for user interactions. Determining whether or not to end the script-fu process.
My guess it has been written in a manner like my former explanation.
As I said this is a layman's explanation and will soon be corrected by an 'expert', but it might offer some insight into the mysterious inner workings of software while you wait.