"No Holding Back FileMaker Blogging"
|
Navigation:
|
Support this site by clicking on a sponsor below or becoming a patron!
Fireside FileMaker Podcast
Become a patron of this FREE web site!
|
|
Recent Blogs:
|
Currency Formatting
 |
Gathering Portals
 |
Multiple Choice Picker
 |
Popups and Pickers
 |
Window Locking
 |
|
Meta-Consulting
Meta-consulting is a service Database Pros offers to help other developers
over programming hurdles via GoToMeeting. Email John Mark Osborne or call John Mark at (909) 393-4664 to find out more about this service.
|
Create a Password Management solution!
|
Quick Tip:
|
Search for Empty
Searching for records with an empty field works most of the time using a single equal sign (=). It can fail if a user has fat fingered a field by entering a space, a return or some other invisible character. While the field contains valid characters, the field is technically empty. In order to avoid this problem, search with two equal signs (==). |
|
|
The Philosophy of FileMaker recommends PCI!
|
Fun Stuff:
|
FileMaker, Inc.
FileMaker, Inc. or FMI is a wholly owned subsidiary of Apple, Inc. It was once named Claris when it also sold MacWrite, MacPaint, Claris Emailer, ClarisWorks, etc. but changed it's name in 1998 when it focused on FileMaker. FileMaker started out as a DOS application called Nutshell but was shaped into the powerhouse it is today by Claris and FMI. |
|
|
FileMaker 20 Video Tutorials
|
RSS Feed
|
|
|
|
Popups and Pickers
|
Level: Intermediate
Version: FileMaker 20
Category: General
Wednesday, May 1, 2024 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Consistent data entry is one of the hallmarks of a well-designed FileMaker database. It allows a user to run accurate reports and perform reliable sorts and finds, just to name a few important features. Popups and Pickers can assist in the integrity of your data, allowing you to control how users enter data. Without pop-up and pickers, found sets and reports might return inaccurate results. This article will discuss the ins and outs of popups and pickers, including interface techniques, feature differences and best use cases.
Examples
The best way to demonstrate poor data entry is by showing you a screen shot of the index from a database that was created by an amateur. While this is a recreation of that real-life example of a client name field designating an invoice recipient, you'll get the idea. The first screen shot shows the value index, which would be used in a report or a sort. The second screen shot is the word index of the same field, demonstrating what a find on a text field would see.
 
When sorting or reporting, those five different values will show up in different areas of the sort or report. When finding, a user may or may not get accurate results, depending on what they enter as their find criteria.
Free-Form
Not all fields should be structured with a pop-up, popover or picker. In fact, most fields should be free-form, allowing users to enter data how they see fit. Common examples include name fields, address fields, city fields and anything that typically exists in the contact manager portion of your complete database solution. But this type of flexible data entry goes for any name field identifying a record in any table. Pop-ups and pickers are for scenarios where you know the data will be repeated and you need consistent data entry.
Pop-up Decisions
There are many types of field formatting that can display a value list for consistent data entry including pop-up menus, drop-down lists, checkbox sets and radio button sets. I don't include drop-down calendars or "auto-complete using value list" for very different reasons. Date fields have automatic data validation such that only a properly constructed date can be entered so drop-down calendars are simply for ease of data entry. "Auto-complete using value list" acts a lot like a pop-up or drop-down but doesn't force consistent data entry or give users a defined set of values to enter.
Pop-ups vs Drop-Downs
I've gone back and forth throughout my FileMaker career favoring pop-ups for years and then drop-downs and then back again. Pop-ups force data entry unlike drop-downs. You can delete the contents of a pop-up but that's it. With a second click, drop-downs allows you to enter a field and start typing whatever you want unless you have validation. It's pretty simple to validate a drop-down to the attached value list. Just enter Manage Database, double-click on a field and select the Validation tab.
Realize there are differences across platforms for each of the data entry formatting types. This is mostly the case with pop-ups and drop-downs and definitely vary from MacOS to Windows to iOS. Most cross-platform differences are subtle but I remember one client clearly favoring drop-down lists on the Macintosh and Windows and pop-up menus on iOS. My point is, don't just assume they work exactly the same in every regard on different platforms. The OS often plays a part in how they function. The example file included with this article includes the variety of different drop-down and pop-ups for your testing.
Currently my favorite implementation is a drop-down list allowing data entry with a pop-up menu covering it without allowing data entry in browse or find mode. When you click on the pop-up menu, FileMaker selects the drop-down below, turning the pop-up into simple interface. With validation for "member of value list", I can take advantage of the features in a drop-down with the look and feel of a pop-up. I just like the way the pop-up attracts your attention with it's look and feel. Sure, you can turn on the option to "include arrow to show hide results" on a drop-down but this actually makes it easier for users to get into data entry mode with a single click.
There are many FileMaker related differences between drop-down lists and pop-up menus. As we learned above, they look different. They also display their value lists in unique ways. A drop-down list displays a limited number of values depending on the resolution of the current monitor. The larger the resolution, the more values that will appear. I found a maximum of 20 values appearing on my monitor set at 3,840 x 2,160. If your FileMaker window is at the bottom of the screen, values may go up rather than down. I noticed these differences when testing on my Macintosh but you may get different results on Windows or iOS since the OS plays a part in how they work.
On the other hand, a pop-up will display as many items as fit on the screen with an arrow pointing down indicating you can scroll. A drop-down list doesn't display the visual queue but still let's you scroll down for items not shown in the list. In previous years, pop-up menus on Windows didn't allow for type-ahead but that's not true anymore. In fact, you can even make a pop-up menu display values from a keyboard since simply tabbing to a pop-up menu doesn't show the value list. Just tab to a pop-up menu and type the space bar to display values for a mouse-free interface. But, for many users, this extra keyboard requirement is either beyond their knowledge or a pain in the butt. Hence, why I like drop-down lists but with the pop-up menu covering the drop-down for interface.
Checkboxes and Radio Buttons
Users often confuse these two types of value list formatting but they couldn't be more different. Checkboxes store multiple values while radio buttons are designed to make a single selection. While it is possible to make make multiple selections in a radio buttons using the shift key, it typically stores a single value from the attached value list. If multiple selections are made, both checkboxes and radio buttons store the values in a return-separated list in the order the values were clicked. If you want to see for yourself how the values are stored, just place a second copy of the field on the layout without attaching a value list. For example, multiple client choices would be stored in the manner shown below (the pilcrow or ¶ character is invisible but shown below for teaching purposes):
Apple, Inc.¶
Microsoft¶
Claris Incorprated
Notice there are returns between each value but not after the last choice. Return-separated lists allow for multi-key relationships, making them a great choice for portal filters and other interface techniques. Typically, the entire value in a key field is used as a single match unless a return is included. Each value (separated by a return) is seen as a unique match in a multi-key relationship, effectively creating an OR relationship. In the above example, the checkbox of clients would match any related record with Apple or Microsoft or Claris.
The downside of checkboxes is they don't allow for ad hoc reporting. FileMaker subsummary reporting allows you to easily organize records by a key field. Since multiple values are stored in a single field, FileMaker subsummary reporting cannot organize a single records to different areas of the report even though they have multiple clients listed. In this case, you are better off using a related table and a portal for data entry if you plan on creating a report with the information.
Key Values
One of the most common pieces of feedback I get from clients is what the heck is that number in my field. What they are talking about is the primary key value that gets entered into a foreign key when making a selection from a pop-up or drop-down. Sure, you can hide the key value by only showing the second value but it still gets placed into a field to complete the relationship. Unfortunately, there's no simple way to hide that value from scrutiny. With a combination of scripts and layout tricks, it is possible to remove the key field from the layout but now the simplicity of a pop-up or drop-down has been lost.
The Picker Layout
If you are really set on hiding the key field from a user, a picker is the way to go. Pickers also offer multiple other benefits at the price of significant programming. For me, the true reason to employ a picker is because the choices in a pop-up or drop-down are in the thousands, making type-ahead cumbersome. Pickers also allow you to show more than two fields, filter on multiple fields and of course hide the key field.
My preferred implementation for a picker is in a card window but a picker can be implemented in a variety of different environments, even a popover. For this article, I'm just going to show you my preferred method. Let's start with the card window showing records from the table from which the selections will be made, in this case CLIENTS. Just make a layout, usually much smaller than the minimum size of the layout where the picker will display so it can display on top. Make sure the layout is in list view using the View As option in the toolbar and resize the body part to just larger than the fields it will contain. You can place as many or as few fields as you want in the body part. Just remember, the reason you decided to choose a picker over a pop-up or drop-down is to go beyond the limitations of these basic interface options. Therefore, you probably want a bunch of fields to help your users select the correct client. For my example, there will be just two fields, client and city, to keep the example simple to enhance the learning experience.
The fields on the layout should not allow entry in browse or find mode. Include a button to close the window. Do this before you try to write the picker script or you'll be sorry. No developer wants to be stuck in a card window with no way to exit except to force quite and possibly damage the file. Place a nice title like "Client Picker" in the header part.
Close Window [Current Window]
Finally, add an invisible button that fills the entire button. This is my preference so it's easy to select a choice without hunting for a tiny button. We'll cover the script later but for now, remove all Appearance options in the Inspector including Fill, Line and Effects so the button doesn't show in browse mode. Make sure you check the other button states other than "Normal" such as "Hover", "Pressed" and "In Focus" or the button may appear in one of these states, providing a less than professional appearance. Believe me, I've forgotten more than once in my career.
The best way to make the button the same size as the body part is to check the height of the body part via the Position in the Inspector. Then, click off all objects so nothing is selected and the Inspector will show you the width of the layout. Apply these measurements to the button and then center the button on the body part using the Dynamic Guides. Send the button to the back of the layout so it doesn't get in your way when trying to edit the fields and then lock it so you don't accidentally move it.
The Picker Display Script
Displaying the picker is a simple process of showing the layout you just created and showing all records.
New Window [Style: Card; Using layout: "Card Window Picker"; Height 500; Top: 0]
Show All Records
Go to Record/Request/Page [First]
This script will display a card window at the top of the screen because of the "0" in the top option of the New Window script step. Since it's a list view layout, you'll also need to specify how tall you want the card window which I've selected 500 points. I also like to dim the window but remove the close button so I can control the interface. In other words, it's just a one line script to close the window. And, if you need to, you can always add on additional script steps for specialized scenarios.
FYI: To create a small button with just an icon that fits nicely next to a field (like is shown in the example file), you'll need to use the Inspector to remove all padding in the Appearance tab. Otherwise, your icon will get cropped.
The Picker Selection Script
Making a selection is fairly easy. You just need to set the primary key from clients into a local variable, close the window and use the Set Field step to place the variable value into the foreign key for clients.
Set Variable [$ID; Value: CLIENTS::_kp_clients_id]
Close Window [Current Window]
Set Field [MYTABLE::_kf_clients_id; $ID]
A variable is required to pass the information from the picker window to the foreign key on the main layout since the two windows are based on different table occurrences.
The Picker Filter
Users don't really want to scroll through a long list of clients. Even if you sort the list, it's going to be cumbersome without a type-ahead like feature you see in a pop-up or drop-down. The best solution is to add a global field that enters find criteria to filter the list.
The script is fairly straightforward, simply entering find mode, placing the global value in into the correct field(s) and performing the find. If the global field is empty, meaning nothing was transferred to find mode, a 400 error will occur and all records are shown. At the end of the script, the global field is re-selected since the script above runs on a script trigger upon modification off the global field. That means each time you type a letter, the find is performed. Once the script enters find mode, the cursor is removed from the global field and needs to be reestablished. The find happens so quickly, the user won't know after each character a find is being performed, except for the fact that the found set will change as they type.
The script finds on two fields, Client Name and City, but with a single filter global field by employing the New Record/Request script step.
Picker Enhancements
A simple enhancement to the picker scripts is to add a Go to Field step to the end of the display script so the user can start typing right when the picker displays.
Go to Field [CLIENTS::xfilter]
Another nice feature for the user is a clear button to reset the filter global field to blank. Of course, the user can simple delete all the text but it's the little things that make your programming elegant and it's really easy to do.
Set Field [CLIENTS::xfilter; ""]
The only problem is Set Field won't trigger the script trigger on the xfilter field, so you'll need to run the find script again.
Set Field [CLIENTS::xfilter; ""]
Perform Script [Specified From list; "Picker [Filter]"; Parameter: ]
The last enhancement you might consider is making the picker scripts dynamic or adaptive so they work across all tables. Indirection may seem like a tantalizing idea but doesn't always make sense. Let's analyze this solution and see if it makes sense to make it dynamic or maybe even partially dynamic.
Let's start with the picker display script. Of the four steps, two are already adaptive which are Show All Records and Go to Record. These steps work in any layout regardless of the attached table occurrence. The New Window step can be made adaptive by passing a parameter with the layout name and using the option "Layout name by calculation". The Go to Field can be replaced with a Go to Object step so you can use a different global field but since global fields don't require a relationship to be accessed across the entire solution, this is likely unnecessary. Only if you start to employ multiple global filter fields might you need to switch to Go to Object. But, this will further complicate the script by adding a second value to the parameter you are passing and, of course, making the script harder to read.
The picker select script has three steps of which one is already dynamic. Set Variable can be adaptive by passing a parameter from the button to the script and then using the GetField function to grab the value. Two values are being passed, as you will see, so GetValue grabs the first of the return-separated values in the parameter.
GetField(GetValue(Get(ScriptParameter); 1))
The script parameter passed from the invisible selection button would be something like "CLIENTS::_kf_clients_id" in our example.
The Set Field step in the picker selection script would need to be changed to Set Field by Name. The value from the variable in the previous step would be the calculated result. The target field would be specified by the following formula.
GetValue(Get(ScriptParameter); 2)
Hopefully you are starting to understand how complicated this script is starting to get and I haven't even gotten to the filter script which is the most complicated given the possibility for different types of finds consisting of a variety of global filter fields and new requests. Yes, it can be done but is it worth it? When programming dynamic scripts, it's important to weigh the advantages and disadvantages. For instance, do you have more than one picker? Maybe you only have two pickers? Is it really worth all the programming? What if you change the layout name and break the script? With a simple non-dynamic script, FileMaker automatically updates all references of layouts, thus avoiding hard coding issues as we see with the passing of parameters.
Some developers will say to copy and paste the finished code to a new project but that isn't always that easy with all the pieces of the puzzle including buttons, parameters, layouts and more. Sometimes it's easier to just copy a script and make a few changes. If you have the need for more than one picker then you'll just have to duplicate the script and modify it. This simple approach certainly will make it easier to read or debug the script at a later time. It's a tough call whether to go dynamic or not but I usually err on the side of simplicity.
The Final Word
The rest of the scripts have have been dynamically programmed in the example file so you can see how it can be done. Personally, I rarely use indirection except where it really benefits me. You need to make that call yourself since there's no right answer. Program the way that makes the most sense to your style but my suggestion is to always keep it simple
Author:
John Mark Osborne
jmo@filemakerpros.com
www.databasepros.com
Example File (available to patrons at $5.00 per month): Download here if you are a patron
This blog is completely free. Please support it by clicking on one of the advertisers at the left side of the window or becoming a patron. Thanks so much!
|
|
