Go to portal row

[Philip Jenks]

Hi everyone

I have a script trigger in a field inside a portal on 'Layout 1'.

The script goes off to a related table (same file), does some calculations, then returns to Layout 1.

When it returns, I want it to scroll down TO THE PORTAL ROW IT STARTED FROM, so that that portal row is visible and active, and the user can see that the calculations have been done. Some records have 25 lines in the portal, so it’s tiresome for the user if the script comes back and display portal row 1 instead of (say) portal row 16, because he/she then has to hunt for the correct portal row.

My script in the original layout starts:

Set Variable [$ActivePortalRow; Value: Get(ActivePortalRowNumber)]

and then when it gets back to Layout 1, it says:

Go to Portal Row [Select ; no dialog ; $ActivePortalRow]

the choice of portal row being defined as a calculation and the calculation simply being: $ActivePortalRow.

It’s not working! The script successfully returns to Layout 1, but doesn’t go to the original portal row and, in fact, doesn't seem to go to any portal row. I’ve tested by changing to ‘Go to portal row [Last]’’ and that doesn’t work either. It just does not seem to want to take any instruction on 'Go to portal row' at all.

I’ve tried various things. e.g. inserting a step saying ‘Go to Object’ where the object is the portal name. I’ve also inserted a 'Go to field' step, using a field which is inside the portal (and only inside the portal). Again, no joy.

Any know where I'm going wrong?

Thanks

 

Philip

[siroos12]

42 minutes ago, Philip Jenks said:

Hi everyone

I have a script trigger in a field inside a portal on 'Layout 1'.

The script goes off to a related table (same file), does some calculations, then returns to Layout 1.

When it returns, I want it to scroll down TO THE PORTAL ROW IT STARTED FROM, so that that portal row is visible and active, and the user can see that the calculations have been done. Some records have 25 lines in the portal, so it’s tiresome for the user if the script comes back and display portal row 1 instead of (say) portal row 16, because he/she then has to hunt for the correct portal row.

My script in the original layout starts:

Set Variable [$ActivePortalRow; Value: Get(ActivePortalRowNumber)]

and then when it gets back to Layout 1, it says:

Go to Portal Row [Select ; no dialog ; $ActivePortalRow]

the choice of portal row being defined as a calculation and the calculation simply being: $ActivePortalRow.

It’s not working! The script successfully returns to Layout 1, but doesn’t go to the original portal row and, in fact, doesn't seem to go to any portal row. I’ve tested by changing to ‘Go to portal row [Last]’’ and that doesn’t work either. It just does not seem to want to take any instruction on 'Go to portal row' at all.

I’ve tried various things. e.g. inserting a step saying ‘Go to Object’ where the object is the portal name. I’ve also inserted a 'Go to field' step, using a field which is inside the portal (and only inside the portal). Again, no joy.

Any know where I'm going wrong?

Thanks

 

Philip

Hi Philip,

 

Consider you have "Main" and a "Child" table. These two tables are in a relationship using a field called "Key" in both tables.

 

Below script would do the job for you:

 

Set Variable [ $RecNo ; Value:Get(ActivePortalRowNumber) ]
Go to Related Record [ From table: “Child” ; Using layout: “Child” (Child) ]
Set Field [ Child::Text ; "test" ]// Do your caculations here
Go to Layout [ original layout ]
Go to Portal Row [ $RecNo ]
[ Select; No dialog ]

Please give it a try and let me know if it works from your end.

 

Regards,

 

 

 

[Philip Jenks]

Thanks Siroos

Yes, I think that's exactly what I have been doing. Most of the script is working because the recalculations in the Child fields are ok. The only bit that isn't working is:

Go to Portal Row [$RecNo}

I had wondered if the problem was something to do with Get (ActivePortalRowNumber) being text and Go to Portal Row being a number, but if I try the simpler:

Go to Portal Row [First]

or 

Go to Portal Row [Last]

that isn't working either, which suggests it's nothing to do with a text/number conflict.

Hmm ...

 

 

Edited June 6, 2016 by Philip Jenks

[siroos12]

Where in your script you set the portal row number? is it possible to post the script here so I can have a look?

Edited June 6, 2016 by siroos12

[Philip Jenks]

Hi Siroos

Can you see this screenshot?

The 'Set Field' steps are the recalculations going on in the other table. Actually, they're going on in the portal row. I don't change layout as don't think they're any need to.

Edited June 6, 2016 by Philip Jenks

[siroos12]

I just tried to replicate the problem here. I did simulate your script and it works here. I am not sure what is wrong based on the screen shot of you.

 

I wonder if you can print the whole script or attached your file here. If you decide to attached the file, please make a clone copy so there is no confident information in it. 

 

 

[Philip Jenks]

That's interesting. Thank you.

I wonder if the presence of something else on the layout is disturbing the final step of the script. I am going to create a duplicate of the script, with only the portal on it, and see if that works. Will let you know ...

Thanks for your help.

Philip

[siroos12]

Cool, Good luck.

[Philip Jenks]

Hi Siroos

Ok, this is embarrassing. I discovered that the script IS working. The reason it didn;t seem to be is that after the Go to Portal Row script step, at the foot of the script, was another script step which did something else. I've relocated that script step and - hey presto! - I can see the active portal row.

Sorry to have wasted your time. I hope to be in S.A. at the end of this year and owe you a drink.

Philip

[siroos12]

10 minutes ago, Philip Jenks said:

Hi Siroos

Ok, this is embarrassing. I discovered that the script IS working. The reason it didn;t seem to be is that after the Go to Portal Row script step, at the foot of the script, was another script step which did something else. I've relocated that script step and - hey presto! - I can see the active portal row.

Sorry to have wasted your time. I hope to be in S.A. at the end of this year and owe you a drink.

Philip

Not a problem at all mate, Happy that it is fixed now. 

 

Let me know when you are here in SA.

 

Regards,

[comment]

BTW, if you want to preserve your position in a portal while going to another layout, considering opening a new window. This method of storing the portal row number then going to it will never restore the exact scroll position.

[Philip Jenks]

Thanks Comment. Opening a New Window may be the best route. Seems so obvious now that you mention it, but I hadn't thought of it!

[Ron Cates]

As an aside. It's been an age old issue that opening a new window is a bit of an ugly experience in Windows ( I realize you're on Mac so this may not apply ). As for the scripted methods, as Michael said, none will restore the exact scroll position. There are techniques that come close but often these techniques can be pretty clunky and complicated. In my experience I have often found it more desirable, for other reasons as well, to just not leave the layout in the first place. I use global fields and table occurrences to establish relationships on the fly so to speak, to any records I would like to modify without leaving the current layout. Since adopting a variation of the Selector Connector model I have been able to come up with a structure along with some modular scripting that allows me to easily create, delete and modify related records in any table from whatever layout I am on. In my current project in fact I have managed to build the entire solution thus far without using a single go to layout script step, that I can think of, except of course for the purpose of navigation.