A button performs a script. So if you need a script to be perform, then use the "perform script" script step instead of making the user press the button to run the script.
I need the user to press the button? It confirms that they are accepting the changes they have made
You would need to set a global variable that the button has been pressed ($$ButtonPressed="T") then when you would check for this variable if it true run your script then set the global variable back to False else exit the script until the button is pressed.
That works great and solved a few other issues.
The only thing I worry about is how would you control a $$ from effecting previous records when revisited?
How to developers keep track of all the variables they create? Would FM Advanced be a better option as my project seems to be getting rather complicated!
The same script that checks the global variable can then clear it.
I personally think all people who create FileMaker databases should use advanced to do so. The data viewer, script debugger and database design report are invaluable in both developing a database and in learning how FileMaker works.
But other than the ability to watch variable values in the data viewer, it doesn't add much additional capability for managing global variables.
My advice is to make sparing use of them (so you don't have a large number to keep track of) and to document their use. You can add layout text off the right hand edge of a layout for example or add a "developer notes" table and layout just to document such design features.
And keep in mind that global variables disappear when a file is closed so they only persist from the first time they are given a value until the file is closed. And the variables (and their values) only exist for a single user. If two users access a hosted database at the same time, each user has their own set of variables and values (much like you do with global fields).