Category Archives: FileMaker

Give Users Feedback with Merge Variables

Tags :

Category : FileMaker , Scripts , User Experience

Much of what happens behind the scenes of your scripts is, and should be, invisible to your users. But there are times when you need to give feedback about what’s happening. If a script can’t process an invoice, or is finished marking a found set of records, it’s common to use a Show Custom Dialog script step to tell users what they need to know. But there’s a problem with this step—users have to stop what they’re doing and click OK to make the dialog box go away. That violates at least one rules for creating good user experience: Don’t interrupt your users.

Fortunately FileMaker gives you other ways to give users dynamic information without using a pesky dialog box. You can set your message into a merge variable with an install timer script set, and then clear it back out again with a second one. This process is so useful that we include a pair of scripts for this purpose in every database we design.

Here are the steps you can use to set a message:

 

It’s a good idea to give users audio AND visual feedback, so the script starts with a beep step to get their attention. Then it parses out a message that you send to the script as a parameter. If you’re using the method described in the link above, your message needs a name and value pair, separated by an equals sign. Use this syntax:

message = Email Sent

And to make sure users don’t have to hunt all over their interface to read the message, put the merge variable in the same spot on every layout. This should be such a integrated part of your design routine that that you plan for it from the beginning of a project. Figure out where to put the merge variable, and then format it with whatever red color you’ve chosen for the solution to give another type of feedback that says: This message is important.

So this short little script makes a noise, shows a brief message, and then does its own housekeeping so the user doesn’t have to do anything to make the message go away again.

Here’s the script you can use to clean up afterwards:

 

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

Tags :

Category : Design , Development , FileMaker , User Experience

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

Tags :

Category : FileMaker , Relationships , Value Lists

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.

« Previous Page

Archives

© 2019 DBHQ, LLC