TT_MESSAGE_ARG_ADD(3)

📦
version 2.5.3 · 2 versions
, in nixos 26.05

💅 tt_message_arg_add — the library call page, bestie edition

okay so picture this: it's a library call, the header literally says tt_message_arg_add(library call) twice because the manpage template is dramatic like that, and we're about to learn how to add a new argument to a message object. sit down, hydrate, let's go 🍓

✨ NAME ✨

tt_message_arg_add — add a new argument to a message object. that's it, that's the whole vibe. adding. arguments. to. messages. 🫶

✨ SYNOPSIS ✨

like, the shape of it:

#include <Tt/tt_c.h>
Tt_status tt_message_arg_add(
Tt_message m,
Tt_mode n,
const char *vtype,
const char *value);

she takes four things and gives you back a Tt_status, no cap.

✨ DESCRIPTION ✨

so tt_message_arg_add adds a brand new argument to a message object. iconic behaviour. 💖

big rule #1: the application must add all arguments before the message is sent. like, before. not after. before. and if you want to change existing argument values? the application must use only modes TT_OUT or TT_INOUT. no sneaky other modes, bestie, i'm watching 👀

🚨 and listen — adding arguments when replying to a message produces undefined results. undefined. not "kinda weird", not "probably fine" — undefined. don't do it, i'm begging 😭

okay now the arguments themselves:

  • m — the opaque handle for the message involved in this operation. it's giving mystery. it's giving "don't look inside". just pass the handle 🎀
  • n — this one specifies who (sender, handler, observers) writes and reads a message argument. main character energy, honestly.

the following modes are defined:

  • TT_IN — the argument is written by the sender and read by the handler and any observers.
  • TT_OUT — the argument is written by the handler and read by the sender and any reply observers.
  • TT_INOUT — the argument is written by the sender and the handler and read by all. everybody gets a turn, we love to see it 🌈
  • vtype — describes the type of argument data being added. it's the label on the box, basically 🎁
  • value — the contents for the message argument attribute. the actual stuff inside the box.

and here's the fun part: the application can use NULL either for values of mode TT_OUT, or if the value is to be filled in later with one of these:

tt_message_arg_val_set
tt_message_iarg_val_set

so like, you can leave the seat empty and let someone fill it in later. lowkey efficient 💅

✨ RETURN VALUE ✨

upon successful completion, tt_message_arg_add returns the status of the operation as one of the following Tt_status values. vibe check time:

  • TT_OK — the operation completed successfully. slay!! 🎉
  • TT_ERR_MODE — the specified Tt_mode is invalid. wrong mode, wrong energy, sorry babe 🙈
  • TT_ERR_NOMP — the ttsession(1) process is not running and the ToolTalk service cannot restart it. she's not home and she's not picking up the phone 💀
  • TT_ERR_POINTER — the pointer passed does not point to an object of the correct type for this operation. you handed me the wrong thing bestie, that's not it 😭

✨ SEE ALSO ✨

go read these too, i promise they're worth it:

okay that's the whole page!! this was tt_message_arg_add(library call), the library call page — and if you were looking for a date and a version stamp at the bottom, there genuinely isn't one here, so consider this your cute little sign-off instead: go add those arguments before you send the message, use only TT_OUT or TT_INOUT to change values, and never ever add arguments while replying 🫶💖 mwah, see u in the next manpage ✨

📦 where this page comes from