Missing feature - 'Go to Layout' and 'New Window' steps with 'open with empty found set' switch

I was tasked to create a CRM including some ERP functionality for a customer. FileMaker got selected because we had to whip up a version 1.0 in a very short time. That's definitely where FileMaker excels.

Some issues I encountered in past projects also made their reappearance.

This is my number one feature wish because not having it impacts the user experience:

'Go to Layout' and 'New Window' steps with 'open with empty found set' switch.

Use case:
Changing the layout in a window or opening a new window always starts with a found set equal to 'show all records'.
For tables with many records and/or layouts with a deep TOG, this can lead to longer load times.

  • not an issue when in LAN or WAN
  • not an issue when connected through VPN here in the country (only 1-2 secs of delay)
  • big issue when connected through VPN while travelling abroad (10-15 secs of delay)

Besides, when loading a full 'all records' at opening a layout, this found set most times is not what is required. Bandwidth and time for this initial loading could be saved.

Known workarounds:
a. narrow tables -> the concerned solution has narrow tables
b. switch to find mode before changing layout

Workaround b is less than ideal, because the switch happens either in the wrong layout or the wrong window in case of a 'new window' step. The script gets cluttered with switching forth and back lines.

A clean and straightforward solution would be adding an 'open with empty found set' switch to the above mentioned script steps.

Having no insight into the FileMaker code base, I can only guess if this is technically feasible. My guess is yes, because FM already knows how to handle an empty found set.


I would even add the ability to select the mode (browse, find or preview).


I would also add the ability to perform a find request.

In the end, what I am looking for is the ability to display a new window with the desired found set in the desired window mode.

If I want to go nuts, I would allow a script to run on the new window… before the window is even displayed. Right now, I have to jump through hoops to create an off-world window, do stuff, then bring the off-world window in-world, in the correct location and in the correct size. A pain!

1 Like

agree with all the above

One way to combat for now (which is not ideal compared to actually having these as options) is to create a blank table (0 records) and a layout based on it. use this to navigate to when you want to go to a 0 found set first. Then, before you actually go to the layout you want, enter find mode.

This gets you started in find mode on the layout such that you can search for a found set you actually want to display.

Historically we have always gone to find mode before going to a layout any time we want to do a find. The exceptions were always if having to open a new window. Now being able to specify layout on new window at least affords the opportunity to go to the blank layout first.


Interesting workarounds @weetbicks.

@Torsten's suggestion is so straightforward (and @bdbd's tweak ) that I'm surprised that Claris have not put it into the toolkit of their own accord already.

I've wanted this option many, many times.

1 Like

Does using GTRR with an invalid relationship or a relationship which matches zero records solve the problem?

No. Because you will not move to the other layout unless records exist on there other side of the relationship.

1 Like

How about GTRR which matches one record, followed by Omit records script step? I would expect that to have fairly good performance…

In case people don't know what I'm talking about, GTRR is the "Go To Related Record" script step, which has options to create a new window and choose a specific layout, as shown here:

This is true (and seems like a source of confusion/possible bug to me, but that's another topic).

I also noticed this in the documentation;

  • If this script step is performed in the context of a filtered portal’s row and the Show only related records option is set, only the filtered records are in the new found set. However, if the focus is not in the filtered portal's row, the new found set can include all the related records, not just the filtered records.

I suppose another technique would be to have a Filtered Portal on the Source layout, perhaps offscreen, with a filter so that only 1 record is shown, and then use GTRR through that portal. This would avoid you needing to make a new TO and relationship, though at the cost of requiring a ghost portal...

source: Go to Related Record

The issue with this is that it would tend to be non-performant. Unless certain conditions are met, the entire related record set is downloaded prior to filtering. In certain cases, the filtering can be done on the server side, so this might be done, however, it's hard to maintain.

Going to a blank layout, performing the find, then if a record set is found, moving to a user friendly layout, is my preferred behaviour.

I second @Malcolm's assessment. Using GTTR can have a performance impact:

Search the soup for 'GTTR' for more information.

@Torsten : That's quite a thread regarding GTRR (it spans over 2 years, from FM15 to FM19) and sounds like there may be some performance regressions, though in many of the tests it seems that GTRR still beats a scripted Find.

@Torsten, as the guilty party who started that thread, it is only fair to follow it up. First though, your wish, maybe an alternative new feature 'open new window in find mode' without needing to enter find mode first, which would allow all sorts of options I do agree with you, it would be useful (but not as useful as an 'OnRecordExit' script trigger - here I go again😂).

Regarding GTRR (not sure what GTTR is, 'Go To The Restaurant', 'Go To the Restroom'?), we remain developers who now try to avoid adding additional TOs and portals as much as possible. New/card windows, list views and SQL are our main TO avoidance tools. We still use GTRR, particularly when trying to go to related records for the current found set for reports. Our focus is on keeping the system as quick as possible for the data processors, who are often customer facing, and sacrificing the speed that scripted reports are produced (most people expect reports to take a bit of time).

GTRR performance does seem to have improved a little since I started that thread, it was so dire in v16 that we had constant performance complaints after upgrading systems from v15. And we usually try to use a find in preference to it.

Back to your original wish. We use blank layouts a lot (a $$DEBUG variable allows us to view the data in a working layout if needed). Have you compared performance opening a blank layout, show all records, show omitted only, or carrying out a find in the blank layout, and then navigate to your destination layout containing objects within the same context as the blank version?

1 Like

I did not measure the difference. However, all this fiddling with layout and view mode toggle is workarounds. After all, FileMaker is a low-code tool.

I’m with you Andy. This one is sorely missing, since many years.

1 Like