REGISTER.ID

What it does

REGISTER.ID(module_text, procedure, [type_text])

REGISTER.ID is the other half of Excel's native-code seam. Where CALL invokes, REGISTER.ID binds: it associates a DLL, an entry point and a type signature, and returns an opaque token standing for that binding. It is the only piece of the XLL registration machinery that Microsoft documents as usable from an ordinary worksheet.

Two operations behind one name, and the distinction is the whole function:

1. If the procedure is not yet registered, REGISTER.ID registers it and returns the new register id.
2. If it is already registered, REGISTER.ID returns the existing id.

That is why type_text is optional. Microsoft states it directly: "If the function or code resource is already registered, you can omit this argument." So a two-argument call is a pure lookup, and a three-argument call is register-or-lookup. A workbook can therefore call REGISTER.ID repeatedly without accumulating registrations — it is idempotent in effect, which is what makes it safe to put in a cell that recalculates.

The id itself is opaque and session-scoped. It is not a stable identifier: nothing guarantees the same value across sessions, machines, or Excel builds. A workbook that saves an id and reuses it later is relying on something no documentation promises.

REGISTER.ID is also the narrower of the two registration functions. Microsoft draws the line explicitly: "REGISTER.ID can be used on worksheets (unlike REGISTER), but you cannot specify a function name and argument names with REGISTER.ID." So the trade is worksheet availability in exchange for the ability to publish the procedure under a name in Excel's function list. REGISTER.ID binds for CALL's benefit; REGISTER binds for the user interface's benefit.

Arguments

REGISTER.ID(module_text, procedure, [type_text]) — arity 2 to 3, matching the reference engine's recorded arity.

• module_text (required) — text naming the DLL that contains the function, in Excel for Windows. Resolution follows the operating system's library search, so which file this names is a property of the machine, not of the workbook.
• procedure (required) — text naming the function in the DLL. Microsoft adds that "you can also use the ordinal value of the function from the EXPORTS statement in the module-definition file (.DEF)". Two kinds of value, one argument slot — the same overload CALL carries, and the same source of confusion.
• type_text (optional) — text specifying the data type of the return value and of all arguments, with the first letter specifying the return value. Omissible only when the procedure is already registered.

Microsoft also notes that REGISTER.ID "has a slightly different syntax for each operating environment", distinguishing Windows and Macintosh. The Handbook has not characterized the non-Windows form.

The misunderstood position is type_text. It is not a description of the function for Excel's benefit — it is the marshalling contract, and it is the reason the seam is dangerous. Because the caller writes it as a string with nothing checking it against the DLL, a wrong type_text is a memory-safety problem rather than a worksheet error. That risk belongs to the seam as a whole and is set out on the CALL page; it applies from the moment registration happens, not only at invocation.

Try it

This Excel interface needs a host library. OneCalc cannot load a native library in this preview.

Quirks

Result and edge cases

A register id — an opaque value whose only documented use is as CALL's first argument. The Handbook has not characterized its value kind beyond "something a formula can hold and pass along"; it should be treated as a token, not as a number to compute with.

The interesting edges are all about when the binding exists:

• Session scope. Registration state belongs to the Excel session. What a saved workbook holds is the last computed value, not a live binding.
• Recalculation. The function is recorded as NonVolatile, so it is not re-evaluated on every calculation; whether the id it returns remains valid across a session in which the DLL is unloaded is not documented.
• UNREGISTER. The teardown counterpart exists as a macro-sheet function. What a previously returned id does after its registration is torn down is not documented.

Errors

Microsoft's REGISTER.ID page documents no error-value table. As with CALL, that absence is substantive rather than accidental: the interesting failures — a DLL that will not load, an entry point that is absent, a signature that does not match — are operating-system and loader-level events, and the documentation does not map them onto worksheet error values.

The Handbook does not know what a missing DLL or a missing entry point returns. That is stated as an unknown, not filled in by analogy.

How to implement

Notes for implementers

• The register-or-lookup duality is the specification. An implementation that always registers will leak bindings across recalculations; one that only looks up cannot bootstrap.
• The id must be opaque and must not be assumed stable. Any implementation that returns, say, a hash of the arguments is offering a stability guarantee Excel does not make — and workbooks will come to depend on it.
• type_text's code set is C API vocabulary, not worksheet vocabulary. It must be reproduced, not redesigned. This is shared with CALL; the two functions must agree exactly, since a binding made by one is consumed by the other.
• The ValuesOnlyPreAdapter classification (unlike CALL's RefsVisibleInAdapter) means registration takes plain values only, which is consistent with all three arguments being strings. See the call pipeline for what the two profiles mean.
• Registration mutates host state. HostSerialized is the right classification, and any engine running formulas in parallel must respect it.

Rust code

This entry has no Rust implementation yet.

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

• CALL — the consumer of the id and the other member of call_register_id_family. The two functions are one mechanism split across two names, and neither page is complete without the other.
• REGISTER — the macro-sheet-only registration function that can also publish a function name and argument names into Excel's user interface. Microsoft contrasts the two explicitly, as quoted above. It is not part of this Handbook's worksheet-function catalog.
• UNREGISTER — the teardown counterpart, likewise macro-sheet-only.
• XLL add-ins — every function an XLL publishes goes through the same C API registration path. REGISTER.ID is that path exposed as a formula, minus the naming.
• EUROCONVERT — a category-mate under "User defined functions that are installed with add-ins", but a computation rather than a seam.

Named variants

No named variants are recorded yet.