

Now using the function to GetLayoutObjectAttribute, I can dynamically show the button only with the portal row is active with. So, to set this up, I had to add a field in the related table as an unstored calculation Get ( RecordNumber ). Beginning with FileMaker Pro 11, you can add a filter to a portal to specify the related records that are shown. In the following example, we will be looking at departments and their related employees. In FileMaker 13, you can with the new FileMaker hide object feature. A portal is a layout object in one table where you place one or more related fields to display in rows the data from one or more related records. For example, a record for a neighborhood might show all the related house records in a portal, or a record for a class might show a portal of all the students. In their most basic form they display data that pertains to the essential relationships in a given system. You may also have some geeky fun in the process. Portals are important tools in the FileMaker toolbox. The user gets the user interface they want, and you get to keep the relationship graph under control.

Problem: When TABBING from field-to-field, while ENTERING NEW DATA in the PORTAL, the active field jumps OUT OF THE PORTAL to the layout and, eventually, back into the PORTAL. Using functions in the presentation layer obviates the need for additional relationships and table occurrences. This includes creating additional PORTAL records (as needed) before the TAB (or CLICKING) out of the PORTAL to the other fields on the LAYOUT. When I click on the button, I would expect an insert file dialog box to appear. Ive added an 'attach file' button to the portal which triggers a simple 'Insert Fileportaltable::attachmentfield' script.
FILEMAKER PRO 11 PORTALS HOW TO
If users have a strong preference for navigating with previous and next buttons, however, this function provides that feature without requiring significant development time. Landon Porter of Honeycomb Custom Database Solutions (demonstrates how to accomplish dynamic portal sorting in FileMaker Pro 11. Im working with a FileMaker Pro 11 database that contains a portal. Nine times out of ten, users have no objection to navigating with scroll bars, which FileMaker handles just fine. Why would you choose this scripted approach over simply providing a scroll bar? As a rule of thumb, I generally employ native FileMaker functions and features over something I have to script and manage myself. Arrow icons or buttons provide the user with the ability to view sets of records without having to scroll. With a script trigger and a few global variables, you can implement this feature in any database where parent records display child records.
