Handling "Blank" selection in a canvas formula

In a canvas, I would like to display formatted text based on the value of a Select list. If nothing is selected, there’s no values to pass to the formatted text formula, so I’d like to short-circuit that logic and display a simple message (or nothing) instead.

I’ve tried If() and SwitchIf() functions to test for blank/no selection, but instead of getting the expected result, I get an error on the “nope, it’s not blank” branch … even though that shouldn’t apply.

This isn’t making much sense. Here, I show you a picture:

When no option is selected, the dynamic text should say “No option selected.” Instead, I get an “Unexpected dot error” because the Blank selection (obviously) doesn’t have a Name property.

How can I gracefully handle “Blank”?

1 Like

Weird indeed.

It’s not a problem with your condition (a simpler formula like If(Selection.isBlank(),"yes","no") works just fine).

I would also have expected this short circuiting to work.

I think this is a bug.

1 Like

I’m not super happy with this solution, but it’s a solution: grab a table row that matches Selection (it’s redundant, but it mitigates the type error)

    "No option selected",
    Format("{1} {2} would weigh {3}kg.",
      RandomInteger(2, 50),
      RandomInteger(1, 50  ) * SelectedRow.Weight
1 Like

@Nick_HE, I had definitely considered that approach, but (like you) it made me so unhappy I desperately hoped I was just doing something wrong.

I’m sorry you had to experience the uncomfortable next step of actually writing out that distasteful workaround, but I’m also grateful because now I can just duplicate your formula instead of creating it myself.

Sympathy and appreciation,


Hey @Brian_James_Lewis, welcome to the Community!

Both you and @Nick_HE are missing one thing: you’re using a Select control whereas you should be using Lookup instead:

It’s not a bug. Select is a generic any-list control that’s not strongly typed. Yeah, you can make it a selection of rows like you did, but Blank will still be untyped. If the value’s a selected row, Options.Column will gracefully resolve but when the value is Blank, there’s no way for Coda to know it’s still a value from an Options table and it should have that Column column.

Lookup, however, is strictly typed to a specified table. So even when the value is blank, Coda Formula Language treats the references right and won’t invalidate the formula.

For answer completeness, if you absolutely must go with Select (e.g. you want to formulaicly construct a selection list that’s a union of multiple tables), you can replace Value.Column with _Deref(Value, ExpectedTable.Column). This is a hidden formula for trying to read a Column from a Value assuming it’s a row from ExpectedTable, or return blank if it’s not. It won’t crash the formula.


D’oh! Yup.

And thanks for the dereferencing tip, that could be handy in other places too.

Thanks, Paul, that clarification helped a lot.

I was working from a community template that uses a Select control … and I see that it should also have been a Lookup.

They only added the separate Lookup control sometime last year. The template could’ve been older than that and they could’ve just forgotten to update it.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.