[Some of the content in today’s article has been recycled from earlier articles.]
Demo file: virtual-list-with-window-uuids.zip (requires FM 26 or later)
Introduction
As the whole world — or the whole FileMaker world at any rate — knows by now, last week saw the release of FileMaker 2026 with a number of compelling new features, as well as improvements to existing features. And almost immediately an abundance of well-written, insightful articles appeared, blossoming like a field of springtime flowers to serve as trusty guides, including…
- Soliant: FileMaker 2026 Executive Summary
- DB Services: Claris FileMaker Pro 2026 Overview
- 1 More Thing: FileMaker 2026 is Here!
- Squaremoon: Claris FileMaker Pro 2026: The Complete Walk-Through
By contrast in this article we’re going to focus on one new feature, and its relevance to the phenomenon known as virtual list. To quote from the FM 26 release notes:
The Select Window, Close Window, Move/Resize Window, and Set Window Title script steps now support selecting a window by UUID, making it possible to uniquely identify a window even if multiple windows have the same name or if the window’s name has changed. You can use the new Get(WindowUUID) function to get the UUID of the currently active window.
The second sentence above points to where we’re going today, because we can leverage Get(WindowUUID) to create variables scoped to a particular window, independent of the window name. Up till now this has been a challenge with virtual list if we wanted to enable users to a) produce multiple on-screen reports, and b) interact with those reports in browse mode.
For background on the issues, and my most recent stab at an acceptable solution, see Virtual List Reporting, part 4. But that was written nearly five years ago, and something wonderful occurred in the meantime: the introduction of the revamped JSON engine last year in FileMaker 22.
I touched on its relevance to virtual list in FileMaker Pro 22: Initial Impressions, and then a few months later in Virtual List Even More Simplified (if you aren’t familiar with virtual list, or need a refresher, you may want to look at this article before proceeding).
To cut to the chase, in FM 22+ two-dimensional JSON arrays are now viable and performant as back-ends for virtual list.
And now with Get(WindowUUID) the other “missing piece” is finally in place. We can generate as many virtual list reports concurrently as we wish, interact with them on screen in browse mode, with no restrictions on window name or requirement that each name be unique. And performance is blazingly fast — not just to render, but in terms of scrolling, sorting, and the display of summary fields or the layout calc equivalent.
All of the above are based on a single virtual list table, with each window deriving its values from a dedicated JSON array in a variable scoped to that window’s unique internal ID.
Running The Demos
To generate reports, click “Customer Summary” or “State Summary”, and a popover will appear offering relevant options.
The Main Idea In A Nutshell
The Reporting Scripts…
- Create a new window
- Get the UUID for that window and generate a corresponding $$var
- Locate a found set in the sales table
- Parse that data into a 2D JSON array using the Fast Summary technique and populating a generic $json variable
- If necessary do some post-processing
- Push the contents of $json into the $$var generated in step 2
- Go to the proper report layout (based on the virtual_list table)
- Perform a find to display the correct set of records
Note: When you close the window, a script trigger will clear the corresponding $$var, but bear in mind that if you close the window in layout mode, the trigger will not fire. (This isn’t a big deal, just something to be aware of.)
More Info
Get(WindowUUID) returns a 32-character string uniquely scoped to a particular window, for example…
…which can be used to construct a corresponding global variable name by the simple expedient of prepending a pair of dollar signs and employing a bit of Evaluate/Let voodoo (which a custom function takes care of for us).
The custom function:
Under the hood:
And the engineers at Claris wisely decided to go with only numbers and letters for this particular UUID, ensuring there are no “forbidden character” problems if we use it in a variable name. Specifically we are dodging this bullet:
Not only that, but because a window UUID is 32-characters in length, we never have to worry about variable names based on the UUID exceeding the hundred-character variable name length limit.
At any rate, after step 6 that variable will contain a two-dimensional JSON array like so…
The Virtual List Table
The virtual list table has been pre-populated with 10K records, and we can add more if necessary, but 10K records are typically more than sufficient.
There is only one indexed field in this table: ID, which is a serial number. These ID numbers have a one-to-one correspondence with the records in the table, and there can be no gaps… since we have 10K records, the IDs are 1 through 10000, and the next serial value for ID is 10001. Here are the field definitions…
…and the one doing most of the heavy lifting is cell_num_r.
A few things to be aware of… 1. this is an unstored calculation, 2. it has 150 repetitions, and 3. the result type is number. And note that cell_text_r is identically defined, except the result type is text instead of number.
The basic idea behind having the field name begin with “cell” is that, as in a spreadsheet, a cell represents the intersection of a row and a column. In this case the row corresponds to the ID number of a particular record in the virtual list table… and each array column corresponds to a particular field repetition.
Regarding the one-to-one correspondence between virtual list records and array rows mentioned above, this means that array row [0] will always be available for miscellaneous use… in this case the window name, current sort field and current sort direction are stashed there. The former for informational purposes, but the other pair to assist in column sorting and the display of the red caret symbol used as a sort indicator (oriented normally when ascending, and inverted when descending).
If you’re curious about the “48” in the above calc, it’s telling the calculation to make an exception if we are on the virtual list table layout, and render results from $json instead of from the $$var scoped to the window. Why do this? So we can display that table in a separate window, step through the reporting scripts with the debugger and see intermediate results during report generation.
Major Benefits Of This Approach
To my way of thinking, the big benefits are…
- Simplicity — each report is based on a single dedicated variable
- Performance — you can crunch and render a lot of data very quickly
- Freedom — to name windows as you wish, and no more requirement that window names be unique (as was the case in Virtual List Reporting, part 4)
With regard to this last point, here is an example of multiple, identically-named windows, each showing a different sort order.
And here are the corresponding variables, with sort criteria visible in row [0].
This is so much easier to do in FM 26+ than it was in previous versions.
Closing Thoughts
Today’s article shows one application of scoping variables to the UUID of a particular window. It will be interesting to see what other uses people come up with.