With the new Current Table Portal (aka master-detail), you can click on any portal row, and that record is selected in the base context for that layout. FINDS and SORTS within the base context, directly impact the portal content, which is awesome.
However, I have not figured out how to IGNORE a blank portal row. IF a user was to click on a blank portal row, and a OnRecordEnter script trigger was to say, go to a layout / card / tab / slide control, to reflect detail, the blank record selection goes to the last active record, ignoring the location of the blank record click.
Needless to say, this could create some data quality issues with users.
Yes, you can always revert to traditional portals and script the interaction. You can also place a transparent button over the row and capture say, the primary key and code the interaction.
Those approaches defeat some of the key benefits of using the new current table portal.
Anyone know how to get around this limitation, while maintaining the new portal type?
When do you have blank portal row while using the current table portal? Or what do you mean by blank portal row on the new master-detail portal? Shouldn’t there be only portal rows based on the current found set?
No records. The portal shows 10, but only 2 records exist, so the blank area displays, but has no records, no data, but responds to a OnObjectEnter.
So you have an area with no data, where there are no records, but a click on the area of any “blank” (not a record) executes the portal OnObjectEnter, but for the last “real data”
Works great for existing data - just don’t want a user arbitrarily clicking where there is no data (or tapping) and have them go to the detail edit screen, for some other record and make changes. IF there is not a commit (implicit or otherwise), these clicks have no effect. However, IF there is a commit, then the "no-record-area: of the portal triggers the OnObjectEnter script.
This behavior does NOT exist on traditional portals, but does on Master-Detail portals.
I built a couple of sample files to display this aberrant behavior, but idk how to post sample file attachments here…
Look for the upload button on creating message
MD_FMP18Test.fmp12 (224 KB)
This 2 button master-detail portal shows the issue. The left does not have a commit, but by clicking outside the portal, an implicit commit occurs. After a commit, a click into the non-record containing body area of the portal, executes the OnObjectEnter script trigger.
The right portal adds the commit to the script trigger, so the problem is consistent. (wish it was the opposite; the solution would then be obvious).
FM18-MD_PortalBehavior.fmp12 (220 KB)
And before someone gets into the alternatives that DO work, here is an example file with those alternatives shown in portals 2, 3, & 4.
The issue was identifying behavior that is both inconsistent and problematic with the new (FM17) Master-Detail / current-table-portal construct and the OnObjectEnter trigger.
Master-detail portal triggers first the go to record step before Portal’s On object enter -script is triggered. When clicking non-existent portal row (“empty”) it will not trigger go to record because not other than current record was chosen.
Traditional portal just does not have go to record behavior.
Order of script triggers are different. FMP 17 help show differences between different portals: FileMaker Pro 17 Advanced Help
If there is a trigger on layout “On Record Load” the difference of behavior is seen.
Get(ActivePortalRowNumber) was published together with master-detail portal (in fmp 17) so I guess that it’s behavior is mainly purposed to act with master-detail portal.
I believe that your example file just shows that there is no empty portal rows on master detail because it shows the current record (or current active portal) if clicking on empty area of portal.
2 Likes