Author Archives: sprosser

Multiple Parameters for Scripts

A common complaint about FileMaker (https://www.geistinteractive.com/2014/04/07/top-feature-request-filemaker-14/) is the lack of a native method to pass multiple parameters to a script. Many developers have tackled this problem using different methods, including include Word Count, Value Count, delimiting characters, and creating a dictionary. Read more at (http://www.merlyn383.com/home/2011/7/27/filemaker-passing-multiple-script-parameters.html). One of the most straightforward, stable and easy to use is a custom function from SeedCode (http://www.seedcode.com/pmwiki/pmwiki.php?n=SeedCodeComplete2.ScriptParameters).

For simplicity and clarity, we started with the SeedCode custom function, but changed the name from SeedCode_GetScriptParameter to MultiParam. The new name name is shorter, to the point, and reminds you what the function does. At DBHQ, we use this custom function in every database we create. It’s a building block which will be used in other script examples on this blog.

In fact, because we do use MultiParam in every database we create, you’ll probably see us employ it even when a script only needs one parameter and Get ( ScriptParameter ) would suffice. The logic behind this is that it’s much easier to use MultiParam (even when you only have one parameter) than to go back and retrofit if you later decide that your script is going to need more than one parameter in certain circumstances.

The function lets you create name/value pairs, separated by a semicolon. First you pass the values into the script using the “optional script parameter” field when you specify the script you’re running. Type:

“action = start ; status = active”

In the code above, the word “action” is the name of a thing you’re passing. Its value is “start.” The semicolon marks the end of the first pair. Note that the spaces around the “=” and the semicolon are for legibility. If you just run the code together, the custom function will still work, but your parameter isn’t as easy to read.

After you’ve passed the parameters, you’ll use Set variable script steps, one for each parameter you’ve passed, to read and store the values within a script:

Set variable [$action = MultiParam ( “action” )]
Set variable [$status = MultiParam ( “status” )]

 

In this example, $action is will have a value of “start” and $status will have a value of “active”.

To use a field name in the script parameter instead of static text, use standard FileMaker concatenation:
” action = start ; status = ” & Customer::Status

You can string together as many parameters as you need for your script. Here’s one with three parameters, using a field in the second to illustrate how to construct the parameter when you introduce a field name in the center of it.

“action = start ; status = ” & Customer::Status & ” ; state = ” & Customer::State

Refer to “Creating Custom Functions” (ADD LINK) to see the steps to add this custom function to your database.

The MultiParam function itself has one parameter (Name). The MultiParam function should be made available to all accounts.

—————-BEGIN CODE—————————
/*

Name:
SeedCode_GetScriptParameter

History:
Created by John Sindelar, SeedCode LLC, based on Anton Anderson’s FileMaker Advisor Article of Dec 2005.
www.seedcode.com
Creation Date: 26 Dec 2005
Last Modified Date: 21 Jan 2006

Purpose:
Returns just the named parameter when multiple parameters are passed into a script.

Parameters:
Name

Example:
SeedCode_GetScriptParameter ( “Operation” ) returns “begin” when the script parameter is “Operation = Begin ; Status = Estimate”.

Requires Other Custom Functions:
None

Other Notes:
Where “Name” is the name in a Name/Value pair like: “Operation = Begin”.
Separate Name/Value pairs with semicolons like: “Operation = Begin ; Status = Estimate”.
Quotes are optional in the value: “Operation = Begin ; Response = \”OK\””
Fields can be entered like this: “Operation = Begin ; Status = ” & job::status
If a requested value is not present, the result is blank.

Options:
None

*/

Let ( [
string = Substitute ( Get ( ScriptParameter ) ; [ “\”” ; “^^” ] ; [ ” ;” ; “;” ] ; [ “;” ; “\” ;” ] ; [ “= ” ; “=” ] ; [“=” ; ” = \”” ] ; [“¶” ; “~~” ] ) & “\”” ;
eval = Evaluate ( “Let ( [” &  string  & “] ;” & Name & ” )” ) ;
result = Substitute ( eval ; [ “^^” ; “\”” ] ; [ “~~” ; “¶” ] )
] ;

If ( result =”?” ; “” ; result )

)

—————-END CODE—————————


Creating Custom Functions

When we provide instructions for creating a custom function, we will specifically provide any Parameters which need to be defined, and also provide the code for the function.

The code will be indicated with the following beginning/ending indicators:

———–BEGIN CODE—————————

The actual code will be here. Do not copy the “Begin Code” and “End Code” lines, but do copy everything between them.

———–END CODE—————————

To create the Custom Function, select File—> Manage—>Customer Functions.

 

The Custom Function dialog box appears. Click “New.”

 

In the Edit Custom Function dialog box, enter the Function Name in the top left field.
In the Function Parameters field, enter each parameter separately and click the “+” button to add it to the list.
In the large field that encompasses the bottom half of the dialog box, paste the code we have provided.
Be sure to indicate whether the function should be available to “All accounts” or “Only accounts assigned full access privileges.”

 

Click OK to close all dialog boxes.


FileMaker DevCon 2015 — 20 Years

Category : FileMaker

 

FileMaker DevCon 2015 is right around the corner. If you’re at all serious about upping your FileMaker game, then you need to be at DevCon. It’s ground zero to get the newest thinking on creating software with our favorite database. You’ll be able to choose from over 20 daily sessions that are packed with new information from FileMaker experts.
I remember my first DevCon like it was yesterday, even though it was 18 years ago. Since then, I’ve only missed one DevCon because it’s so crucial to staying current with FileMaker. There’s no doubt that working in the trenches gets you lots of experience, but there’s nothing like seeing how others go about cracking some of the same problems you’ve tackled to broaden your outlook and expand your toolbox. Even better, you get to see solutions to problems you didn’t even know people were having. Great as the sessions are, sometimes a chat over lunch or in the hall between sessions is worth the price of admission when you make new contacts or get pointed toward another great resource.
The first early bird discount period has past, but there’s still time to avoid paying full price. Plus, hotel reservations tend to fill up fast, so it’s not too soon to start making plans. Read more about the full schedule of sessions, speakers, exhibitors, and travel plans.


Giving Users Feedback

No matter what type of database you’re creating, at some point you’re going to find an occasion to employ some sort of method to let your user know they have made an error or neglected to fill in a required value. One method of achieving this goal is through the use of a custom dialog. Another is to use a global variable ($$message) in a merge variable.

At first glance, it may appear that this is more work than using a custom dialog, but the advantage is that you only have to write it once for each database and you can re-use it whenever you need an error message.

Place the merge variable in prominent location in your layout (or in a popover) and give it a red color to draw attention to it. When the $$message variable is empty, it will be invisible. You don’t want a lingering reminder when you use it, just a timely message. So the only real task after you use it to send a message to the user is to empty it again.

This is done with two small scripts. In our examples below, the first is named “Set $$message.” This script is using MultiParam (as opposed to Get (Script Parameter) ). If the error message you want to send is “A value is required for Name,” your script parameter would be:

“message = A value is required for Name.”

Alternatively, you could set a variable ($error, for instance) with the content of your message. In this case, the script parameter would be:

“message = ” & $error

The “Set $$message” script beeps (to give audio and visual feedback), sets the $$message variable to the value of your error message, then uses the Install Timer Script to call the “Clear message” script after 8 seconds. It includes a Refresh Window step just to make sure the $$message is redrawn.

SetMessage


The second script is “Clear message,” which clears the $$message variable, refreshes the window, and calls the Install OnTimer Script step without providing a script or a timer value, which  clears the timer.

ClearMessage



Empty Fields in Relationships

Here’s an interesting problem that you might run into when trying to create a value list based on a relationship that uses multiple fields. This discussion uses a medical billing scenario as an example, but the important aspect is how value lists based on relationships work.

The Scenario—you want to show a value list of Billing Codes for a therapist to use during a visit with a client. Visits are designated as different Types, which determine which insurance company will pay for the visit. The therapist may be fulfilling one of several roles during the visit and may or may not be designated as a Team Lead for the particular visit. The Billing Codes you are going to present to the therapist to select from are dependent on the Visit Type, the Role and whether or not the therapist is acting as a Team Lead.

In the Visit layout, we’re providing a radio button set to select the role, and a checkbox set (using a value list of 1 and 0) for the Team Lead.

The tricky part is that some billing codes depend on the Type and Role, but a few of them need to be added to the Billing Code value list only when the therapist is acting as Team Lead.

The table for the Billing Codes is named client_visit_BILLINGCODES_vl.
The table for the Visit is named client_VISIT.

In the Manage Value List dialog box, we have chosen the “Use values from field” option and then made the sections as indicated in the graphic below.

 

This means that the Billing Code value list is entirely dependent upon the relationship between the two tables.

The relationship between the Visit and Billing Code is defined as:
Visit::Type = Billing Code::Type
AND Visit::Role = Billing Code::Role
AND Visit::Team Lead = Billing Code::Team Lead

In both the Visit and Billing Code tables, the Type and Role are text fields. Each Visit will be of a single type, which make matching those two fields very simple.

For the Role, the Billing Code may have multiple roles to which it applies. This is addressed by using the Role field as a value list, with the options entered in the same field with a return separating the different values. In the Visit layout, the Role is a radio button set, allowing the user to choose only one role. If the role selected is one of the items listed in the Billing Code table’s Role field, it qualifies as a match for the relationship.

The Team Lead is a number field, and this is where the potential matching problem lies. In the Billing Code table, we can set the Team Lead value for our special codes as 1 and mark all of the other codes as 0 (zero). So in the Billing Code table, we’re basically treating Team Lead as a boolean (the value is either 1 or 0).

The trick to this is how you set the Team Lead field for the Visit. If the Visit’s Team Lead field is empty, the value list will be empty as well because an empty field does not match the number 0 (zero). We want to show all the normal Billing Codes (those where Team Lead is 0) if the Visit and Role fields match, and still be included when the Visit’s Team Lead field is checked.

This means that the Visit’s Team Lead field cannot be treated as a Boolean. If we change the Visit’s Team Lead value to 1, then our Billing Code value list will contain those codes with Team Lead marked as 1 in the Billing Code table, but it will lose all the codes marked as 0.

The solution to this is to offer the Team Lead field in the Visit layout as a Checkbox Set with values of 1 and 0, but make the field small enough to only let the 1 option be visible. Give the field an Auto-Entry option that calculates its value to 0. Don’t use any sort of script to change the field’s value from 1 to 0 (like you might do to control a normal boolean use), just allow the user to click on the 1 checkbox. The 0 value for the field (which is hidden) will always remain checked.

So when the Team Lead field is checked on the Visit layout, its value will be 1 AND 0, and the Billing Code value list will add the Billing Codes where the Team Lead value is 1, while keeping those marked as 0. When it is unchecked, the 0 codes will still remain and the 1 codes will disappear.