As wonderful as Filemaker is, I’ve never really liked the way drop-down lists work, especially the fact that, using a non-enterable display field on top of the enterable ID field, it’s difficult to prevent the user typing into the ID field. At best this is confusing, and at worst it allows invalid ID data.
So this is the rather labour-intensive way that I use drop-downs, to make them a) more elegant, and b) less prone to allowing the user to enter invalid data in the key field.
Here’s a drop-down from the “Focus” system, as it appears in Browse mode:
The Component Parts
The layout “item” is actually made up of 3 objects, as shown below (in Layout mode):
The first field, INT_g_kf_PTI_ID, is the global field for data entry. Note that, in reality, the text colour is WHITE – I’ve shown it as red only for illustrative purposes. This field is defined as:
- Drop-down list
- Using values from a value list (see below)
- Do NOT “include arrow to show and hide list”
- Do NOT “select entire contents on entry”
The Value List behind this field is defined as:
i.e. using the key field and corresponding text field (“Programme Title” in this case), but only displaying the text field.
So, when the user selects a Programme Title from the list, the key field of the selected item is stored in INT_g_kf_PTI_ID, but formatted as white, so it’s effectively invisible. What the user does see is the related PTI_Title field (in this case from the TO, “INT to PTI”), which is formatted as grey (or any other non-white colour), and placed on top of the underlying data entry key field. This second field is defined as allowing no field entry, in Browse or Find modes. It is the same height as the key field (17 px), and 16 px narrower.
The 3rd component is the little arrowhead icon, which is really only there for decorative effect, and to give the user a visual clue that there is a drop-down involved. It is 15 x 15 px, and fits very neatly to the right of the display field.
Another visual nicety is the conditional formatting of the display field. This particular field is a required field, so if the key field is empty, the display field is highlighted in red, like this:
So why don’t we display the arrowhead?
The nice thing about NOT including Filemaker’s own arrowhead on the drop-down is that the user doesn’t have to click on it to activate the drop-down – with the Filemaker arrowhead hidden, when the user clicks anywhere on the field, the value list is displayed. Apart from making the list easier to use, this greatly reduces the opportunities for the user to start typing in the key field. OK, it’s a minor pain having to add your own arrowhead, but it’s worth it.
Validation of user input
Although we’ve made it harder for the user to put invalid data in the key field by hiding the arrow head, thereby making the whole field a “hotspot” for the value list, the fact that we have to allow field entry means that, if the user clicks twice on the key field, that will enable them to type directly into the key field – the first mouse click anywhere on the field activates the value list, the second positions the cursor in the field itself, and there seems to be no way to prvent this. So we need a validation routine, i.e. a triggered script, run “OnObjectModify” of the key field (whether by keyboard action, or slection of an item from the VL).
The script basically checks that the contents of the key field is a valid key. It looks like this:
The script uses the excellent “FilterList” custom function (by Agnès Barouh, available from Brian Dunning’s site) to check whether the item selected or entered by the user is one of the items in the VL. If not, it asks the user to try again.