1 of 1 people found this helpful
You can use Get(RecordNumber) to get the active record number.
Then you just need to specify "by calculation" under the go to record script step to go to that record number.
Also I believe if you use a "Go To Object" or "Go To Field" script step, it will go to the highlighted active row for those actions as well.
Thanks for the try Mike, but no cigar. I tried both methods, and nothing happens. The reason being, the desired record is already active, it's just not visible unless I scroll down to it. As mentioned previously, the list always appears scrolled to the top, regardless of which record is active.
After reviewing the solution, I think I see the issue. The starter solution came with a trigger which runs on layout enter. This causes a sort to be done, which I think is causing the list to scroll to the top. Because this trigger is already there, I can remove the trigger I created and use this one.
Still, I need to actually get the list to scroll so the active record is visible. If there is no "scroll to active record" script step or similar, I think the only way is to go to next then go to previous, both of which forces the new active record to be visible. I'm guessing that when I get the active record number, I should also get the last record number somehow, then if current record = last record go to previous then next. Otherwise go to next then previous.
This seems like unnecessary work, especially if opening the layout for the first time. I can't see any way around it, though, if there is no "scroll to active record" or "ensure active record is visible" step.
I don't suppose there are "first visible record" and/or "number of visible records" properties available?
1 of 1 people found this helpful
Your last record number is the same as Get(FoundCount).
As I also noted, using "Go To Field" to go to the first field in your body object should also take you to the active row.
You could also add these actions to the layout trigger that is run so it happens automatically when you return to the layout.
Well, this is a perfect example of "stupid programmer error".
I just noticed that the list layout enter triggers a sorting script, and the last item is Scroll Window [Home].
Instead I should put Scroll Window [To Selection].
Unless, of course, I have just filtered the list, in which case it's proper to select the first item in the list.
So I changed my scripts as follows:
When selecting an item in the list, I first set $$ActiveRecNo to the record number I clicked on.
When filtering my list, I first set $$ActiveRecNo to 0.
When activating my list layout, instead of Scroll Window [Home], I put a test of $$ActiveRecNo > 0, and then either select first record or scroll to selection.
Thanks for your contributions Mike.
This brings up one of the trickier issues with Script Triggers. They can mess with your script, creating unexpected results that are difficult to quickly track down.
The way I avoid this is basd on blog post from Digital Fusion (http://www.teamdf.com/weetbicks/a-local-way-to-suppress-script-triggers/143/)
The essence of this method is to pass a paramter to the script trigger upon calling it. In my case, I pass "Get (ScriptName)" as a paramter to the trigger script.
Whe the script is called from a trigger action (enter layout for example), NOTHING is passed to the script as a parameter because Get (ScriptName) is not defined when a trigger calls the script. You can capture this in the trigger script and do what needs to be done at that point. (see below for a simple example)
When you call something like Change Layout (layout name) from a script, however, Get (ScriptParameter) does have a value and therefore the calling script's name shows up. Now you can capture this SOMETHING and therefore do NOTHING (if that is what you need done).
Thanks @deninger, that is quite helpful to distinguish how the script was called from. I will remember this and use it in the future. In my case I needed to use a $$ variable because my sorting script is called from a trigger AND from other scripts, and I don't need to distinguish the source. Just needed to know whether or not to scroll the window to the top or to the active record.
As a newbie, I really appreciate the technique. Thanks!
I tend to stay from global variables because tracking down which script changed the value unexpectedly (or failed to clear a value etc) can be a huge pain. Instead of using a global variable, consider using an optional script parameter to pass to the script to flag the scroll feature.
eg. Perform Script ("My Script" ) is default behavior (say leaving the list on record 1 sorted list)
and Perform Script ("My Script" ; Parameter: "scroll") enables auto scrolling to the previous record
If your script already requireds a parameter, you could add a second optional parameter. I tend to add error checking in the script by looking for the ValueCount(Get(ScriptParameter) <= 2) and handling the case where only the main parameter is passed vs. when both are passed.
Perform Script ("My Script" ; Parameter: "parameter 1" & ¶ & "parameter 2") // second parameter is optional and defines scrolling behavior
Tracking down the script parameter passed to a script is trivial compared to the global variable method IMHO
Get(recordnumber) passed with script
scroll to get(script parameter )