I don't see why the buttons cannot call the "main" script directly - with a different parameter for each button.
That would work if you wanted to restart the script for each button and then execute steps conditionally on the script parameter. The problem I have is that my scripts tend to do set up code at the start before putting up the layout that contains the buttons. If I use the ButtonID script as I implemented it, I can pause in the middle of the layout controlling script and return to the pause/resume script step. The ability to resume in the middle of the script makes it easier for me to follow the flow of the code.
I'm guessing that I could have the buttons execute a pause/resume script step and then have the code conditionally execute based on the name of the current object. I think I might have tried this and either it didn't work or it seemed more cumbersome than a one script step script that resumes with a global variable set to the button tag
Then again, I could be missing something really obvious!
I'm afraid I don't get this part:
my scripts tend to do set up code at the start before putting up the layout that contains the buttons. If I use the ButtonID script as I implemented it, I can pause in the middle of the layout controlling script and return to the pause/resume script step. The ability to resume in the middle of the script makes it easier for me to follow the flow of the code.
I dont get it atall, it sounds like you are over-complicating the entire situation
Why not just categorise the scripts in sub folders for each layout ?
I have thousands of scripts and dont have a problem debugging anything with the script debugger.
Of course, if you only have filemaker pro, I can sort of see where you are coming from but still I would think it would be more difficult to debug 1 script which caters for a lot of different actions.
From what I can make of the posts above, it sounds to me like your going to outgrow this implementation rather quickly which will then make it hard work to change, since you would need to edit every layout to change the button actions, and re-create a load of scripts.
SW, your sub-folder approach is great. It is a real clever way to do encapsulation of the layout. I like it a lot and will use it for sure.
I must be explaining this very badly or it must be a horrific idea...let me try again.
In response to SW, am not suggesting that you tear up your existing code apart and use this method. On the other hand, I find that using this technique from the get-go results in layouts and code that are easier to maintain. If I want to add a button to a layout, I simply set it up so that it calls my universal button interpreter script with a descriptive script parameter and with the ‘resume' option. The script handling the layout pauses, waiting for a button to be pressed, and then executes the appropriate script steps based on a global variable which has been assigned the script parameter by the button interpreter script.
Here is an example of a script snippet that might be used instead of a ‘show custom dialog'/get(LastMessageChoice) combo. This script and layout could be generalized into a user designed custom dialog box with a little more work, but I think it illustrates what I am doing. The script snippet assumes that there is a layout with some data and buttons that might be similar in content to a custom dialog, with fields and data entry ability, as well. This hypothetical layout has three buttons, let's say. ‘Yes', ‘No' and ‘Cancel'. In the layout editing, each button invokes a call to the common
button handler with the ‘resume' option and the name of the button as the script parameter. There is only one code instance of the common button handler script in the entire project.
The common button handler script is one line and it just moves the script parameter to a global variable, $$Button, e.g:
Set variable [$$Button; get(ScriptParameter)]
The rest of the code would look like this:
Go to Layout [ <the hypothetical layout>]
Set variable[$$Button; ""] /* clear the button field before starting to make sure the last usage isn't still around */
Pause/Resume Script [Indefinitely]
If [$$Button = "Yes"]
...do the ‘yes' response code
Else if [$$Button = "No"
....do the ‘no'
Else if [$$Button = "Cancel"]
...do the ‘cancel' code
This would be akin to:
Show Custom dialog["What do you want to do"; "Choose a button";<put in some data entry fields>]If [ get(LastMessageChoice) = 1]
Else if [get(LastMessageChoice) = 2]
Else if [get(LastMessageChoice) = 3]
But the first example has all sorts of flexibility in layout design, number of buttons, etc.
Maybe I'm on the wrong track, but it has helped me organize my code and layouts where there is lots of user interaction with lots of choices.
Go to Layout [ <the layout with buttons> ]
Pause/Resume Script [Indefinitely]
If [ Get(ScriptResult) = "Yes" ]
# DO THE "YES" THING
Else if [Get(ScriptResult) = "No"
# DO THE "NO" THING
Else if [Get(ScriptResult) = "Cancel"
# DO THE "CANCEL" THING
And for the script attached to the buttons:
Exit Script [ Result: Get(ScriptParameter) ]
Very cool indeed!!
Your implementation is elegant, eliminating the global variable.
It does indeed make more sense now.
With regards to the drop down menus etc, can you not use an 'onObjectModify' trigger