You are correct that the change in layouts causes the portal to "lose focus" and thus the portal row clicked is no longer the current portal row.
You can use:
Set variable [$Row ; get ( CurrentPortalRowNumber ) ]
At the start and then
Go to Object ["portal object name"]
Go To Portal Row [$Row ; no dialog]
To resestablish the focus on the originally clicked portal row.
(Use the name box on the inspector's postion tab to give your portal an object name. This is not strictly necessary unless you have more than one portal on your layout, but is safer if you do as you might just add a second portal at a later date.
On a different note, what is that loop supposed to do for you? I can't help thinking there's faster way to do whatever it is that loop is doing when you create a record, do the loop and then delete the record you have just created.
Thankyou -that worked a treat. Learning a lot !
If you're interested....
I am calculating an "Eddington Number" - for a given data type this is the largest number X such that there are at least X instances of a value great than or equal to X.
For example it was originally coined with respect to cycling. So a riders cycling Eddington number would be the greatest number X where they'd done at least X rides of X miles or more.
I've been pondering how best to do this. My first effort which works is:
Have a table that lists all my values (called my Base Data)
Have a related table which is related by a value X which relates to any row in Base Data thats greater than or equal to X. I have another relationship which looks at the value X+1 with the same relationship (this is to allow me to decide if the value is the greatest and thus the Eddington NUmber).
This method works great. However I track 100s of Eddington numbers and thus the layouts that reference in to this are vvv slow. The numbers don't change that often so I want to do it as a script. This is what this script is trying to do. It effectively works out the count of values great than the number X and then keeps upping the value of X until it gets to the maximum value where there are X or more values greater than or equal to that.
If there is a quicker way I would love to find it !
Thanks for you help.
Hmmm, what a fascinating puzzle!
This may be what you've worked out already, but using the cycling model here.....
Rider-----<RideData---<RideDataSameDistorLess (RideData and RideDataSameDistorLess are occurrences of the same data source table.)
Rider::RiderID = RideData::RiderID
RideData::RiderID = RideDataSameDistorLess::RiderID AND
RideData::Distance < RideDataSameDistorLess::Distance
A calculation field, cEddCount, in RideData could be defined as:
count ( RideDataSameDistorLess::RiderID )
Then a filtered, sorted portal to RideData can use this filter:
RideData::Distance < RideData::cEddCount
I can see where that might result in very slow layouts given significant numbers of records in the RideData table due to the inequalities used in both the self join relatinship and the portal filter...
It is fasctinating. To give an idea my "Base Data" table has ~60,000 rows and these are being added to at a rate of 30-50 per day EVERY day - this is a training diary and in theory I could be using it for the next 30 years by which time it will have perhpas 250,000 rows. Since Eddington numbers only get bigger I could go through and remove irrelevant values (which I've considered).
The above approach is what I've been using and it works perfectly and is totally reliable just makes certain views very slow. So I'm trying to come up with a script method to see if it's any better.
For data that is static or nearly so, you can sometimes save signficant processor cycles by updating summary totals in a simple number field each time a record is added. The catch is that changing an existing data point is now a lot trickier as you have to take the old value out and then put it back in with the new value. Here's a possible take on updating your Eddington totals via relationships and a Replace Field Contents Batch update of the affected Ride Data records.
Use the relationships as we both arrived at, but use Go to Related Records specifying the RideDataSameDistorLess occurrence to bring up all RideData records for the same distance or less. Then use Replace Field Contents to increment a counter field in each of these records:
Replace Field Contents [No dialog ; RideData::ECounter ; RideData::ECounter + 1]
I will have a play around with that in a few days as I'm heading away for a bit.
Thanks for the suggestion.