That shouldn't make a difference as far as I can tell.
In any case where I"ve seen this issue reported previously, it tracked back to the portal losing the focus before the Go To Related Records was executed. The classic example of that is when the button performs a script with Commit records first, then the Go to Related REcords step. The commit step removes the focus from the portal and then GTRR pulls up the first portal record instead of that of the clicked portal row.
That was it, thanks I had forgotten that I had added a Trigger to the OnLayoutExit.
Is there some way to run the trigger without changing the focus from the field? Or, is there some generic way to just go back to the last field that had focus after the trigger ends?
What does the triggered script do?
One option is to set up a check of a global variable to keep the triggered script from doing anything if the variable is set:
If [ Not $$TriggersOff ]
Put rest of triggered script here
Then you set $$TriggersOff to true just before you change layouts and then set it to false before the script exits to re-enable your triggers.
If you do need the script to execute before you perfom the Go To Related Records step, you can use code like this:
Set Variable [ $Row ; value: Get ( CurrentPortalRowNumber ) ]
Perform Script otherwise tripped by OnLayoutExit here
Set Variable [$$TriggersOff ; value: True ]
Go to Object ["objectNameOfPortalHere"]
Go to portal Row [$Row]
Go To Related Records
Set Variable [$$TriggersOff ; Value: False ]
Oh yes, forget to mention that you'd have to use the Name Box on the INspector's data tab to give your portal an object name. The go to object step makes sure that this will work even if you have more than one portal on your layout.
The script does very little. Its part of a back/forward system.
It sets a global variable based on the current layout and then it tests a second global variable, and then conditionally sets a third global variable. As an experiment, I commented out the whole function and it still caused the same issue. I guess just having a trigger is enough to move the focus.
I can do something like what you describe above, but its going to make everything a lot more complicated. RIght now I just have a Go To Related Record commnd on a button. Now I am going to need to make each button a function, and update trigger to not always do anything.
This seems so unintuative. Am I really the first person to have an OnLayoutExit trigger after a GotoRelatedRecord command?
I tried the TriggersOff method and I am still getting the same result (first record show instead of current record). It seems that no matter how little I do in the Exit Layout trigger, I am getting the first record as long as the trigger exists.
Is there some way to disable/enable the triggger programatically?
Otherwise, I am not sure what else to try.
I'll need to test this. I wouldn't expect the mere presence of an OnLayoutExit trigger to cause this loss of focus. I figured you had a commit records step in there that was causing the issue.
If my tests confirm what you are describing, this sounds like a bug that needs reporting. As a work around, you can script a loop that moves you to the same record as the clicked portal row.
Ok. I've run a few tests on my Windows 7 system and cannot reproduce what you are experiencing.
I took a field in one of my portals and set it up as a button. I tried this with a script and with just the go to related records button option.
I set up a script that assigned a value to a global variable and specified that teh OnLayoutExit trigger be used.
In all of the different combinations of these features that I tried, The record corresponding with the portal row that I clicked became the current record on the layout that the GTRR took me.
I have cut down my Application to the smallest amount I can do to illustrate the issue. I have removed most of the tables, all of the scripts except one and all of the custom code. I also have deleted most of the fields. When you uncompress the attached file, you will get two files, an App and a Data file.
The app file has three layouts:
Deal Details - No Trigger
Deal Details - TriggerInvestor Details
The two Deal Details layouts are exactly the same, except that "Deal Details - Trigger" has a script attached to its Exit Layout Trigger. The script is empty, so it shouldn't be doing anything to change focus. Both layouts contain a single portal. Clciking on a line on the portal is supposed to bring up the related record in the Investor Details layout.
When clicking on the portal in "Deal Details - No Trigger" - the correct record is shown. When clicking on the portal in "Deal Details - Trigger" - the same record is shown each time.The code is here: https://dl.dropboxusercontent.com/u/23607856/FMTrigger.zip
I'm on a Mac, so perhaps this issue only manifests itself here.
That is odd. I tried both layouts. Even though the trigger is checked, with no script steps, it sends you to the wrong record. Then if you just unclick it, it works fine.
The only thing that pops up in my mind is the line at the bottom of the script trigger tab which reads "If the script returns true, the original event proceeds normally, otherwise the event is cancelled". First I thought maybe its not that a scipt is selected on layout exit, maybe the script itself needs to be modified. Then I put in a Show Custom Dialog script.
After clicking ok, it still went to wrong record.
Also I can only open up DB app, not DB data (it requires a password), so I cant see whats going on with the First Name, and the auto calc Legal Name. DB app wont allow me to look at any table except globals.
But when I go to the Investor Detail Layout, the Legal Name label and field kind of vibrates. So something is going on there.
login/password on both files is all/all
yeah I took a guess....
Ok, now I see the issue as I've encountered it before with another poster.
First, the records/table you are specifiying in the GTRR are not the Records/Table shown in the portal. You are doing a GTRR to Contacts but the portal is to Investor.
You, in fact, have this relationship:
If you were using GTRR to pull up the Investor records, you would not be having this issue and that's why I could not reproduce this in my tests. You have two possible solutions you can use.
1) Set up the target layout for your GTRR as a layout based on Investor instead of Contacts. You can include only fields from Contacts on this layout given the many to one relationship you have here. Your GTRR would, of course, then need to specify the Investor table occurrence instead of Contacts.
2) set your button up to perform a script instead of a single GTRR step. In the script use to GTRR steps:
GTRR (//specify investors for layout and table)
GTRR ( //specify contacts for layout and table)
I'll try this, thanks.
Do you have any idea why it apears to work when there is no trigger?
Ok, I did soluion 1, and it is working. Thanks again.
One more question. All I did was make a copy of my contacts layout and change its source to Investor. I can't just change my contacts layout completely, because some contacts are not investors yet.
My question for you is, is there a way to avoid having two identical layouts? Now I have to remember to update the second layout when I update the first one. WHat would be nice, would be if I could just have one layout and specify which table it got its data from at load time. Is this possible?