Select Previous Row

I have a to do list table:
When a user marks a record as DONE, a RunActions() is called that sets a row’s status to “Complete”. It also runs an OpenWindow with a link to the current table. That causes the record that was just marked complete to be filtered out as hoped

However The behavior that I don’t like is that the user loses their place on the page.
For example, if you have scrolled quite far down the table, marked something as complete, you will be launched back to the top of the table.

Is there a way to make the row lose focus so that the filter is re-applied without scrolling the page?

Is there a way to link to the row previous on the current table? That way I can Openwindow() and not lose my place.


Hi @Nick_Solyom :blush: !

Maybe this Action formula could help you here :
(See the sample doc down below :blush: )

  thisRow.Index != 1,
  Table.Nth(thisRow.Index - 1).ObjectLink().OpenWindow(),

So, the first thing I did was in my table was to add a Index using simply this :


It returns literally the visual position of thisRow within the table Table (Find()).

This allows me to ask to my button to retrieve the previous row using Nth() :

Table.Nth(thisRow.Index - 1)

Then grabs its url using ObjectLink() which is then used by OpenWindow() :blush:

This is just an idea which, depending on your use case, might need some adjustments :innocent:
But I hope this helps a little :blush:

1 Like

LOVE IT @Pch !
Will the Row position formula update per user? In my doc there are personal sort and filter controls. I assume so right?

No is the answer, sadly the index created with thisTable.Find(thisRow) does not update live with personal sort and filters

I’ve gotten a live, personal RowIndex working using a column with the formula:

thisTable.Filter(FILTER HERE).sort(true,SORT HERE).Find(thisRow)
1 Like

Oh my :sweat: … Sorry, I completely missed your previous reply :pensive:

But I’m really glad to know that you’ve found a way to make it work :raised_hands: !

Hi! I see behavior in your doc that I’m not trying to fix. If my table lives on a different page than the view that I am interacting with, ObjectLink().OpenWindow() will open the record in the original table location, not the view.

Yes :blush: … As in this :

Table.Nth(thisRow.Index - 1).ObjectLink()

… returns the url of the previous row relative to thisRow and thisRow lives in the source table …

I honestly couldn’t find cleaner way to workaround this that what you’ll see in the sample below :innocent: (but maybe I’ve missed something somewhere :thinking: ), where :

In the table Table (which is my source table) I’ve reconstructed the url of each row depending on where they would need to be focused on (either the table Table or the connected view [View of Table]) using something looking like this:

E.g.: for [View of Table]

  [View of Table].ObjectLink().ToText(),
  thisRow.[Row ID]

And the formula in the field [Row ID] is this one :


(it returns the nice looking unique ID of thisRow)

And then, I’ve added a button (the purple one) which when pushed will set the focus on the previous row (depending on the value of its Index/visual position) in the connected view [View of Table] :blush: .

So its Action formula is this one:

  thisRow.Index != 1,
  thisTable.Nth(thisRow.Index - 1).[Row URL (View)].OpenWindow(),
1 Like

I love it so much, you are so helpful. Thank you very much.

Is there a formula that is “this view” so that I don’t have to make a URL column that has the view name hard coded in?

My pleasure @Nick_Solyom :grin: !

Not that I know of :thinking: … Not for this use case at least …

But you could also use a single select relation field to store the previous row relative to the visual position of thisRow and use that row to reconstruct the url OpenWindow() to set the focus where needed :blush:

This is the Action formula in the purple button :blush:

// Reconstruct the previous row url within [View of Table] and stores 
// its value within View_Prev_Row_Url
  [View of Table].ObjectLink().ToText(),
  thisRow.[Table (Index - 1)].RowId()
    thisRow.Index != 1,

(:information_source: WithName())

It’s working as intended, but with unintended consequences.
Here is a screen capture

My goal was to prevent the screen scroll position from jumping around when a user presses the done button.

  • If my done button does not end in an object link, the completed row does not automatically get filtered away until the user clicks somewhere

  • If my done button links to the view of the current table, the completed row DOES automatically get filtered, but my users lose their place because the windows scrolls to the top

  • If I calculate the previous RowID as we have been discussing, and then link to that, the window STILL scrolls, but moving the scroll position so the linked row is at the top.

It seems that I am no closer to my goal of the Done button automatically getting filtered away AND the scroll position staying put AND not requiring a click from my users.

Hi @Nick_Solyom :blush: !

The thing is that I understand the frustrating issue with the jumping around when marking the previous row as done but there’s not much more I can do about it as Coda controls how the filtered view behaves (and the scrolling… which I don’t know, might also depend on the browser you use) when a row is filtered out…

I mean, I can still try to mitigate the jumping around by sorting the view so the previous rows would stay in the same area of their “parent” rows, setting up the actions of the button a bit differently, calculate the index a bit differently, etc… (which I’ve done in the sample you’ll find below :blush: ), but I can’t change the fact that the row which will be focused on when the button is pushed might now appear as it if was at the top of the view :confused:

You could potentially limit how many rows can be mark as done in the view by disabling the button if the index is over a certain value or just making only 1 row always available so it would effectively be at the top of the table … But this depends on your specific doc setup and use case of course …