In the past, when selecting items from a list in order to do, say, a mail merge or some other sort of bulk processing, I’ve used a clunky combination of “select” indicators on each record, followed by a Find finding all recs with the selection indicator set), then a loop through the found set.
Having realised the error of my ways, I now use the technique described in “Selecting Items from a List“, which basically puts the primary key of each selected item in a global variable (say “$$SelectedPeople”), using a neat custom function to toggle between selection and de-selection.
Once the global variable is set, getting the records for bulk processing is embarrassingly simple – just bung the contents of the variable into a global “match” field on the table you’re interested in, and do a Go To Related Record.
Within the GTRR script step, having checked that there are people selected, you can specify:
- the layout to be used (in this case a letter template for mailmerging),
- whether to use a new window,
- which records to show – in this case, of course, only related records.
And that’s it. One script step to replace a clumsy sequence.
Given a list (not a portal), users may need to select certain records for later processing (mail merge, print list, etc.). Using an indicator field on each record is not an option in a multi-user system – User B may unset the flag set by User A – so the solution is to use a global variable to hold the keys of selected variables. The global variable is session-specific, so there’s no danger of users getting in each other’s way.
- The global variable to hold the list of selected people – $$SelectedPeople
- The key of the record that user has selected – say PPL::PPL__kp_ID.
- The custom function that maintains the list in the variable – AddOrRemoveSelectedItem (list,value). (It needs to detect whether user has already selected the item. If so, it must be removed from the list. If not, it needs to be added to the list.)
- A script to run when the user clicks on the select button – Select a Person.
The Custom Function
The CF looks like this:
The first bit creates a variable, “newList”, that will be used if the value is already in the list, i.e. in the “If” statement. (The leading and trailing “¶” are there to ensure that the PatternCounts do actually find “PPL1981” and not “PPL198”.)
The If statement itself reads:
“If the value is already in the list, take the new list (i.e. the existing list, with a leading and trailing “¶”, but minus the value selected) and remove the leading and trailing “¶”. If the value is NOT already in the list, add it to the end, with a “¶” before it. If the list is empty (i.e. this is the first item selected), don’t add the “¶”.”
The script is really just a one-liner to set the variable, with a freeze and refresh of the window:
(The parameter (GSP(1)) is the key field of PPL. )
To show the user which item(s) s/he has selected, apply conditional formatting to the list. Use the same checking as in the CF, i.e.:
PatternCount( ¶ & $$SelectedPeople & ¶; ¶ & PPL::PPL__kp_ID & ¶)
i.e. if the item exists in the list, apply the highlight (or whatever formatting is suitable).
Selecting ALL Records
If user wants to select everyone in the found set, the process is very straightforward. Here’s the script that runs if user opts to “Select All”:
We go to Form View (important, because in List View the whole thing is VERY slow), then loop through all records, adding each one to a script variable. After that, plonk the list into the global variable. (Using a script variable for the loop seems to make the whole thing faster.)