Quick Checkbox Selection of Portal Records for Users

By Daniel Wood, 19 January 2011

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.

portalrecordselect 1

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:

portalrecordselect 2

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:

portalrecordselect 3

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:

portalrecordselect 4

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:

portalrecordselect 5

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).

portalrecordselect 6

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.

portalrecordselect 7

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.

portalrecordselect 8

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

 

Something to say? Post a comment...

Comments

  • roulette play money 20/07/2017 1:50pm (3 years ago)

    Hi there, You've done a fantastic job. I will certainly digg it and
    for my part suggest to my friends. I'm sure they'll be benefited from this site.

  • Kristy Lapidus 20/09/2015 7:20am (5 years ago)

    Elegant and so fast to implement. Thanks!

  • Bilal 05/02/2013 11:51am (7 years ago)

    Hi Daniel, it works well but as soon as i convert it into file maker 12 pro advanced file i.e. .fp12 its checkboxes don't behave.

  • Daniel Wood 09/01/2012 9:01am (9 years ago)

    Hi Fastserv, you could show the selected contacts in another portal by establishing a relationship between the field that contains the return delimited list of contact IDs, and the contact ID field on the contacts table, cheers.

  • fastserv 08/01/2012 5:39am (9 years ago)

    hi,
    I really like this method. Is there a way to show the selected contact ids in a portal?

  • fastserv 08/01/2012 2:17am (9 years ago)

    hi,
    I really like this method. Is there a way to show the selected contact ids in a portal?

  • Daniel Wood 23/08/2011 8:20pm (9 years ago)

    Hi Joshua, you are right, it seems to act very weird in FM Go which is strange! From what I can see the value list in each portal row contains the record ID of the first portal row, rather than just the record ID of that row. What is even weird is that when you toggle these checkboxes on various rows, the actual underlying field changes but in a very odd way. I would think that if visually the value list in each row contains 5, then toggling any row would add or remove 5 from the field, but this is not the case. It's very strange.

    I don't think the issue here is straight up related value lists, as we have used these before in FM GO with no issue. I think the issue here related value lists whose starting context is that of a table occurrence that is the basis of a portal on the layout. More testing might be needed to figure out the exact scenario but that is what it is looking like to me.

    Thank you for finding this and raise it in the article, I'm sure this will prove useful for future readers, especially if they are hoping to use this on FM Go.

  • Joshua Morton 23/08/2011 7:22pm (9 years ago)

    It doesn't seem to work with FMGo - no mention of related value lists not working it Go but that seems to be the case??

  • Kevin James 08/07/2011 6:23pm (9 years ago)

    Thanks, Daniel. I have it now. You were exactly right. I was thinking the field had to be set to the value list. Not so, of course - only the field in the portal is associated with the Value List. Thanks again.

  • Daniel Wood 08/07/2011 5:34pm (9 years ago)

    Hi Kevin. It sounds to me like your gChosenItem field has validation on it, and has been specified to only contain vlaues from the value list. If this is the case, then you will see this message when you try to check any of the values in the portal. Simple solution - remove the validation :-)

    Cheers

  • Kevin James 08/07/2011 5:30pm (9 years ago)

    Hey, Daniel,

    I was playing with this method and it works except that I get a gChosenItem is defined to contain only specific values. I understand why I'm getting the message, but 1) don't see how to defeat it, 2) don't see how you are not getting the same message.

    Thorough description - thanks for the post.

    - Kevin

  • Matt Petrowsky 19/01/2011 12:55pm (9 years ago)

    Nice explanation Daniel.

    Here's some code that make may the process even simpler.

    Just attach a Set Field directly to your field in the
    portal. No value list needed, no checkbox field, no extra
    relationship, just direct interaction with the global key
    field.

    Hopefully, the calc code will translate through the comment posting...


    Let ( [
    ~globalField = Home to Contacts for Portal::Selected Contact IDs;
    ~rowValue = GetNthRecord ( Home to Contacts for Portal::Contact ID ; Get ( ActivePortalRowNumber ) )
    ];
    If ( IsEmpty ( FilterValues ( ~globalField ; ~rowValue ) ); // it doesn't exist

    List ( ~globalField; ~rowValue ); // add it, otherwise...

    Substitute( "¶¶" & ~globalField & "¶¶"; // remove it
    [ ¶ & ~rowValue & ¶ ; ¶ ];
    ["¶¶¶"; ""];
    ["¶¶"; ""]
    )
    )
    )


    P.S. Extra cool UI using conditional formatting on the field
    itself to show whether it's included or not. Just use the
    IsEmpty(FilterValues()) test to highlight included rows.

    Matt Petrowsky
    Editor of ISO FileMaker Magazine

RSS feed for comments on this page | RSS feed for all comments