GTRR won't work for this. GTRR would be used to pull up the Table B record clicked on a layout based on Table B, not a row in a portal of a layout based on what is apparently an unrelated table C.
How do you determine what record in Table C is the correct record to have when you click this button? Is there a relationship between Table A and Table C? Is there some common value between the two that can be used to match up a record in Table C with Table A?
Thanks for the response. I've uploaded the relationship map to give you a better picture.
For example, Table A represents information about a part number. Table B represents the Bill of Materials (BOM). Table C represents an Assembly. Table C ties the related records together in Table B to form the BOM. An assembly also has a part number, hence the relationship between Table A and C. You can imagine in Layout A, which pulls information from Table A, has a portal that shows where the part is used on from Table C. When you click on the portal row with the GTRR button, it takes you to Layout C, Table C, which has the portal showing information from Table B. GTRR is only halfway. Ideally you should be able to see where that part is in the BOM in Layout C without having to scroll the portal looking for it, especially when an assembly has parts more than whatever the portal can handle, in terms of spaces in the layout.
I've tried adding a global field to set part number from Layout A whenever you enter Layout C, and filter portal based on the global field, but you only end up with one row for that part in the portal instead of all the parts of the BOM. It's also the same if you do in it find mode. Then tried Go to Portal Row based on input from the global field, and that didn't work either.
The relationshps shown are all one to one. Any portals based on that will produce no more than a single reccord in any portal. Can you add in just a bit more detail and maybe ditch the alphabet soup while you do so? A typical BOM setup looks like this:
Products::__pkProductID = BOM::_fkProductID
Parts::__PkPartsID = BOM::_fkPartsID
And Parts and Products can be two occurrences of the same table--which enables the BOM for one Product to list a series of assemblies that in turn have their own BOM's in a potentially infinite recursive series.
See the first post of this thread if my notation is unfamiliar: Common Forum Relationship and Field Notations Explained
Ah! Good fundamental point, that was an unnecessary addition of an extra table and relationship!
Back to the original question. I created a field PortalRowNumber in the BOM table to Get ( RecordNumber ). Then use this script to go to the portal row:
Set Variable ($portal; value BOM::PortalRowNumber)
Go to Portal Row [Select; $portal)
The problem is the field PortalRowNumber does not correspond to the row numbers in the portal. I notice you have to Perform Find to get the record number in a found set, I don't exactly know how to link them together in a script.
Get ( RecordNumber ) returns the position of the Layout's current record in the Layout's found set of records. It has nothing to do with which row in the portal was clicked. get ( ActivePortalRowNumber ) will return the number of the portal row you just clicked.
But I fail to see the purpose to your script.
That script would only work if I created another layout for BOM and perform Find to get the corresponding row numbers by product. But I'm having trouble linking them together as one script. I keep getting a return of 1, which highlights the first row of the portal.
I haven't posted any script in this thread so I don't know what you mean by "That script".
I still don't know what tables and relationships you have set up and thus cannot provide any suggestions until you do so.
Sorry for the confusion Phil. I got it to work manually. Now it's just a matter of how to put it into scripts.
Here's the clarification:
I've added in the BOM Table a field call BOM:PortalRowNumber to calculate Get (Record Number). Then I created a layout that displays all records from the BOM. This layout only serve as function and not to be displayed to users. At that point, BOM:PortalRowNumber will populate to account for all records. For example, if there's 100 records, it will give each record numbering 1 to 100. Then I perform find for a product in the BOM layout, and now the record renumbers, for example, 1 to 20, which means that particular product has 20 parts in the BOM.
Using the script below attached as button to a portal row in the Part Layout, I can now click on the portal row that takes me to the correct Product record, and scroll to the correct portal row.
I've added in the BOM Table a field call BOM:PortalRowNumber to calculate Get (Record Number).
This field is not necessary. There are several different ways to capture the current portal row numer or to display the current record number without having to add an unstored calculation field to your table to do so.
I'm sure that this all make sense to you, but from my perspective, it makes no sense at all as I do not now what portals to what tables with what relationshps are being used by you. Nor how the portal row number (which can be determined without using the calculation field you are describing) can always match up to the portal row on a different layout based on what, from what little I can discern here, is based on a different table (or possibly a different occurrence of the same table).