Lost in Portal

[obesefeline]

Hi. I using FMP 5.5 for a screen with 5 portals. I want to work with records in one of these portals, looping thru the records. The loop runs forever - so I'm either stuck on row one of the right portal or I'm not looping on the intended portal.

I think I'm making the right portal active by Going to the leftmost Field in the portal and I think I'm looping thru the rows of that portal using Go to Portal Row(Select, Exit after last, Next. This command preceds the End Loop.

Does Going To a portal field make that portal active? Does it stay active until if/when you Go to a different portal? Does FMP lose track of what portal it was using if, within the loop, non-portal fields are referenced?

Any thoughts would be appreciated.

Doug

[jeffer]

When a script relates to a portal, it will always work in the portal thats on top of all the other portals. So when you need some scripting to do in another portal...rever to another layout where that portal is on top of all the other portals.

Jeff

[obesefeline]

Thanks for the response. I'm not clear on what you mean by the portal that's on top. Whatever on top means, does this mean that I can't have a script that can do analysis of records in one portal on a layout, then analysis of records in another portal on the same layout?

The Help refers to the "active portal" - how do you make a particular portal active if Going To one of its fields doesn't make it active?

Doug

[jeffer]

In layout mode, Use the "bring to front" option (arrange menu) after you have selected the portal. The script will be using that portal. When you have a script that uses a other portal, just duplicate the layout and bring the apropiate portal to the front. In your script step, place the line "go to layout" and mark the layout with that portal on top.Sorry if I wasn't clear in my first reply!

Jeff

[SteveB]

If you have 2 or more portals on the same layout and the portals have the same field that you access with a GoTO Field, you'll have problems. If you want to go to portal B, you should use a GOTO field that is specific to portal B. If necessary, add a unique field and hide it by making it very small and non-enterable.

[obesefeline]

Thanks for further responses. I think that I'm staying on the right portal. I'm testing with a script that does nothing but counts portal records per master record. Most instances of the portal have only one record and the script works fine, moving to the next master record after counting the single portal record for the prior master record. When it gets to a master record with 2 portal records, it counts the first, moves to the second portal record, counts it, but then doesn't recognize that that was the last record in the portal. It just sits on the second record, and counts and counts.

Doug

[jasonwood]

I believe (?) that some script steps (like "Set Field") will cause the system to forget what portal row it is on. What script steps are you including?

Why not just have a calculation field that keeps track of the number of line items? Do you need it to only update when you run the script?

If so, you could run an external script...

Script in main file:

Go to related records [show only related records]

Perform external script (see below)

Set field, myRecordCount, Relationship::globalFoundCount

External script in line items:

Set field, globalFoundCount, Status(currentFoundCount)

[obesefeline]

Hi. I don't want to count the portal rows, I just using that as a test. I want to look for certain characteristics in the portal rows and I'll add this logic if/when I can get the basic process working.

Attached in the current script (in jpg -sorry for the poor resolution). PR Contact is the related file for the portal I'm starting with. I've tried every combination of Go To Field's trying to get FMP to stay on the right portal and on the right row in the portal. With the pauses I can see the progress, and as the preceding posting said, when it gets to the first master record with more than one portal row, it properly gets down to the second row and then begins to spin its wheels. My suspicion is that it keeps going back to row 1 just before it gets to the Go to Next portal row.

I tried using Go to portal row based on row number and came up dry. If it is possible (and intended that you be able) to work with the set of related records in a portal, I reckon I don't understand why it isn't straight forward. Maybe it is, and I'm just missing the magic bullet.

On a separate subject - how come the Forum doesn't accept pdf attachments?

Doug

[Vaughan]

Scrolling through portal rows is slow and, if there is more than one portal on the layout, not very robust or reliable (as you are finding out).

Most people are (gently) advising that you should forget scrolling through the portal and instead loop through the records in the related file. I tend not to be so gentle: do it. It's much faster and more relaible and it won't unexpectedly break if you (or worse, somebody else) changes the layout with the portals on it some time in the future, not realising it's gonna be mission critical.

Jason Wood posted the basics of a script to perform the magic: give it a try. My 2c might be something like this:

Allow User Abort [off]

Freeze Window

<<stuff to do before touching the related records>>

Go to Related Records [show only related records: relationship]

Perform Script [external, related file::script2]

<<stuff to do after the related records are processed>>

Refresh Window [bring to front]

--

Script2 in the related file:

Allow User Abort [off]

Freeze Window

Go to Record [first]

Sort <<if necessary>>

Loop

If [<<test for the record>>]

<<whatever process is needed>>

End If

Go to Record [next, exit after last]

End Loop

<<optional clean up steps: show all records, unsort, etc>>

--

Just a tip: while testing the scripts particularly the loop in the related file, work methodically, back-up before running any changes, and modify the first step to "Allow User Abort [on]" so you can cancel out in case it goes infinite.

[obesefeline]

Thanks, Vaughan. I'll switch horses to use external scripts.

Doug