I see nothing out of date in that other forum thread in terms of the content--especially since how a portal scrolls has not been modified much since its introduction in FileMaker 3. There isn't any script steps specifically set up to control portal scrolling nor are there any property settings in Portal Setup... that would do this.
Go to Portal row, the script step recommended in the other thread, can scroll the portal by putting the focus on a portal row not currently visible in the portal. So if you have a 10 row portal and the first 10 rows are currently visible,
Go to Object ["object name of portal here" ]
Go to Portal row [no dialog ; 11 ]
will scroll the portal exactly one portal row. But since your script cannot detect what rows are currently visible after the user has manually scrolled the portal, this is not likely to be very successful a method to use.
If you describe your set up in more detail and why this capability is important, someone might be able to suggest an alternative approach--such as a portal that does not have scroll bars, but has buttons to click that move the user forwards and backwards through the set of related portal records N records at a time.
Basically, I've a portal that displays only one row and the row it displays has more than one level of fields in it, so it is confusion when I'm scrolling as sometimes you need to pause and look at the row to check its not half of one row and half of another. It would be great to have some white space after the bottom level of fields in the row but space doesn't allow it. I know I can alternatively colour each row but that doesn't solve the other issue of having to select the row to snap it into place when scrolling down.
I thought it would be handy if the scrolly could be set to snap from one row to another rather than a smooth scroll down through the rows. When I click into a row it snaps the row into place and highlights it blue. I thought that as it snaps it into place here can the scrolly be set to do the same.
Your idea sounds like it would help with buttons to scroll down each row, rather than a scroll bar. "such as a portal that does not have scroll bars, but has buttons to click that move the user forwards and backwards through the set of related portal records N records at a time." Can this be done to flash through the rows like slides on powerpoint, for instance? This woud solve my issue.
It can be a bit complicated to set up but it does work. I recently set up an FMP 10 database for this as the relationship was matching to 10's of thousands of records and a needed complex conditional format expression (used a recursive custom function) was bringing the entire system to a near halt when it tried to conditionally format such a huge dataset. By only matching to a small number or records via relationship, the "update load" on the conditionally formatted portal became manageable.
But in your case, since you are only viewing one record at a time, you don't even need a portal.
I am assuming that your current one row portal is not filtered.
Say your relationship is currently:
LayoutTableOccurrence -----< PortalTableOccurrence ( ---< means "one to many" )
LayoutTableOccurrence::PrimaryKey = PortalTableOccurrence::ForeignKey
You can add a new occurrence for the portal's table and link it like this:
LayoutTableOccurrence::SelectedRecordID = PortalTableOccurrence|Selected::PrimaryKey
In place of your one row portal, you'd add the needed fields from PortalTableOccurrence|Selected directly to your layout.
You can then set up a global variable, $$Rec as a counter and initialize it to be 1 with an OnRecordLoad performed script.
Your button to show the next record would then look like this:
Set Variable [$$Rec ; value: If ( Count ( PortalTableOccurrence::ForeignKey ) > $$Rec ; $$Rec + 1 ; $$Rec ) ]
Set Field [ LayoutTableOccurrence::SelectedRecordID ; GetNthRecord ( PortalTableOccurrence::PrimaryKey ; $$Rec ) ]
If layout is slow to refresh after performing this script, add a commit records step as the last step.