Universal Record Marking
Who doesn't need to mark subsets of records? I've rarely, if ever, worked on a solution which couldn't take advantage of simple record marking. Whether it's for creating a user based subset or simply toggling an active or favorite value.
Marking records is something which should just be standard. So, why not make it both standard and universal. Meaning, you use one single script regardless of whether you're dealing with a current found set of records or a filtered portal - and independent of a specific field.
That's what this video and technique file are all about. Universally marking records within your solution. A small collection of scripts for targeting any given Boolean field and making it so simple and easy that you don't even need to think about it. You just call the one universal utility script and call it a day. Your records are marked - or unmarked.
Looking for a smaller, and easier, FileMaker solution to manage? Then start using utility scripts and make this marking solution one of your go-to recipes.
Comments
Multi-User Selections
Hey Matt. Great tips! Two comments:
1) When I hide portals on the layout that need identical filter settings like this, I now add a BIG comment at the top that says that any changes to the filter will also need to be updated in the other portal as a reminder. I drove myself crazy one day trying to troubleshoot a script that wasn't working, only to find out that I had failed to mirror the filter settings in both portals! Your suggestion to use custom functions is brilliant, and maybe I'll start doing that instead!
2) How would you update this technique to work in a multi-user, hosted file that avoids collisions? Usually, individual users want to "mark" their own subset of records to perform some action, but this method selects the same records for all users (thus the need to check for record locking), which may lead to undesired/confusing behavior. I've figured out a way to do it using a global field and some calcs that works well enough, but I'm sure you would come up with a more sleek, streamlined method compared to me.
Thanks!
You will never completely avoid collisions
The ListOf summary field allows you to quickly grab the primary key values across the current found set, or you can use the List() function in a calculation if you want to grab the set of records through a relationship, or you can use Matt's technique described in this video to grab the values across a filtered portal (PRO TIP: define your filter as a custom function, and use that in your portals; you will only have to change the calculation in one place).
Once you want to work with the values, it's best to transfer them to a global VARIABLE and not a global FIELD. You'll still use the global field if, for example, you want to run a Go to Related Records step to isolate the records in the destination layout, but having the list of values in the global variable not only brings a performance boost but also allows you to make your scripts less context-dependent so you can copy and paste between files with less effort.
Once you have a found set of records to work with, you can loop through them and perform the required action on each record - based on your preference you can either update the existing global variable or set new variables, one with the IDs of the records where the action completed successfully and another variable to store the list of IDs for the records where an error occurred (not just record-locking conflicts, any error is worth tracking). You can then decide how your system will handle those errors, such as logging them to another table for later re-processing.
--
Daniel Farnan
Ignorance is curable, not preventable