Monthly Archives: March 2015

  • -

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.


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.


  • -

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.