RadzenSpreadsheet: typed/pasted cell input ignores the cell's own NumberFormat (Text format doesn't prevent number/date inference)

Radzen.Blazor Components
1

Version: Radzen.Blazor 11.2.8 (also checked 11.4.2 — same behavior for this specific issue)

Component: RadzenSpreadsheet

Summary:

When a cell has Format.NumberFormat = "@" (Text) set, typing or pasting a value like 0071, 123., or 12/34 directly into that cell still gets number/date-inferred and loses the leading zero / trailing character — exactly as if no format were set at all. This differs from Excel's own behavior, where a Text-formatted column keeps typed input as literal text with no extra step needed.

Root cause (traced through source):

Cell.SetValue(string) decides how to store a typed/pasted value using only the string's own content:

  • If it starts with ' → forced to literal text (CellData.FromString), no parsing.
  • If it starts with = → treated as a formula.
  • Otherwise → passed to the Value setter → new CellData(value, culture) → Infer() / TryConvertFromString(), which tries number → date → bool → text, in that order.

At no point does this path read cell.Format/NumberFormat. So a Text-formatted cell and an unformatted cell behave identically for fresh input — the format only affects how an already-stored value is displayed (CellView.razor's GetDisplayValue()), never how new input is parsed.

Repro:

  1. Set a cell's Format to NumberFormat = "@".
  2. Click the cell and type 0071 (no leading apostrophe).
  3. Cell shows 71, Cell.ValueType is Number — same as if the format were never set.

What we tried as a workaround:

A custom SpreadsheetCellType (via RadzenSpreadsheet.CellTypes) with a custom editor that forces Context.CommitAsync("'" + typedText) on commit — this does work, but only after reverse-engineering several undocumented internal contracts:

  • The editor's root element must be contenteditable and carry the exact class rz-spreadsheet-editor-input — this is required for Spreadsheet.onFocusIn's buffered-keystroke flush (for the "click a cell and start typing before F2/double-click" case) to target it at all; a plain <input> silently drops those keystrokes.
  • The material theme sets .rz-spreadsheet-editor-input { color: rgba(0,0,0,0) } (fully transparent), expecting a separate .rz-spreadsheet-editor-highlight overlay to do the actual visible rendering — a custom editor without that overlay needs its own color override or the typed text is invisible.
  • Spreadsheet.onKeyDown's global handler calls Editor.StartEdit(address, key) for every printable keystroke whenever isGridContext is true — which is also true while focus is inside the editor itself — repeatedly stomping the shared Editor.Value. A custom editor has to stop propagation on ordinary editing keys at the element level to avoid this, which also incidentally works around Backspace/Delete being intercepted by the grid's own shortcut handling.

This worked but felt like it was fighting the framework rather than using a supported extension point, and cost several rounds of debugging to get right.

Question:

Is there a supported, simpler way to make cell input respect Format.NumberFormat (specifically "@"/Text) the way Excel itself does — either built into Cell.SetValue, or via some documented hook we're missing? If a custom cell type really is the intended mechanism for this, would it be possible to document the class/CSS pairing and the isGridContext/keydown behavior above, since neither is currently documented and both are easy to get wrong in a way that silently breaks (invisible text, dropped keystrokes) rather than erroring?

Happy to share a minimal repro project if useful.

2

Hi @teninfotech,

We decided to handle this in the library itself, so no custom cell type or editor is needed. Cell.SetValue now respects the cell's number format: in a cell with the Text format ("@"), input like 0071, 123., 12/34 or =1+1 is stored as literal text. This covers typing in the cell, the formula bar, pasting from other applications, and custom editors that commit through Context.CommitAsync. As in Excel, a leading apostrophe is still stripped. Custom text formats such as "ID-"@ are also treated as Text.

The fix is in master (Keep typed and pasted RadzenSpreadsheet input as literal text in cell… · radzenhq/radzen-blazor@cf9ea8d · GitHub) and will ship with the next Radzen.Blazor release later this week. After updating, you can remove your custom cell type and just set Format.NumberFormat = "@".

As for the customer editor gotchas - we will research in the future how to avoid them altogether so no documentation is needed.