Quick Checkbox Selection of Portal Records for Users

There are many ways in which users can select records, so that each user can keep their own unique selection. This particular method uses a portal showing related records as a selection tool. The main technique involves using a value list & checkbox to easily achieve selection with no scripting required.

Setting the scenario:

Quite often it is necessary in a solution to let users select one or more records for a certain purpose. Because this is a user-level process, each user should be allowed to have their own lists of records without interfering with other users selections - this is a perfect use of a global field! Global fields are user-specific, so one users global field contents will differ from that of another user.

So, how can we make use of a global field to select records? One of the most common techniques simply involves maintaining a list of selected record IDs in the global field, and this is the technique that we will be using in this article.

A little bit about checkboxes:

The easiest way to construct a checkbox in FileMaker is to simply make use of FileMakers existing features. Value lists have a visual display option to show as checkboxes. Typically when you see a checkbox value list it looks something like the following:

The first box shows a standard checkbox value list containing 3 values. The second box shows what is actually stored in the field when options are checked. When a value is checked, it is either added or removed from the field. The field itself is just a return-delimited list of checked values.

So, with that said, is there any way to maintain our return-delimited list of selected records using a checkbox?

"Single-Value" Value Lists

To further help understand the technique (which I will eventually explain!) it pays to demonstrate the following technique that you can use with value-lists that only contain a single value:

In the picture above, the value list now contains just the single value "Apple". You can see that everything still works as expected - unchecking the apple box will remove apple from the field just as it did previously.

So, if a value list contains only one value, is it really necessary to show the label "Apple" beside it? If it is only one value, then surely the user knows what the checkbox pertains to depending on where the checkbox is located on the layout?

With a little jiggery-pokery, the checkbox field can be reformatted to give the appearance of a lone checkbox with no label:

This is achieved by doing a few things:

• Reduce the width of the checkbox field so the label is hidden
• Increase the font size of the field to make the checkbox larger
• Remove field borders to remove the "double box" effect.

We now have a checkbox which when toggled, will select/deselect the word "Apple".

Applying this now to the portal:

So, we have shown how to build a single checkbox to toggle a value in a field. Applying this to our problem, it stands that to solve our issue we simply need to place this checkbox in our portal so it appears on every row. Toggling the checkbox in each portal row will need to toggle the selected portal rows record ID in our global field.

In order to do this, the value list is going to need to contain a single value - the portal rows record ID. Each portal row is going to require a different value attached to its checkbox - that being its record ID.

So, how do we produce different value lists for each portal row? You may think the answer would be to create many value lists - fortunately there is a MUCH easier and MUCH less time consuming way (note - creating many value lists will

Value lists have a context

This is key. The contents of a value list will change depending upon the context in which they are evaluated. Most value lists you see have a layout-level record context. This means that the values contained within the value list will change from record to record, depending on what record you are on. Other value lists may be contextless, such as ones that use custom values. For these, they will show the same values regardless of the record they are on.

A portal is a context, and as such you can have a value list evaluate within a portal on a row-by-row basis. This means in just the same way a value list can change its values on found-set records, they can also change on portal rows.

This property of defining a value lists context is achieved using the value list option Use Values from Field combined with the option to Include only related values starting from: - the latter of which provides the context for the value lists evaluation.

Because a related value is needed for this feature, we are going to require a new relationship to obtain the value lists values from. We only wish our value list to have 1 value which will be the records primary key value, so we need to create a self join relationship:

In the picture above you can see the layouts context Home, related to the portal of contacts we will be using. From the portal table occurrence, we have created a self-join relationship to a new Contacts table occurrence in blue. The relationship here is simply from primary key to primary key (Contact ID = Contact ID).

The image above shows how the value list that we will be using for the checkbox is setup. Note that the value list is set to show each portal rows Primary key Contact ID through the self-join relationship. The Starting context of the value list is the portals table occurrence. This means the value list contents will be evaluated at the portal level, giving unique value list contents on each row.

The picture above shows the result of putting our global field in the portal, and attaching our value list to it. I have expanded the width of the field so you can see the actual value of each value list. You can see that on each portal row, the contents of the value list changes to reflect that rows Contact ID.

The end result:

Putting it all together we end up with a nice checkbox on each portal row, which when checked will toggle that contacts record ID in our global field.

Final Thoughts:

The thing I like about this method is that it is quick, requires no scripting, and makes use of FileMakers existing checkbox as a selection tool.

While there are many other great methods out there for record selection in portals, hopefully this has given you yet another tool for this process. It really is a case of using the right technique for the right situation. This checkbox technique works best when the number of records in your portal is relatively small, otherwise visualising the selected records becomes more difficult. You could combine this technique with some conditional formatting in each portal row to achieve a better indication of the selected records, but generally if you were to go that far then other techniques that involve scripted maintenance of your list of IDs is probably more suitable :-)

Example File:

Please find attached an example file. This file was used for all the screenshots in this article, and is provided to help you fully understand what is going on in this article, and to let you experiment in FileMaker with this solution.

Download Example File