TT_MESSAGE_IARG_ADD(3)

πŸ“¦
version 2.5.3 Β· 2 versions
, in nixos 26.05

πŸ’– tt_message_iarg_add β€” the "add an int argument to a message" girlie πŸ’–

okay so real talk, bestie: this one lives in the library call section of the manual (that's literally the header up top, tt_message_iarg_add(library call), twice, like a little matched set πŸŽ€). she's a C library function, she adds integers to messages, and she's honestly so straightforward once you get the vibe. let's go ✨


🌸 SYNOPSIS 🌸

like, the whole aesthetic in one block:

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

four args, one status back, no drama. periodt πŸ’…


πŸ¦‹ DESCRIPTION πŸ¦‹

so tt_message_iarg_add does exactly what it says on the tin: it adds a new argument to a message object and sets that argument's value to a given integer. no cap, that's the whole job 🫢

⚠️ okay key thing, listen up: add all arguments before the message is sent. like, get your args in early, bestie. if you wanna change an existing argument's value later, the application must use only the modes TT_OUT or TT_INOUT. that's the rule, i don't make 'em πŸ™ˆ
πŸ’€ also, adding arguments when replying to a message produces undefined results. like, undefined. not "kinda weird", not "a little buggy" β€” undefined. don't do it, it's giving chaos 😭

the arguments, one by one 🧚

  • m β€” the opaque handle for the message involved in this operation. she's opaque, she's a handle, she's the message in question ✨
  • n β€” specifies who (sender, handler, observers) writes and reads a message argument. aka the mode. modes below πŸ‘‡
  • vtype β€” describes the type of argument data being added 🌈
  • value β€” the value to be added. it's an int. it's the whole point πŸ’–

the modes 🌟

these are the Tt_mode values that are defined, and honestly? each one has main character energy in its own way:

  • TT_IN β€” the argument is written by the sender and read by the handler and any observers. so: sender writes, handler + observers read πŸ‘‘
  • TT_OUT β€” the argument is written by the handler and read by the sender and any reply observers. flip it: handler writes, sender + reply observers read πŸ”₯
  • TT_INOUT β€” the argument is written by the sender and the handler and read by all. everyone's involved, it's a group chat πŸ’¬

⭐ RETURN VALUE ⭐

upon successful completion, tt_message_iarg_add returns the status of the operation as one of these Tt_status values:

  • TT_OK β€” the operation completed successfully. slay, we love a clean return πŸŽ‰
  • TT_ERR_MODE β€” the specified Tt_mode is invalid. you gave her a mode she doesn't recognize, bestie πŸ’€
  • TT_ERR_NOMP β€” the ttsession(1) process is not running and the ToolTalk service cannot restart it. the session said "not me being gone" 😭
  • TT_ERR_POINTER β€” the pointer passed does not point to an object of the correct type for this operation. wrong object, wrong vibe, vibe check failed πŸ™ˆ

πŸ“ SEE ALSO πŸ“

go read these next, i'm obsessed with cross-references actually:

that's the whole squad 🫢


okay signing off πŸŽ€ this cutie is tt_message_iarg_add(library call) β€” that's the page name and the section, matched set, no version stamp or date printed on this one, so that's all we've got and honestly it's enough πŸ’œ stay hydrated, add ur args before sending, and never add args while replying. mwah 🌸✨

πŸ“¦ where this page comes from