PDF Estimated Time To Read This: 2 – 3 minutes
I’ve run into the problem a number of times (while developing in FileMaker Pro) that I make a change to some data on one of my layouts, and the related data that I was expecting to see does not instantaneously get updated. My simple old approach was to use the “Refresh Window” script step that takes advantage of the “Flush cached join results” option. I’ve recently learned that this can be a very bad practice. Especially when your FileMaker Pro solution is being served to multiple clients. The approach that I’ve been taking lately is rather simple, and in some ways actually works a lot more elegantly too.
For the purpose of explanation, I”m going to assume that you understand the “Hidden Portal” technique, and I’m going to use a solution that is using a checkbox containing a value “Other” as an example. When the end user clicks “Other”, then the hidden portal technique kicks in. An extra field will instantly appear (from within the hidden portal), and the end-user will have the ability to explain their “Other” choice in greater detail.
For Windows users, had I taken my previous approach, not only would this have caused the server a fair deal of grief, but it would’ve also caused the end-user’s entire screen to flicker during the refresh. This new approach circumvents both of those problems.
To accomplish this, you’ll need to modify whichever relationship your related data comes from. This can be done by adding an additional predicate of cartesian product [X]. The fields you select are for the most part arbitrary here, but make note of whichever field you select for the near side. Once you have made this modification to your relationship, then you’re good to go. All you have left to do is to update the field that you made note of. This can be done typically via “Set Field”, and you can even get away with setting the field’s value to whatever it’s current value is. Perform this “Set Field” any time you need to do the refresh and the rest is taken care of for you.
4 Comments
This article is potentially very interesting but there were two flaws. For one, the Youtube video had no sound and only lasted a few seconds, so I found no useful content there. For another, the method description text only cryptically referred to “adding an additional predicate of cartesian product [X]” … I think I understand the general intent but more description is necessary (or an example) to clarify the situation before I’d try to use this technique. Until now I’ve used the “Refresh Window” script step also, but if there’s a reason not to then you’ve got my attention.
Hi Charles;
The YouTube video was added solely to show the outcome of such a technique. It was recorded on the Windows platform, and as you can see from watching it, you do not get the typical screen flicker that you would from using the “Refresh Window” step.
As far as the cryptic reference you were referring to: Basically, in order to get the “Hidden Portal” technique to work, it requires the use of a relationship. Set up that relationship as you normally would, but add a secondary predicate to the relationship. This predicate will use the cartesian product [X] instead of the typical equals to [=] relationship. When this technique is used, and you update the field on the near side of the relationship, the portal(the one that’s using this relationship)’s contents will be updated.
Using this technique will provide much improved server performance over the alternative, and will also alleviate the screen flicker that is present on the Windows platform.
Excellent tip! Thanks for sharing.
Matthew. I agree with Charles that the explanation is a bit cryptic and the YouTube video needed some explanation what it’s supposed to show.
But I appreciate your effort to bring attention of other developers to this very useful technique.
I think more than as just an alternative to Refresh Window, the real value of it is in the ability to refresh only a selected part of the layout.
For those for whom the explanation seems still cryptic, let me explain if using different words.
The key of this technique is in that FileMaker Pro always refreshes contents of a portal (but not the rest of the layout) when you modify the local relationship key. Even if this change does not affect the related records set.
If the data you want to refresh is already displayed in a portal, just add one more key to the relationship definition, base it on a special “refresh” field in the local table and any field in the remote table, and set the match operator to [x]. This way the “refresh” field can contain any value without affecting the related records set. So you can force the portal to refresh by simply modifying the “refresh” field.
If you want to refresh anything else, you can create a new relationship which returns at least one related record, and enclose the part of the layout you want to refresh with a portal using this new relationship. Again, to refresh the portal contents, simply modify the local key field of this relationshiip.
Thanks again, Matthew, for sharing this. It’s an important optimization technique every serious FileMaker developer should be aware of.