MRMREGISTERNAMESINHIERARCHY(3)

💖 MrmRegisterNamesInHierarchy — the library call bestie 💖

okay so this is a page from the library call manual, and we're gonna talk about MrmRegisterNamesInHierarchy. Yes the whole name. Yes it's long. We're getting through it together, hand in hand 🫶

---

✨ NAME ✨

MrmRegisterNamesInHierarchy — registers the values associated with the names referenced in UIL within a single hierarchy (for example, UIL callback function names or UIL identifier names)

like… it's the "these names mean THESE things, but only in THIS hierarchy" girlie 💅

---

🌸 SYNOPSIS 🌸

#include <Mrm/MrmPublic.h>
Cardinal MrmRegisterNamesInHierarchy(
MrmHierarchy hierarchy_id,
MrmRegisterArglist register_list,
MrmCount register_count);

copy it exactly bestie, don't freestyle the signature 😭

---

🦋 DESCRIPTION 🦋

So MrmRegisterNamesInHierarchy registers a vector of names and associated values for access in MRM. Those values can be callback functions, pointers to user-defined data, or honestly any other values. The info you hand over is what gets used to resolve symbolic references occurring in UID files into their run-time values. For callbacks, this information provides the procedure address required by the Motif Toolkit. For names used as identifiers in UIL, this information provides whatever run-time mapping the application needs. it's giving "glue between your UIL and your actual code" ✨

This function is similar to MrmRegisterNames, except that the scope of the names registered by MrmRegisterNamesInHierarchy is limited to the hierarchy specified by hierarchy_id, whereas the names registered by MrmRegisterNames have global scope. When MRM looks up a name, it first tries to find the name among those registered for the given hierarchy. If that lookup fails, it tries to find the name among those registered globally. so hierarchy first, global as the backup plan, no cap 💜

• hierarchy_id — specifies the hierarchy with which the names are to be associated. the one and only home for these names 🏠
• register_list — specifies a list of name/value pairs for the names to be registered. Each name is a case-sensitive, NULL-terminated ASCII string. Each value is a 32-bit quantity, interpreted as a procedure address if the name is a callback function, and uninterpreted otherwise. 32 bits!! note it!! 📝
• register_count — specifies the number of entries in register_list.

The names in the list are case-sensitive. The list can be either ordered or unordered. she's flexible, she's chill, she does not care about your ordering 🌸

Callback functions registered through MrmRegisterNamesInHierarchy can be either regular or creation callbacks. Regular callbacks have declarations determined by Motif Toolkit and user requirements. Creation callbacks have the same format as any other callback:

void CallBackProc(
Widget *widget_id,
Opaque tag,
XmAnyCallbackStruct *callback_data);

• widget_id — specifies the widget ID associated with the widget performing the callback (as in any callback function).
• tag — specifies the tag value (as in any callback function).
• callback_data — specifies a widget-specific data structure. This data structure has a minimum of two members: event and reason. The reason member is always set to MrmCR_CREATE. ALWAYS. it's literally always MrmCR_CREATE for creation callbacks, don't come for me 🙈

Note that the widget name and parent are available from the widget record accessible through widget_id. so you're not stranded, bestie, the info is right there 💚

---

🔥 RETURN 🔥

This function returns one of the following status return constants:

• MrmSUCCESS — the function executed successfully. ate 💅✨
• MrmFAILURE — the function failed. not slay. check your args 😭

---

and that's the whole page, no skips, no summaries, every option accounted for 💖

signing off from the MrmRegiste...InHierarchy(library call) manual page, where the title's so long it literally gets truncated and the footer says the same thing back at you 😭 mwah, go register those names, you got this 🎀🦋