You might save the current portal row number in a global variable.
When the user clicks the portal row and your script fires, the script can use go to portal row and the number in the variable to return to the previously selected portal row in order to have the correct focus to save the data.
Or you might enter the primary key of the portal record into a global field when you load the data into the global edit fields. Use this field in a relationship and you can save the data to the correct record in the portal's table without it mattering which portal row has the focus.
Thanks. Good suggestions. I'll try that out. Is there a way to NOT have the portal row black out when it is select by script? Or, is there a way to change the color of the script-selected row?
Is there a way to NOT have the portal row black out when it is select by script? Or, is there a way to change the color of the script-selected row?
Have you selected all the fields and turned it into a button to perform your script to select the record and load the globals?
If you load a field or variable with the portal record's primary key, you can set up a conditional format to change the fill color of the portal row fields to highlight them to show them as selected.
All of the fields in the portal are buttons which perform a script to select the record. The only time I seem to get the blacked out portal row is when I use the Go to Portal Row with the Select Entire Contents option. If I deselect the Select Entire Contents checkbox, it puts the cursor in my first field on the portal (where I don't allow editing). This would work great if it didn't select the field to edit. Any way?
You might try this option:
Go to portal row, do what you need and use commit record to release it again--getting the cursor out of the field, but with the current portal row number kept in a global field or variable so you can re-establish the focus if you need to.
Or you might try a different scripted option that does not require interacting with the portal. Often, you can freeze the window switch to a layout based on the portal's table, do the things you need to do on that layout and then return to the original layout--all without manipulating the portal. I use this last option whenever possible as it is less susceptible to having a change in layout design inadvertantly break the script.