Can the "Go to related record" script step land you on a specific portal record?

[Myron S.]

Hi my friends,

I'm trying to write a script that, when a button in a portal row is clicked, takes the user to a found set of all the related records and then lands the user on the particular record that was clicked on.

The problem is that the "go to related record" script step takes you to the related records correctly, but then lands you on the first record of the found set.

I know i could script it to take me to only that record, but I want to bring up the entire found set of all related records and land on the specific record that was clicked on.

I have a feeling I'm missing a simple solution to this problem. Can someone help?

Thanks in advance!

[Ender]

Hmm, Go to Related Records[] does bring you to the related record you were on in the portal. Perhaps your script is Committing the record prior to jumping to the related record? If that's not it, maybe you can post your script for us.

[LaRetta]

Use Go To Related ... but don't click results 'Show Only Related Records'. You will automatically get the related set and it will stay on the record you clicked.

[Myron S.]

Actually, yes, I have a "commit record" step in the script prior to the GTTR because I'm using pop-up windows and I was experiencing record locking.

[Ender]

Put the Go to Related Record[] step before the Commit Records[] step.

[Ender]

Hey LaRetta,

GTRR will jump to the selected portal's record regardless of the Show option.

In Myron's case, the portal selection is lost when the record is committed, so it just goes to the first related record.

Edited September 23, 2006 by Guest

[LaRetta]

Hi Mike ^)

Yes, I realized focus was probably the problem here (as you pointed out). GTRR will work either way but (for some reason) it seems like it would be more efficient WITHOUT the extra parameter so I was just throwing that in more out of boredom.

Edited September 23, 2006 by Guest

[Myron S.]

Hi Ender,

I appreciate the feedback. The problem definately happens because of the "commit Record" script step. Without it the GTTR does exaclty what I need.

So I moved the "commmit record" step to occur after the GTTR like you had suggested but it doesn't affect the outcome. The record is still locked and any changes that were being made in the portal are not saved. Hmmm... Any other ideas?

Thanks

[comment]

If your GTTR opens a new window, you need to start by storing the portal row in a variable or the script parameter. Commit the record, go back to the portal row and GTTR.

[Myron S.]

Thanks, Comment, your solution worked using a "set Variable" script step. However, following a "commit Record" step, the "go to Portal row" doesn't seem to work unless you first make the portal active by naming it as an object and then including a "go to object" script step first. But with that step added it works like a charm.

Thanks everyone for your suggestions

[comment]

unless you first make the portal active

It seems you have more that one portal on the layout?

[Myron S.]

No, I only have one portal on the layout. It seems that once the record is commited the portal becomes inactive. If I then use a "go to portal row" step, it goes to the first portal (regardless of whether I indicate first, last or by calculation) but it won't highlight the row even though "select all" is checked and subsequent "go to portal row" steps are ineffective. It just kind of sits there in the first row no matter what I do. However, with the go to object step included first, all subsequent script steps perform as expected.

Edited September 24, 2006 by Guest

[comment]

That is very strange. It certainly works in version 7 & 8, and I am not aware of any changes in 8.5 regarding this. Could you download this file and see if it works for you?

[Myron S.]

Yes, your file worked fine.

And I think you were right the first time when you suggested I have more than one portal.

I have several hidden single-row portals that are used to hide or show buttons and fields based on dynamic relationships. they work so well I had hidden them from myself.

So that is the problem. The good thing about 8.5 is that I can name each portal and perform a "go to Object" script step which activates the portal I need.

Sorry for the confusion. I hope you didn't lose sleep over this one, Comment, because I sure did.

Thanks again for your help ;-)

Edited September 25, 2006 by Guest

[comment]

Go to Portal Row[] goes to the first portal in the stack order. If you select your "real" portal and send it to back, you won't need the Go to Object bit (and it will work in 7 and 8 too).

[Myron S.]

You're awesome, thanks. I knew it activated the first portal in the stacking order but i thought it went to the "first" on the top of the stack. I had tried both the top and the bottom to no avail. However, when you told me it's the bottom of the stack I realized the reason it didn't work for either is because the "real" portal lays on top of a tab control. To get it to work properly I had to pull it off the tab control before sending it to the back.

Okay, mystery solved. Thank you so much!

I'm glad, though, to have discovered another great use for the "go to object" in 8.5. You can place portals anywhere on a layout in any stacking order and activte any one of them on the fly.