Acquiring the Portal Row Number

[laguna92651]

I am just trying to do something that should be simple, click on a row in a portal and save the row number to a variable, $row. I've attached the script to various triggers, OnObjectEnter, OnObjectExit etc, I've attached it to a button on the portal row, but no luck. The variable, $row, never shows up on the script debugger data viewer. The script only has this step in it.

       Set Variable($row;Get(ActivePortalRowNumber))

My objective is to be able to go back to the last row that I was on when I re-enter the layout. There are a total of three portals on the layout.

 

[comment]

There are several things here that don't add up:

 

3 hours ago, laguna92651 said:

I've attached it to a button on the portal row, but no luck.

If you have a button in the portal that you click, then set the button to run the script directly - no script trigger is necessary. If you want the script to run automatically whenever you click into a portal row, then set the portal's OnObjectEnter script trigger to run it.

 

3 hours ago, laguna92651 said:

The script only has this step in it.

       Set Variable($row;Get(ActivePortalRowNumber))

This will not accomplish anything, because script variables (prefixed by a single $) expire when the script exits. Since this is the only step, the variable will be erased immediately after being created. If you want the variable to persist, you must make it global (prefixed by double $$). That will last until the end of the session, or until you clear it out explicitly.

 

3 hours ago, laguna92651 said:

My objective is to be able to go back to the last row that I was on when I re-enter the layout.

And why is this needed? If it's for the user, then this will not work well if the portal is scrolled. If it's for you, then you are doing something wrong: you should be working at the data layer, and not rely on layout objects.

[laguna92651]

I had realized I needed to use a global variable, $$, to save the row number for use after leaving the layout. For whatever reason I used the local variable, $ for testing, I assumed the $row would persist as long as I didn't leave the  portal.

Is there an advantage one way or the other to use a global varianle, $$, versus a global field to store the row number?

8 hours ago, comment said:

And why is this needed? If it's for the user, then this will not work well if the portal is scrolled. If it's for you, then you are doing something wrong: you should be working at the data layer, and not rely on layout objects.

Can you elaborate on this a little more? The app is for my use. Specifically what did you mean by working on data layer not layout objects.

[comment]

1 hour ago, laguna92651 said:

Is there an advantage one way or the other to use a global varianle, $$, versus a global field to store the row number?

A global variable can be created ad-hoc; a global field must be defined in advance before a script can use it. I would advise you not to use global variables unless it's unavoidable, precisely because they do persist.

 

1 hour ago, laguna92651 said:

Can you elaborate on this a little more?

Why don't you elaborate first: tell us why you need "to be able to go back to the last row that I was on when I re-enter the layout". In what circumstances do you have to leave the layout while you're in a portal row?

 

1 hour ago, laguna92651 said:

The app is for my use.

That's not what I meant. Even if you're the only user, you still wear two hats: that of a user, and that of a developer. If the script is not assisting the user in data-entry, it should work directly on the data and not go through a portal.

[laguna92651]

The application has two separate sections, no interaction between the two, so I only have to open one app to access the two areas I usually work in. Section 1 is a contact manager, and the second section keeps a history of various financial data. If I were to be in the contact management section and need to go to the financial history section, for convenience I would like to go the same contact I was on, rather than the top of the list, when I left the contact section. Not a major deal, but convenient.

On the global variable issue it sounds like I should use a global field, which is fine with me?

The script is not assisting the "user" in data entry, it is only to go to a record for browsing or editing contact data. The layout is based on a table called Lists, with the Contacts portal sitting on top of the layout.

[comment]

To me it sounds like opening a new window to access the other "section" would be the optimal solution here. When you're done and close the new window, you will be returned to the original window in the exact state you left it, including the scroll position of the portals.

[laguna92651]

I hadn't thought of that, might be the way to go. What is the advantage of that over using the Get(ActivePortalRowNumber) approach? Within the contact section I would be going to other contact layouts then back to the main contact layout.

[webko]

The obvious advantage is that *nothing* changes on the original layout - when the new Window closes, the original is the same as it was in every way...

[Lee Smith]

Read about the “New Window” script step http://fmhelp.filemaker.com/fmphelp_14/en/html/scripts_ref1.35.92.html.

[comment]

5 hours ago, laguna92651 said:

What is the advantage of that over using the Get(ActivePortalRowNumber) approach?

The most significant difference is the scroll state of the portal/s. When you restore the active portal row, it will come into view - but it won't be exactly where it was before you left the layout.

And of course, by returning to the original window, you don't have to do anything to restore the portal row/s. Or tab panels. Or anything.

[Mike Duncan]

5 hours ago, comment said:

The most significant difference is the scroll state of the portal/s. When you restore the active portal row, it will come into view - but it won't be exactly where it was before you left the layout.

And of course, by returning to the original window, you don't have to do anything to restore the portal row/s. Or tab panels. Or anything.

If having the window look exactly as it does, then this may be an option, but nowadays I tend to avoid opening new windows due to screen flicker, potential record locking, managing multiple windows, and so on. I know, those can be mitigated and controlled as well, so it just depends on the requirements of the project.

[laguna92651]

Well I have a couple of options now, that I can play around with and see what will work for my application. Thank you all for your suggestions.