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! 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.
… 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 (but maybe I’ve missed something somewhere ), 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]
Format(
"{1}/r{2}",
[View of Table].ObjectLink().ToText(),
thisRow.[Row ID]
)
And the formula in the field [Row ID] is this one :
thisRow.RowId()
(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] .
Not that I know of … 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
This is the Action formula in the purple button
// Reconstruct the previous row url within [View of Table] and stores
// its value within View_Prev_Row_Url
Format(
"{1}/r{2}",
[View of Table].ObjectLink().ToText(),
thisRow.[Table (Index - 1)].RowId()
).WithName(View_Prev_Row_Url,
If(
thisRow.Index != 1,
View_Prev_Row_Url.OpenWindow(),
""
)
)
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.
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 ), 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 …
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 …
!
…
… Sorry, I completely missed your previous reply 
…
!
), where :
!
…