Thanks for the help. Beverly has put her finger on the problem: there is no "trigger". I have tried using calculated fields with functions like Get(PortalRow) on the master layout, but the problem with them is that they don't seem to update whenever one moves to another portal row, even when they are not stored - it is necessary to use a Refresh Window command.
So it seems that there is no way to solve this problem without scripting. That's the way I have been trying to address it, but I thought there might be a way of structuring the tables and layouts to do it automatically. Apparently not! Thanks again. Bruce ________________________________________________ Bruce Button Tel: 012-331-7072; Fax: 086-602-8247; Cell: 082-412-4972. PO Box 31442, Waverley, 0135, South Africa. Email: [EMAIL PROTECTED] -----Original Message----- From: FileMaker Pro Discussions [mailto:[EMAIL PROTECTED] On Behalf Of Beverly Voth Sent: 9-January-2008 09:10 PM To: [email protected] Subject: Re: Automatically update field from portal On 1/9/08 1:48 PM, "Bruce Button" <[EMAIL PROTECTED]> wrote in whole or in part: > I have a master layout which includes a portal showing related records > (namely a list of projects). I would dearly love to place a field (call > it Master_Project) on the master layout which updates automatically as > one moves through the rows of the portal - say with ProjectID or > ProjectName. Thus, when one moves (say) from row 2 to row 3 in the > portal, the field Master_Project will change to show data from the > current portal row. Try as I might, I can only get such a field to show > information from the first related portal row, irrespective of which row > is active. > (I am using FM Pro 9 on Windows XP.) > > Thanks for any help. Since there is no "trigger", the related information is only from the first related record as if you placed the related fields on the layout without a portal. If the user were to "scripted-navigate" through the portal rows, for example, then you can set a field that is the related record "id", rather than the match field from the relationship. I often add my own buttons to "scroll" the portal up and down rather than relying on the built-in scroll. Keep in mind that any interaction other than that record needs to clear the scrolling mechanism. If you go to another RECORD, the detail needs to match both the primary key for that record and any "id" used to get the details. Beverly __________ NOD32 2778 (20080109) Information __________ This message was checked by NOD32 antivirus system. http://www.eset.com
