# RadzenSpreadsheet: typed/pasted cell input ignores the cell's own NumberFormat (Text format doesn't prevent number/date inference) **URL:** \ **Category:** Radzen.Blazor Components\ **Created:** [September 23, 2026, 10:42am UTC](https://forum.radzen.com/t/radzenspreadsheet-typed-pasted-cell-input-ignores-the-cells-own-numberformat-text-format-doesnt-prevent-number-date-inference/21713 "2026-09-23T10:42:47Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![teninfotech](https://forum.radzen.com/user_avatar/forum.radzen.com/teninfotech/32/22974_2.png) [@teninfotech](https://forum.radzen.com/u/teninfotech)\ **Post date:** [September 23, 2026, 10:42am UTC](https://forum.radzen.com/t/radzenspreadsheet-typed-pasted-cell-input-ignores-the-cells-own-numberformat-text-format-doesnt-prevent-number-date-inference/21713/1 "2026-09-23T10:42:47Z")
**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 `` 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. ---
**Author:** ![korchev](https://forum.radzen.com/user_avatar/forum.radzen.com/korchev/32/4_2.png) [@korchev](https://forum.radzen.com/u/korchev)\ **Post date:** [September 23, 2026, 12:00pm UTC](https://forum.radzen.com/t/radzenspreadsheet-typed-pasted-cell-input-ignores-the-cells-own-numberformat-text-format-doesnt-prevent-number-date-inference/21713/2 "2026-09-23T12:00:51Z")
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](https://github.com/radzenhq/radzen-blazor/commit/cf9ea8de5)) 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.