TYPE in Calligra Sheets: Identify value types and codes

• Introduced: Documented by 26.08.2; original introduction not established.
• Availability: Supported in Calligra Sheets 26.08.2, based on the function-specific registration.
• Scope: The official application listing provides Linux installation; other packaged builds are unverified here.
• Checked: October 14, 2026. Documentation/source check; no new native test in Calligra Sheets 26.08.2.

A column that looks like numbers may contain numbers, text values such as "0025", Boolean flags or errors. TYPE helps distinguish the categories before downstream arithmetic or searches. A formula that calculates 5 is a number for TYPE purposes even though its cell contains a formula. Conversely, a formula returning "5" is text. This is value classification, not formula provenance; use ISFORMULA for the latter.

The official handbook identifies five published code categories. The examined 26.08.2 func_type source also returns 0 when none of its recognized categories matches; that internal fallback is not a documented user-facing data category and requires native testing to establish any reachable worksheet example. Modern Microsoft Excel additionally documents code 128 for compound data; the pinned Calligra callback contains no such 128 branch, so don’t expect full feature parity for modern Excel data types.

=TYPE(x)

TYPE has one required argument and no optional type selector or default value. See KDE’s TYPE entry, 26.08.2 XML and C++ function. TYPE is not a way to decide whether a formula exists in a cell.

Use a new worksheet and enter the contents below in column A. A leading apostrophe is a common way of forcing a number-shaped string to remain text, but the exact input method varies; alternatively set the cell to Text format before entry. Enter =TYPE(A2) in B2 and fill it down.

For a direct independent formula check, =TYPE(25) is expected to return 1 and =TYPE("25") is expected to return 2. For dates and times, do not claim a universal code without testing how the installed build represents the value; the handbook’s date example suggests 1 for its sample but does not resolve all locale and format handling.

Advanced example: audit an import before calculations

Suppose A2:A100 holds mixed invoice identifiers. In B2 use:

=IF(TYPE(A2)=2;"Text ID";"Not text")

Fill down. SKU-025 (stored as text) should be labelled Text ID; a numeric 25 should be Not text. This distinguishes storage type, not whether an identifier should semantically be numeric. If leading zeros carry meaning, forcing an ID to a number can destroy information; retain text identifiers instead of coercing them unnecessarily.

Advanced example: inspect a calculation result, not the source formula

Enter A2 as =2+3, then evaluate =TYPE(A2) in B2. The expected type code is 1 because the result is 5. If the goal is to detect an accidentally overwritten formula, use ISFORMULA(A2) instead. A row may satisfy TYPE(A2)=1 regardless of whether 5 was typed or calculated.

Error and array branches: evidence does not equal runtime observation

At the callback level the 26.08.2 code includes if (args[0].isError()) return Value(16) and an earlier isArray() branch returning 64. That is source behavior, not proof that the formula evaluator delivers all errors and ranges to this callback without interception or scalarization. =TYPE(NA()), =TYPE(A1:A3) and array constants are useful future native test cases, but this guide does not assign them unconditional observed outputs. For errors, an evaluator may propagate the error earlier. For references, the handling of arrays/ranges depends on engine evaluation semantics, not merely callback type checks.

• Formula shown vs formula result: TYPE uses the evaluated value. Use ISFORMULA to inspect formula presence, not TYPE.
• 0025 returns 1 unexpectedly: It probably became a number when imported. Examine cell storage/text formatting and import options before applying TYPE.
• Text looking numeric returns 2: TYPE is not a numeric conversion function; text "25" remains text unless something converts it first.
• An error input behaves differently than code 16: The C++ has an error-value branch, but the surrounding evaluator may propagate an error before invoking TYPE. Mark such behavior pending native confirmation.
• Array/range gives surprising results: Range evaluation versus an internal array Value has not been native-tested. A 64 callback branch does not prove every range is treated as an array.
• Unexpected 0: The callback has a fallback 0 for internal values outside recognized categories. No common user-facing example of 0 was established; don’t interpret it as a new documented type.
• Different date, currency, Boolean, or decimal displays: Cell formatting is not always equivalent to underlying value type. Locale-specific rendering does not by itself change the TYPE category.

The current Microsoft Excel TYPE documentation lists the same five classic codes (1, 2, 4, 16, 64) and also 128 for compound data, including certain newer Excel data types. The examined Calligra 26.08.2 callback has no 128 branch. Therefore classic simple examples can transfer conceptually, but modern Excel compound types and error/array routing must not be presumed portable. The support page also says TYPE determines formula results, not formula existence. LibreOffice may share classic codes, but verify actual implementation and workbook migration behavior instead of treating the product names as interchangeable.

KDE TYPE entry, Calligra 26.08.2 XML contract, C++ TYPE branch, KDE release listing and Microsoft TYPE function were checked 2026-10-12. The live Calligra function index and software comparison page were accessible that day. Compare TYPE with ISFORMULA, ISNUMBER, ISTEXT and ISERROR to select the test appropriate to your task.