CELL

What it does

CELL(info_type, [reference])

CELL(info_type, [reference]) returns one property of a cell, selected by name.

Microsoft's published info_type table, verbatim:

Several of these — "color", "parentheses", "prefix", and much of "format" — are survivals from Lotus 1-2-3 compatibility and from Excel's macro-sheet era. They still answer, but they describe a formatting world that modern workbooks mostly do not use.

Arguments

info_type — required. Text naming the property. It is coerced to text and matched case-insensitively after trimming, so "ROW", "row" and " Row " are the same request. A name outside the twelve is a failure, not a null result.

reference — optional, and this is the argument position most commonly misunderstood. Microsoft's own caveat is worth quoting because it is unusually blunt for a reference page: "Although technically reference is optional, including it in your formula is encouraged, unless you understand the effect its absence has on your formula result."

What its absence does: CELL falls back to the last cell that was changed, which is a piece of application state, not a property of the formula. The documented consequences are that calculation timing varies by platform, that co-authoring can report the wrong active cell, and that a plain recalculation (F9) can produce a new result with no edit anywhere. That is why the function's declared volatility is VolatileContextual and its thread-safety class is HostSerialized: an argument-free CELL is a formula whose answer depends on what the user did last.

Supply the reference. There is no case in which omitting it makes a formula more correct.

Note also that reference is a reference position, not a value position: the live reference survives argument preparation, which is what lets "address" and "row" mean anything. Handing CELL a computed value where a reference is expected is a failure, not a coercion.

Try it

Quirks

Result and edge cases

The return kind depends on info_type: Text for "address", "filename", "format", "prefix" and "type"; Number for "col", "row", "color", "parentheses" and "protect"; whatever the cell holds for "contents"; and an array of two items for "width" — the only info_type whose result is not a scalar, and a shape that will spill or be intersected depending on context.

• A multi-cell reference is reduced. "address" reports the first cell, "contents" the upper-left. CELL does not aggregate.
• "contents" returns the value, never the formula. FORMULATEXT is the function for the formula text.
• "filename" on an unsaved workbook has a documented-empty answer in the folklore and no observation in this Handbook.
• "type" is coarse. It reports a one-letter classification of the cell's content, not the fine-grained kind that TYPE returns. The two functions have similar names and different jobs; see "Relationships".
• "format" is locale- and version-sensitive. The text codes describe number formats, and which code a given format maps to is a per-build fact this Handbook has not recorded.
• Volatility. With reference supplied the function is still declared VolatileContextual — the properties it reads (format, width, protection) can change without any formula input changing, and Excel's dependency graph does not track formatting edits the way it tracks values. A CELL("format", A1) result can therefore be stale after a formatting change until a recalculation happens.

Errors

Microsoft's page is the documentation of record; the Handbook has read its info_type table and its reference-argument caveat, and does not have a documented error table for this function to reproduce.

• an unrecognised info_type — #VALUE!
• a reference argument that is not a reference — #VALUE!
• an arity failure (zero arguments, or three) — #VALUE!
• no host available — the call is refused rather than answered

#REF! from a deleted target and #NAME? from an unresolvable name would arise before CELL runs, in reference resolution (coercion and lifting).

How to implement

Notes for implementers

1. CELL cannot be implemented in the function layer. It must be a declared host query with a defined failure mode when no host is present. Faking "filename" or "format" from local state produces answers that look right and are not.
2. The reference must survive preparation unresolved. If the dispatch layer dereferences, "address", "row", "col" and "width" all lose their subject.
3. The omitted-reference path is a different query, against application state (last changed cell), not against an argument. It should be modelled as such, and its non-determinism documented rather than smoothed over.
4. "width" returns an array of two. A scalar-shaped return path will silently drop half the answer.
5. "format" and "prefix" are locale- and version-scoped. Any claim about their outputs must name the build and locale, per the Handbook's claim rules.

Rust code

1 cell_fn "CELL" (1, 2) [V "info_type", F "reference"] |s, a, sv| { cell(s, a, sv) }

No implementation has been published with a Handbook test suite for this function.

Version differences

No comparison between specific Excel builds is recorded here yet. This does not establish that all builds behave alike.

Alternatives

Relationships

• INFO is CELL's sibling: same category, same host dependence, same "cannot be evaluated without Excel" property, but asking about the environment rather than about a cell.
• TYPE and CELL("type", …) are not the same function and do not return the same alphabet. TYPE returns a numeric kind code for a value; CELL("type", …) returns a one-letter classification of a cell. If you want to know what kind of value you have, use TYPE.
• ROW and COLUMN give the same numbers as CELL("row", …) and CELL("col", …), without the host-query machinery, and are the better choice.
• ADDRESS builds an address from coordinates; CELL("address", …) reads one from a reference. They meet in the middle.
• SHEET and SHEETS answer the sheet-level questions CELL does not.
• ISFORMULA and FORMULATEXT answer the formula questions CELL("contents") and CELL("type") cannot.
• CELL("filename", …) is the traditional route to the workbook or sheet name, usually wrapped in MID/FIND. It is fragile — it depends on the file having been saved and on the path's punctuation — and it is the reason many workbooks break when moved.

Named variants

No named variants are recorded yet.