Contact

PlanMaker DEC2HEX: Signed 32-Bit Conversion and Examples

Number Conversion Intermediate SoftMaker PlanMaker

DEC2HEX converts decimal input to hexadecimal. PlanMaker documents a signed 32-bit domain and two's-complement negative values. The represented quantity and the written numeral are different things; preserve the source and its sign convention when converting.

Verification status: See the evidence and test scope described in this guide. How formula examples are checked

DEC2HEX converts decimal input to hexadecimal. PlanMaker documents a signed 32-bit domain and two’s-complement negative values. The represented quantity and the written numeral are different things; preserve the source and its sign convention when converting.

Availability and evidence

The PlanMaker 2026 reference, 2024 reference and 2021 reference were retrieved and read on October 15, 2026. These establish documented support in those manual families, not the original introduction or a last-working-version endpoint. Both historical endpoints remain unverified. Specific FreeOffice/mobile editions and every desktop build are outside the checked scope.

No native PlanMaker execution, screenshot or file transfer was performed. The expectations below are independently checked integer encodings consistent with the documentation. English formulas use commas; localized separators and function names require checking in the installed build.

Exact syntax and input domain

=DEC2HEX(Number [, Digits])

Number is required. The documented signed domain is −2^31 through 2^31−1, or −2,147,483,648 through 2,147,483,647. The binary/hexadecimal/octal strings for negative values encode the 32-bit two’s-complement word, rather than an ordinary minus-prefixed numeral.

The input column contains numeric decimal integers. The reference explicitly describes the converted output as text, even when it contains only digits. Keep the original numeric column for sums and comparisons. The documented truncation of Digits does not establish how a fractional Number is treated.

Digits controls output width

Digits is optional. When omitted, PlanMaker determines the required width. It must be greater than zero; fractional Digits are truncated rather than rounded. A positive input whose significant representation is wider than Digits gives #NUM!, as shown in the vendor examples.

For a negative value the 32-bit representation is used and Digits is ignored. The examples use ordinary positive width requests when checking that rule; they do not settle validation precedence for a simultaneously invalid width. Number’s numeric value and Digits’ display requirement remain separate.

Complete reproducible worksheet

Create BaseControls with Source in A1 and Converted in B1, Width_12 in C1. Enter the numeric A inputs below. Fill B2 =DEC2HEX(A2) through B7. Fill C2 =DEC2HEX(A2,12) through C7.

Row A: source Expected B Expected C
2 0 0 000000000000
3 1 1 000000000001
4 42 2A 00000000002A
5 255 FF 0000000000FF
6 1023 3FF 0000000003FF
7 -42 FFFFFFD6 FFFFFFD6

In a copy change A4 from 42 to 43. B4 becomes 2B, and C4 becomes 00000000002B. Only that input row changes.

Reproduce the width and negative-number examples

SoftMaker gives =DEC2HEX(42) as 2A and =DEC2HEX(42,8) as 0000002A. A one-place request cannot hold two significant digits, so =DEC2HEX(42,1) gives the documented #NUM! error.

For −42, the result is FFFFFFD6, the eight-hex-digit representation of its 32-bit two’s-complement pattern. A positive width request such as 2 or 12 is ignored for that negative input. Neither a literal minus sign nor extra left zeroes are the documented negative convention.

Advanced: format a specified RGB triplet

Create RGBText and enter numeric 34,139,230 in F2:H2. In F3 use =DEC2HEX(F2,2) and fill right through H3. The expected strings are 22,8B,E6. I3 ="#"&F3&G3&H3 produces #228BE6.

A separate application rule limits each channel to integers from 0 through 255; the function’s signed 32-bit domain is much larger and does not enforce that policy. The two-character width matters: a channel value 7 should produce 07, preserving the fixed two-position field.

Change F2 from 34 to 35 in a copy. F3 becomes 23, and I3 becomes #238BE6. The other two channels stay unchanged. The conversion only formats the supplied values; it does not calibrate a display or establish a color-space interpretation.

Advanced: audit signed word endpoints

The independent 32-bit controls are =DEC2HEX(2147483647) → 7FFFFFFF, =DEC2HEX(-2147483648) → 80000000, and =DEC2HEX(-1) → FFFFFFFF. They illustrate why a high leading hex digit can mark a negative signed word.

A matching inverse such as =HEX2DEC("FFFFFFD6") returns −42 under PlanMaker’s documented interpretation. This is a mathematical/documentary round trip, not evidence that a native file export preserved the string or that an external program uses the same signed width.

Keep original numeric inputs, display widths and the destination’s data-format specification separate. A correct hexadecimal encoding is not itself a proof that a source identifier, color channel or register value is valid for its intended application.

A documented fractional-width control

=DEC2HEX(42,8.9) has independently expected output 0000002A because the documented Digits truncation gives width 8. This is a width example, not evidence for truncating a fractional source Number. Keep an explicit integer width in routine formulas for readability.

Errors and verification limits

Respect the documented signed range and source base. The short reference does not give a complete native error/coercion matrix for malformed strings, prefixes, blanks, Boolean values, arrays or fractional Number inputs. No exact error token is invented for those cases. A source with too many bits or an invalid digit is outside the documented contract even when its intended meaning seems obvious.

Before reuse, record the exact PlanMaker build, edition, platform, language and workbook format. Recreate the original cells, inspect whether source text survived entry, and apply each changed-input control separately. Test saving and the receiving application’s interpretation independently; neither follows from a correct mathematical encoding.