I've been working on getting all my scripts for basic search, sort and navigational functionality "portable", so that they work on any given layout in my solution. I've succeeded, with the exception of portals which still create a huge overhead in programing time.

I got stuck quickly, when I realized that there's no way to go to a related record by calculation. Otherwise, I could maybe use object names to indicate what portal I'm in, and where FileMaker should go.

Does anyone have an idea how this could be accomplished?

It's just about the basic functionality: add record, delete record, go to related record.

Thanks!!

Send the base table name and record PK as script parameters and perform a find rather than a GTRR?

That's interesting. I didn't think of that...

However, I think this would send the PK of the base table and display all related records. There's going to be many related records with the same primary key. How could I get it to go to the very record I'm clicking on in the portal?

Or am I thinking wrong?

A PK by definition is unique to a record.

You question really depends on the specifics of you file and your goals.

I understand the PK is unique, but am I not getting the PK of the record in the Base Table I'm browsing, as opposed to the PK of the record in the related table?

Without "going to related record", how am I going to get the PK of the related record?

I'm assuming that a user is supposed to click on a portal record and that brings the user to the layout of the related table with that record showing; that a button is attached to the portal record.

The portal record is aware of itself, including its PK. Set the script parameter to relatedTable::PrimaryKey.

Your related child records should have their own PK. Pass that PK as a parameter and perform the find in the child table.

I wasn't aware of that (that the record in the portal is aware of itself) - fantastic, I'll put it into action.

Thank you for all your help!