Good morning,
Could you put alternate row shading for tables on the wishlist - it would improve the readability of wide tables a lot. I have looked at the possibility of doing this with conditional formatting, but that only works if we can get a function to get the position of a row in all the visible rows (after sorting, filtering, etc.).
Greetings,
Joost
You can obtain a column with numbers that are from let’s say one to last row with a new column that have a formula that see where thisrow is is thattable, and conditional format it for odd and even number 
If you need help to build that formula i can help, as you know external sorting and filter must be taken into account, but it can be done
But i agree that a build in feature would be great!
Have a nice making 
Mario
Hello Mario,
The subject of row numbering has been addressed in this forum before - the conclusion is that whatever function you use (rank, rowid or anything else you can think of), will not give you a sequentially numbered list without gaps after filtering or sorting - we have tried many times to do so.
But please, prove me wrong. Sort the sample on column 1 or 2, or filter a couple of numbers of letters, and see what happens to the shading. I’m looking forward to any reasonable workaround.
You can edit this sample document
Hey! Take a look at this approach:
Hello @Paul_Danyliuk,
Thank you for guiding me to this very clever example. It works, but it requires a lot of overhead and one has to prepare a table properly. I added some rows and it keeps on working, but as soon as I filter something out, it breaks:
Not to be stubborn (although I guess I am), but these type of work arounds to get something that is pretty much industry standard are only practical if you really really need it and you know ahead of time how the table is going to be used.
But in some situations this will certainly work.
Greetings,
Joost
For filters I do pretty much the same:
I agree that it’s workarounds, but on the other hand I advocate to build docs in such way that end users NEVER have to tweak table settings themselves. Instead it’s your responsibility as a doc builder to only surface the controls they should be able to tweak (by making canvas controls, these helper tables etc) and wire everything together. End users should not figure out that they have to go into table settings (which are hidden and not surfaced as UI elements), it should be obvious what they can or cannot change.
And when you’re in charge of all settings, you can as well add this workaround logic to your tables.
Yes, I agree with that…for the most part. I am not against workarounds, especially for special situations. But if often used, I would prefer it as an option, rather then adding extra columns. As far as issues go, yes. My pages are locked anyway, but a lot of tables are just for me and I like the shading for ready viewing most of tables, including ad hoc filters and sorting.
Who knows, maybe my request (and a couple of likes) will give it a bit of priority.
I totally agree with @joost_mineur
Most of my docs are for my own use as an ad-hoc “workspaces” for working on my data - Coda makes lots of data manipulation tasks much easier then excel - and alternate shading would be very helpful in some cases.
@shishir had a great explanation of how to make this happen and includes an example here…
@joost_mineur, you’re right that some of these things require workarounds and would be really nice to have as easy native features. We keep an eye out for these and are looking to make more things easier as the product grows.
P.S. @joost_mineur I just remembered that you can simply use a view and then find the row’s position within that filtered view. When you reference a view in your formula, it already comes pre-filtered, so the visual position will be correct.
It won’t respect the view’s sorting or grouping though; those are applied not at the dataset level but at presentation level.
It would be useful to have a table/view current presentation object (CurrentPresentation) exposed in the formula editor.
The context of CurrentPresentation could be either the view name (for calcs outside of the view) or thisView (for calcs within the view) – thus it could be different on each of the many different views of a table. It could hold the current modifications to the table/view list of rows (sort, filter, group, etc).
thisView.CurrentPresentation.Find(thisRow).IsOdd() → blue
thisView.CurrentPresentation.Find(thisRow).IsEven() → grey
MANY use cases would be made trivial by storing view presentation configurations in an object accessible via formula.
I’m constantly having to replicate the presentation configuration of a given view into a variable some place in order to do something. But it’s painful because it’s not linked to the actual configuration held by the view itself – so if the actual configuration changes, it breaks the functionality built on the hard-coded replication.
This is a ubiquitous design pattern for me, and I’m sure it would be for many others also, if it required less overhead to set up and maintain.
EDIT
It could hold the current modifications to the table/view list of rows (sort, filter, group, etc).
This list could just be a property on each table/view.
i’m pretty sure i can find a way to make it working!
Is this still needed?
@Mario: yes I would use it on many tables if it can be setup without the help of 2 or more helper columns. Some of my tables are pretty big, so I don’t want to add to much overhead. For smaller tables I don’t mind the overhead, but it should not be too complex: most of it is just for my own convenience.
To be honest: I still think this should be build into Coda, because it is very hard to get a grip on the row number of all visible rows. Coda has a way of doing it, because no matter what your data manipulation is, you will see a sequential row number on the left of your table when you hoover your mouse over the table. If we can get programmatic access to that number we are all set.
Looking forward to new insights in this matter - just reading through all the other postings related to this subject has taught me quite a couple of tricks
This use case is a good example of why it would be useful to be able to access a property on a table or view that holds its current configuration (filter, sort, group).
