A filter is not the same than a relation, your relation is X so "gtrr" will show all related records, or did I miss something?
Maybe you need a function "GTFRR" go to filtered related records?
Or is the problem a different one?
If you exit a portal, or a record, you do not have any relation more. Because you have no spot.
It has to do with the context.
If you have a button within a portal, with the portal filter, the context will be the portal. So a GTRR will take over the rules of the portal including the portal filter.
If your button is outside the portal, the context will be the top record. Like expected, the GTRR will use the rules of the relation. Although there is an exception: if the cursor is inside a field of the portal with the port filter and the button is outside the portal, the context will be the portal and the GTRR will take over the rules of the portal filter.
But if you have the script trigger "onLayoutExit" defined on the layout, the context will always be the record and never the portal, even if the button is on the portal (or the cursor is on a field on the button). So you loose the current context.
ok, so you registered this 'bug' (or 'Gotcha') AGES AGO, but it has just bitten me - and I at last understand what is going on.
Our scenario is:
- We have an FM email client solution with a master-detail layout: A portal on the left shows the emails in your inbox and the current email is shown (in a web viewer) on the right.
- The layout has an OnLayoutExit script trigger on it (a workaround for a copy + paste bug on windows , when copying out of a web viewer).
- The portal can be filtered, and when you click on a portal entry a script is run to display the selected email.
- This script makes sure the focus is on the portal, uses a GTRR to spring to a "work layout" (based on the same TO), before returning to the mail client layout.
The result we get is:
- We land on the correct record,
- but the filter has been ignored, we have ALL related records shown
What is happening?
OnLayoutExit seems to be implemented in the following way:
- The GTRR script step is half-executed, to see if the Layout changes
- If the GTRR leads to a layout change, the script is triggered...
- if the trigger script does not abort the action...
- the GTRR script step is executed again...
- HOWEVER the half-execution in step 1 seems to have (half-) LOST THE PORTAL FOCUS...
I say HALF-lost the portal focus, because it FORGETS the portal filter but REMEMBERS the record of the portal row (i.e.: we land in the correct record, not in the first record of the relationship.
Now it is FMIs turn to classify this as
- a bug - and then fix it - or
- a feature - and then we can add to the list of 1001 FM Gotchas ;-)
Happy FileMaking, whichever way it goes!
Thank you for resurrecting this post. Otherwise, it would have been lost. I don't have a reason why it was overlooked.
I am able to replicate the issue under FileMaker Pro 15. This issue, along with a sample file, has been sent to our Development and Testing departments for review. When I receive any feedback, I will let you know.
you are welcome ... and thank you for the quick response!
Testing says when the script runs, the portal no longer has focus. One of the reason why the example always shows 5 records because a Cartesian relationship is used and all records will be related. Changing the relationship type and adding a script to move the focus back to the portal in the script used by the script trigger will then work.
After making those changes, I can confirm this works. Using the example above by "KoenVanHulle", I changed the relationship to not be Cartesian (that is, key = kind), assigned to the portal the object name "portal", and added to step #11 the script step: Go to Object [ "portal" ].