For referencing fields belonging to
[thisRow]) within a canvas cell within a template table, another simple solution is to simply write the formula as text (or you can write it in one of the “real” table (eg meeting table) then copy-paste the formula into the template table. Coda automatically recognizes the formula chips once the template makes it into the destination table.
Of course the downside of this is if a column changes it’s name, the formula in the template will break. Plus the red underline feels wrong… but it’s a quick and easy hack.
It strikes me that there are three classes of scenarios where you might want to reference data from canvas cells:
- a repeated formula for every row
- a one-off formula in just one (or a few) canvas cells
- a repeated formula, but some exceptions where the formula is a bit different
For (1), I think 99% of the time it is best just to have that formula as a column formula, since it’s repeated for every row (and if the formula references a table, then that table should also be a column formula).
For (2), the formula should simply be a named formula and then referenced by name wherever that value is needed.
For (3)… this one is trickier, and here I think @Nikola_Lajic’s hack might come in handy. In many cases though, I think it would be worth it (simpler at least) to have an entire canvas column just for that one formula, and refraining from adding extra data in there. Con: fragile, requires user restraint.
I came for this as well. I’ve run into this issue several times and inability to print a row (as it appears when opened to fill screen) is a barrier to moving forward with my preferred implementation.
For context, I’m using canvas column as a policy template and want the user to be able to print.
Other print formatting options would be great too - anything that would easier export to a Google doc or similar.
Thanks for these examples, @Kelsey_Chan, for those use cases, where we do not want a user to set the filter within the canvas cell themselves (ie where we want to auto-filter based on parentrow).
As I was working through the methodology of this, I created a step-by-step guide. I’m sharing the doc below, in case it’s helpful to others.
All the best from Austria,
it is a clever set up @Nina_Ledid , the creation of a page that is referenced in the canvas column in a kind of helper table permits for quite a bit of intelligent nesting since the filtering is activated on that level, you don’t have to set it right in and for each row you work in. I like that mechanism a lot. Designing and maintaining these solutions is a challenge in itself, proper documentation is key and you showed a great example of how to do that!
well done indeed on two levels;
- the trick itself is genius and so very useful!
- you have explained how to do it - and how it works - so clearly
Can we paste images into table cells using this?
This is exactly what I was looking for. My question (which very well could something else to tackle entirely), is there a way to populate a table within that Project template with a table of prefilled tasks?
What I’m attempting to do is create a new project that has a preset list of tasks that will have this filter function (the one you’ve demonstrated) applied. The point is to avoid having to re-enter (or copy/paste) the same tasks we use in every project. Essentially a filtered template of tasks in the template.
Absolutely, there is. Like with anything in Coda, there’s more than one route to achieve one’s goal
Personally, I’d do it like this:
- Create a separate table, called “Tasks that need to be done for every new project” (abbreviated CommonTasks for the purpose of this post).
- Set up an automation (or button, if you’d prefer), so that whenever you add a new project to the projects table, it will automatically add the rows of the table CommonTasks to the AllTasks table, while assigning the new project name to these tasks.
- That way, they will show up in the filtered view in the canvas cell, where the filter is set to the parentrow (ie Project Name).
Hope this helps! Nina
you hit the nail on the head
i use a similar pattern myself
just to add…
this works best using a BUTTON to add a new project as automations can lag a bit (i think they run on the server?)
so we have adopted a rule; always put an
Add New Row button on every table and hide the little ‘+’ button below the table. that way we always have a place to put the logic for adding new customers, products, projects etc, etc.
and by doing this for every table, we train our users to use the button every time.
it also facilitates popping up a form-like dialog for them to input the required data.
and locking the page to prevent adding new rows means we are confident (ish) that nobody sneaks past this logic
Yes! Nina and Max, that’s exactly what I’m looking for. However, being a bit new Coda’s buttons and automations, is there any guidance (explanation, article reference, video) that might help out. I’ve tried utilizing what I know about buttons and automations, but I’m missing something.
I’m currently using the method you described in Canvas cell with auto-filtering.
Feel free to share the doc with the changes you made, and I’ll take a look!
That’s an interesting approach, thanks for sharing! I like your concept of narrowing down a new user’s possibilities, in order to “keep them on the right track”
No problem. And thanks again for your help. Also note, there are some tasks in the project that I’ve copied and pasted.
Rebuilding Project Space
@Kelsey_Chan Hi there! Loving the Canvas Column. That said, I’ve been testing the limits of this new feature and ran into a problem I was hoping you might help me solve. When I refer to one canvas column inside another via formula, any buttons that were used in the original column become inactive. Is there any workaround for this? It seems like an unintuitive limitation.
Hi, @TSStrickand1! Do you have an example doc you can share?
I recently built a doc that uses a template for a canvas cell and I just created it on the actual first row of data, instead of building it outside the table – that makes it easier.
After a few iterations I had to change the template for the new entries, then is just a matter of changing the first row of the table, so it reflects on the new ones created over it.
It has a downside, though… if you need to change the data on this template (which is a view of another one, in my case), you must do it manually, one-by-one, on theses canvas cells.
Still it is a nice little feature, and the parentRow object opens up a lot of possibilities.
Here is a use case that I can’t currently implement because of the Toggle Preview setting on a canvas field type. In some views, I’d like to collapse the Canvas field so that I just see an ‘Open’ preview button.
On other views of the same data, I’d like to not collapse the data, and be able to see all of the information. But the Canvas option display preview toggle applies globally in the doc, and so I don’t have the View specific control to see or not see the data.
To chime in here, for the same reason I would also like the same thing for text-wrapping. Some views need to be compact but still show a preview of the text data, and other views of that data I would like to show the whole text value without clicking in.
Curious if anyone else has had performance issues with this pack. I’m finding that adding a QR code column to a table with a couple hundred entries is still “syncing” with no QR codes actually propagating after at least 10 minutes of thumb twiddling. I don’t think its unreasonable to expect better performance than that. Am I missing something?