No, I do not think so. Scripts are written in XML and not easily accessible from vanilla FMP.
About FmPro Script Diff
FmPro Script Diff compares, edits, searches and stores FileMaker ScriptMaker scripts - outside the FileMaker database. Changed scripts are compared on a line-by-line basis and displayed with color coded tags to the left of each modified line. Interline changes are also highlighted to indicate Changed, Added or Deleted text. Each script’s XML source can be manually edited or updated via the Search & Replace feature, and pasted back into FileMaker.
ScriptMaster 4 is a free, general-purpose plugin. It includes file manipulation, URL and network utilities, shell scripting, encryption, and much more.
Google "import scripts site:filemaker.com"
https://www.google.com/search?q=import+scripts+site%3Afilemaker.comImporting scripts from other FileMaker filesFileMaker Pro allows you to Copying and pasting scripts.scripts from other FileMaker files. You can also copy and paste scripts between files. SeeMany scripts refer to files, fields, layouts, records, and other scripts. In addition, some script steps, such as Set Field, Insert Calculated Result, Replace Field Contents, and so on, may have field references embedded in calculations. While these references may be valid in the original file, it is possible that they will be invalid in the file into which they are being imported.When you import a script, FileMaker Pro attempts to map fields, layouts, tables (including those used in relationships), and so on based on their names. Fields and layouts are mapped using their, and these must match exactly or the reference will not be imported. If the referenced object cannot be found, FileMaker Pro flags it as missing. After importing a script you should edit the script to make sure that all references are valid and appear as intended.Important Always review your imported script before performing it for the first time.
To import a script:1.Open the file into which the script will be imported.2.Choose Scripts menu > Manage Scripts. Or, choose File menu > Manage > Scripts.3.In the Manage Scripts dialog box, click Import.4.Open the file that contains the script(s) you want to import.5.In the Import Scripts dialog box, select the script(s) you want to import.If one or more of the scripts you’re importing refer to other scripts, make sure you select and import all the referenced scripts at the same time. For more information, see the Notes below.6.Click OK.The Import Summary dialog box appears.7.Click Open Log File to view the import log file, or click OK to close the Import Summary dialog box.If FileMaker Pro reports errors, follow the steps in Creating and editing scripts to correct the <unknown> references in each script. During the script import, FileMaker Pro checks all references to fields, layouts, other scripts, files, and so on, in each imported script. References must match exactly to be included in the import. If a referenced object is not found, FileMaker Pro flags it as <unknown>.8.Close the Manage Scripts dialog box.Tip You can import scripts into a folder by selecting the folder, then clicking Import.
Notes•The match for field names is not case-sensitive.•When importing a script that references a related field, thefield names must match identically, including the names of the tables as they appear in the .•When importing script steps that contain calculations (for example, If, Set Field, and, Insert Calculated Result), if FileMaker Pro cannot match all items referenced in the calculation (i.e. tables, fields, or custom functions), the calculation is commented out (using ‘C’ style comments).When importing scripts from single table files, you can avoid most of these naming difficulties by making a copy of the file containing the script you want to import. In the copied file, rename the table to match one of the tables in your destination file, and import the script from the copy. Script steps that refer to identically named fields and layouts in both files will import properly because the underlying table in the source file has the same name as a table in the target file.•When importing script steps that contain more complex information (for example,, , import field order, and export field order, etc.), FileMaker Pro discards any missing field references.•To import a script, you must have access privileges in the source file that allow you to modify the script.•The option Run script with full access privileges is only imported when the user performing the import has logged into the target database with full access privileges.
Difference Between A Script Step Vs. ScriptMaker
What is the difference between a script step and ScriptMaker?
Updated: May 24, 2011
Often there is confusion on the terminology of a Script Step and ScriptMaker. The following defines the difference between these two and the architecture of scripts. To clarify some of the confusion between the two, the following is a breakdown of actual script steps and the ScriptMaker feature.
Script steps are the set of commands, which are in the ScriptMaker feature, to be added to a script, in order to automate tasks or operations inside of FileMaker Pro. Many FileMaker Pro script steps can be made available to web users when you publish your database using Instant Web Publishing.
There are 12 categories of script steps:
- Control – Special variables that affect the script as it runs.
- Navigation – Going to specific parts of the database or entering specific modes.
- Editing – Actions that are found in the Edit menu.
- Fields – Field specific modifications.
- Records – Record specific modifications.
- Found Sets – Actions to obtain or modify a found set of records.
- Windows – Actions to change the visual aspect of database windows.
- Files – Actions found in the File menu.
- Accounts – Account and password management and Re-login script step.
- Spelling – Perform and modify spelling and dictionaries.
- Open Menu Item – Open various features and menus.
- Miscellaneous – Assorted script steps to perform internal and external actions.
The ScriptMaker feature in FileMaker Pro is a building tool for creating scripts by selecting from a list of FileMaker Pro script steps. You are then able to specify options (if necessary), and arrange the steps in the correct order to perform the task.
Some tools within ScriptMaker include:
- Creating scripts.
- Editing scripts.
- Deleting scripts.
- Duplicating scripts.
- Printing scripts.
- Importing scripts.
- Performing scripts from inside of ScriptMaker.
- Creating Groups for easy management of alike scripts.
- Creating separators to divide scripts and groups.
- Filter specific groups to be displayed.
- Filter scripts based on naming conventions.
- Indicate if a script should be included in the Scripts menu.
- The ability to indicate a script to be ran with full access privileges
- Display web compatible script steps, which can be seen by checking the "Indicate web compatibility" check box, which will disable any non-web compatible script steps.
An example of a printing script that shows a custom dialog with printing options:
This example asks the user if they would like to print giving 3 options of; “Cancel”, “PDF”, or “All Records.” The script then performs an If Statement which checks to see which option were chosen, which then exits the script after the selection is completed.
For more information on script steps, please refer to the FileMaker Pro 9 Scripts Reference Guide.
Planning Scripts with FileMaker Pro
What do I need to know about scripts in FileMaker Pro?
Updated: Sep 20, 2011
Planning a Script
The more time you spend planning your script, the more likely that it will accomplish what you want. As you plan, ask yourself these questions:
Can you separate the task into smaller tasks? You can define sub-scripts for each small task, and then define a script that performs the sub-scripts. It's easier to design and test several small scripts than one complex one. You can also reuse sub-scripts in other areas. (Use Perform Scriptscript step to perform a sub-script inside another script.)
What script steps should be executed under what conditions? Should every script step always be executed? Should some be executed a number of times until a certain condition is met? Should the script call other scripts and sub-scripts? You can control the progression of the script in a number of different ways. See Control script steps for more information on creating scripts with conditional steps.
Do you want the script to run in a particular layout? Because scripts are defined at the file level and can be called from any layout, you should make sure the script will operate in the layout or layouts you expect. Use the Go to Layout script step to change layouts. Use the If script step and other Control script steps to perform script steps based on conditions you define, such as layout name.
Is all the data you need in one database file, or will the script operate on more than one file? If you're using multiple files, which ones should the script open? In which file should the script(s) be defined? In most cases a script should be defined in the same file as the data it is processing. Database solutions with more than one file may need separate scripts in each file, depending on the complexity of the task you are trying to script.
With which record should the script start? For example, when using the Loop script step, you must decide whether the loop starts at the first or last record, a specific record, or the current record in the found set. (Use the Go to Record/Request/Page script step, Go to Related Record script step, or Go to Portal Row script step to specify a starting record. If you don't include a navigation script step to determine the current record, the loop begins with the record that's current when the script is performed.)
Should the script switch among modes? A script can be run from Browse, Find, Layout, or Preview modes. Make sure your script is in the proper mode before it acts upon something. For example, use the Enter Browse Mode script step to modify data in fields and records, and use the Enter Find Mode script step to set up or perform a find request.
Note Scripts performed in Layout mode automatically switch to Browse mode before executing.
In File Maker, copying and pasting scripts are not quite easy as scripts never behave like texts, that can be copied and pasted in Filemaker script editor. If there are some modifications in some of the scripts in a file, then it is not needed to copy and replace the whole file in the client's live application, Modification should be done for that particular script. It happens that if some logic or new functionality is required to be implemented, then there is a need to create the scripts at the developer's end and QAing will done for that new modification, then that script again needs to be written in the Client's live application. Because of live data, the script written in the client's end can not be checked. As the script is written directly and not tested then that script may have some defects. Those defects will appear at the time of work for that functionality in live, which is a big problem. To prevent this kind of situation, "Import Script" option can be used.By using import script, a script can be imported to any other system which are in network, Then script steps can be copied and pasted in the existing script at the client end.What needs to be done ?
Which fields and layouts will the script need? Some steps require a field to be on the current layout (like the Go to Field script step, the Insert Text script step, and the Insert Calculated Result script step, while others, such as the Set Field script step and the Replace Field Contents script step, don't. Use the Go to Layout script step to switch to a layout that has the fields your script requires.
Should the script work on all records in the database, the current found set, or a specific set of records? (Use the Perform Find script step, the Show All Records script step, the Show Omitted Only script step, the Omit Record script step, the Omit Multiple Records script step, and the Modify Last Find script step to include only the records that you want to work with in the found set.)
Should the records be processed in a certain order? Decide among the current sort order, a specified sort order, or unsorted (the order in which the records were created). Use the Sort Records script step or the Unsort Records script step before entering a loop to order your records properly before processing them.
How should the script advance through multiple fields or records? (Use the Go to Record/Request/Page script step, the Loop script step, the Exit Loop If script step and the End Loop script step to control multiple field or record processing).
When should the script finish? After all records have been processed? After a specified condition has been met? (Use the If script step, the Else If script step, and the Exit Loop If script step to perform a task when the script reaches a specified condition.)
How will you test your script? Use the Pause/Resume Scriptscript step to pause at predefined points in your script. Save a clone of your database, and then define and test your script in it to preserve the original data. After testing the script, import data from the original file into the clone.
How will you handle error conditions (such as an empty found set)? You can capture the last error condition reported by FileMaker Pro by using the Get(LastError) function. Use this function and the If script step, the Else If script step, and the Else script step to create scripts that react gracefully to user errors or unexpected results. For even greater control, use the Set Error Capture script step to suppress the error alerts that FileMaker Pro normally displays in these situations, and replace them with your own using the Show Custom Dialog script step.
Should all users be allowed to perform all scripts? Use privilege sets to control users' access to scripting. Through the use of privilege sets, users can be allowed to execute or modify individual scripts, no scripts, or all scripts. You can also set the default permission for each privileges set for any future new scripts that are defined in the file. Setting a Script to run with full access privileges will allow the script to do things on behalf of the user that may not be normally allowed by their assigned privileges. See Creating and managing privilege sets for more information.
How will users perform the script? You either need to create a button to perform the script or specify that the script be added to the Scripts menu. Scripts can also be run from the Define Scripts dialog box or when a database is opened or closed. See Setting file options for information about running scripts when files are opened or closed.
- Need to host the application file from where the script can be imported to any other
- Need to open the filemaker file in which script needs to be imported..
- Click on Scripts option, Click on Manage Scripts. All these should be done for the particular file where the scripts need to be imported.
- Click on Import button (Alt+I).
- Choose the file form where Script needs to be imported.
- Choose the script, Need to check the check box at the right of the script.
- Click on OK.
It will import the script.
Open the imported script, Copy all the script steps, Paste those scripts all the steps if the script is already existing then you need to rename that script, because after import of the same script after some modification, application will refer to the newly imported script.For Remote - Client End.Need to host the filemaker file in a server from where the file can be accessible in client end.
Need to give Network file path and the file name. like - fmnet:/126.96.36.199/main.fp7
The filemaker application from where the script will be imported, that application should be enabled for Network Sharing.
To enable network sharing - Go to File - Sharing - Filemaker Network, Click on the radio button for ON to active network sharing for the
After importing of the script and pasting the script steps, it is necessary to check once for the relations of the tables.The source table and the target table for all the relationships should be present.
Troubleshooting Scripts: Hints and Tips
Troubleshooting Scripts: Hints and Tips
Updated: Oct 31, 2007
FileMaker Pro 7, FileMaker Pro 6, FileMaker Pro 6 Unlimited, FileMaker Pro 5, FileMaker Pro 5 Unlimited, FileMaker Pro 3.x, FileMaker Pro 2.x, FileMaker Pro
Note: If you are at all unsure of changes you will be making to your script, make a duplicate of the script and test out the changes there. Never work on your only copy of a script!
Using the Pause/Resume script step
One of the most useful approaches to troubleshooting scripts is to use the Pause/Resume step to check conditions during the execution of the script. You can check the value being returned by a step in a script by creating a test field, and adding a step to paste into that field, then pausing the script. When you are done, you can delete the field's definition and delete those two steps from your script.
[Your previous script steps]
Paste ["Value Check Field"]
Pause/Resume Script 
You can put this series into your script many times, and check the progress of the script at each important point. This will indicate where you have the wrong value being copied or returned or will confirm that you have the correct value.
Divide the script into distinct portions
It can very difficult to look at a long script and be able to tell where the problems are. Dividing a long script into several parts may make it possible to tell where a problem is happening and certainly makes it easier to create complicated scripts. This also makes each part of the script available to use in other chains of scripts.
Hint: If you already have a script and wish to divide it, you can duplicate the script and delete the unwanted parts rather than re-entering each part.
Example: You have a long script that does a find, exports records, does another find, sorts, then prints. It changes layouts to perform each of these actions.
Instead of one long script you might organize it like this:
Perform Script["Find all the Hints"]
Perform Script["Export the Hints"]
Perform Script["Find the Tips"]
Perform Script["Sort by Article Number"]
Creating a Script Plan/Flow Chart
If your script is complicated, or if you have several scripts calling each other, you might want to draw out a flow chart or list. This will help you understand and visualize the flow of information.
Here is a simple flow list:
- Copy the customer ID
- If the invoice has been paid, exit the script
- If customer ID is over 1000 and the customer type is retail, go to the Retail file and paste in the ID to create a new record
- If the customer ID is less than 1000, go to the Charitable Foundations file and paste in the ID, and run the 'New ID script'
- Return to the original database and go back to the original layout
You can see that this list is in plain language. There may be additional steps to flesh out and this leaves out many details, but you at least have a readable road map. Most people find this easier to translate to a script than trying to work within ScriptMaker to set up complex systems. You can also use a drawing program to draw a flow chart.
This is extremely valuable in scripts that contain Loops. Using this technique and the Pause/Resume Script step as outlined above can help track down problems that are extremely difficult to visualize from a script.
Here's a list of things to check when your script is not doing what you expect:
- Is it going to the right layout?
- Are you trying to copy to or paste from a field that is not on the current layout?
- Is the field you are looking at in Browse mode really the field you think it is?
- Have you checked the result of your conditional ('If' script step)?
- Are you trying to do something in your current file that is actually happening in an external script?
- Are your conditionals and loops in the right place?
- Is the script doing the Find you expect it to?
- Do you have a Restore on a Find or Perform Find that shouldn't be there?
- Is your script doing 2 Finds, effectively canceling out the First find?
- Do you have a Find that finds no records?
- Is the script doing the Sort you expect it to?
- Are your fields sorting in the correct order (ascending or descending)?
- Does the user's password allow them to do what the script does?
- If the script is dependent on a calculation, is the calculation returning the correct value and type?
- Is there a step in the script that is dependent on platform?
- Do you need to go to Preview to see the results of the script?
- Are you freezing the window and not refreshing it (it will refresh at the end of the script automatically)?
- Are you checking for the right message results?
You can copy and paste the calculations that might be used for set variable, calculated field, etc. These could be created in a text editor.
You can copy and paste scripts and steps within scripts to another script.
People LOVE FileMaker for its point and click and eliminating most of the hassle of typing plain text to create commands and scripts. That's why I changed to FileMaker 30 years ago after becoming totally frustrated by DOS command line and dBase and Visicalc functions that errored out but wouldn't tell me why.
Perhaps you could use SQL instead of Filemaker steps?
You can use the Snipped database coming with MBS FileMaker Plugin.
So if you copy some script steps in FileMaker, you can use Clipboard.GetFileMakerData function in a solution to get the XML, edit it and put it back on the clipboard with Clipboard.SetFileMakerData. Just like the FileMaker Snippet Storage database included in plugin examples.
The same can be done with ClipManager from myFMbutler. So theoretically you could write it all in a text editor. And for the longest time I have wished that we could but the script editor in 15 and even more so in 16 has become so close to what I expect from a good code editor that I don't feel that need so pressingly anymore.
Replaces / refactoring / auto-complete of variable names are still issues that I wish to see made better in FM's script editor.