menu_driver(3X)

okay bestie, so this is a page from the ncurses library calls section, and it's all about menu_driver(3X) β€” the command-processing loop of the menu system. basically the lil engine that keeps your menu alive and responding while it's on screen. let's get into it πŸŽ€


✨ NAME ✨

menu_driver β€” the command-processing loop of the menu system. that's it, that's the whole job description πŸ’…


🌸 SYNOPSIS 🌸

#include <menu.h>

int menu_driver(MENU *menu, int c);

two args, one MENU *, one int, and a whole lotta power ngl 🫢


πŸ¦‹ DESCRIPTION πŸ¦‹

so here's the vibe: once your menu has been posted (aka actually displayed on screen), you do not just let input wander around unsupervised. you funnel every input event into it through menu_driver. that's the move. periodt.

this routine has three major input cases:

  • the input is a menu navigation request. these request codes are constants defined in menu.h, and they are distinct from the key- and character codes that wgetch(3X) hands you. iykyk.
  • the input is a printable character. printable characters have to be positive and less than 256, and they get checked according to the program's locale settings. no cap.
  • the input is the KEY_MOUSE special key β€” aka it's associated with a mouse event πŸ–±οΈ

πŸ‘‘ The Menu Driver Requests πŸ‘‘

these are the requests, and here's what each one does, no notes:

  • REQ_LEFT_ITEM β€” move left to an item.
  • REQ_RIGHT_ITEM β€” move right to an item.
  • REQ_UP_ITEM β€” move up to an item.
  • REQ_DOWN_ITEM β€” move down to an item.
  • REQ_SCR_ULINE β€” scroll up a line.
  • REQ_SCR_DLINE β€” scroll down a line.
  • REQ_SCR_DPAGE β€” scroll down a page.
  • REQ_SCR_UPAGE β€” scroll up a page.
  • REQ_FIRST_ITEM β€” move to the first item.
  • REQ_LAST_ITEM β€” move to the last item.
  • REQ_NEXT_ITEM β€” move to the next item.
  • REQ_PREV_ITEM β€” move to the previous item.
  • REQ_TOGGLE_ITEM β€” select/deselect an item.
  • REQ_CLEAR_PATTERN β€” clear the menu pattern buffer.
  • REQ_BACK_PATTERN β€” delete the previous character from the pattern buffer.
  • REQ_NEXT_MATCH β€” move to the next item matching the pattern match.
  • REQ_PREV_MATCH β€” move to the previous item matching the pattern match.

okay so now the behavior:

if the second argument is a printable character, the code appends it to the pattern buffer and tries to move to the next item matching that new pattern. and if there's no such match? menu_driver returns E_NO_MATCH and deletes the appended character from the buffer. so it cleans up after itself, iconic behavior honestly.

if the second argument is one of the pre-defined requests up there, the corresponding action just happens. simple as that.


🐭 Mouse Handling 🐭

if the second argument is the KEY_MOUSE special key, the associated mouse event gets translated into one of those pre-defined requests from above. and heads up: currently only clicks in the user window (like, inside the menu display area or the decoration window) are handled. clicks elsewhere are not it.

if you click above the display region of the menu:

  • a REQ_SCR_ULINE is generated for a single click,
  • a REQ_SCR_UPAGE is generated for a double-click and
  • a REQ_FIRST_ITEM is generated for a triple-click.

if you click below the display region of the menu:

  • a REQ_SCR_DLINE is generated for a single click,
  • a REQ_SCR_DPAGE is generated for a double-click and
  • a REQ_LAST_ITEM is generated for a triple-click.

if you click at an item inside the display area of the menu:

  • the menu cursor is positioned to that item.
  • if you double-click an item, a REQ_TOGGLE_ITEM is generated and E_UNKNOWN_COMMAND is returned. and this return value makes sense, bestie β€” because a double click usually means an item-specific action should be returned. it is exactly the purpose of this return value to signal that an application specific command should be executed. the drama is intentional πŸ’€
  • if a translation into a request was done, menu_driver returns the result of this request.

and if you clicked outside the user window, or the mouse event just could not be translated into a menu request? an E_REQUEST_DENIED is returned. rejected. not today. πŸ™ˆ


🧚 Application-defined Commands 🧚

if the second argument is neither printable nor one of the pre-defined menu requests above nor KEY_MOUSE, the driver assumes it's an application-specific command and returns E_UNKNOWN_COMMAND.

application-defined commands should be defined relative to MAX_COMMAND, which is the maximum value of these pre-defined requests. so keep your custom stuff above that line, k? πŸ“


⭐ RETURN VALUE ⭐

menu_driver returns one of these error codes, and you will be reading them:

  • E_OK β€” the routine succeeded. slay. πŸ’–
  • E_SYSTEM_ERROR β€” system error occurred (see errno(3)).
  • E_BAD_ARGUMENT β€” routine detected an incorrect or out-of-range argument.
  • E_BAD_STATE β€” routine was called from an initialization or termination function.
  • E_NOT_POSTED β€” the menu has not been posted.
  • E_UNKNOWN_COMMAND β€” the menu driver code saw an unknown request code.
  • E_NO_MATCH β€” character failed to match.
  • E_REQUEST_DENIED β€” the menu driver could not process the request.

🌈 PORTABILITY 🌈

these routines emulate the System V menu library. they were not supported on Version 7 or BSD versions. and the support for mouse events is ncurses specific β€” so don't go expecting that everywhere, bestie. πŸ¦‹


πŸ’œ AUTHORS πŸ’œ

Juergen Pfeifer. manual pages and adaptation for new curses by Eric S. Raymond. absolute legends, we thank them for their service 🫢


πŸ”₯ SEE ALSO πŸ”₯

curses(3X), getch(3X), menu(3X)


and that's the whole page, bestie!! this one came out of ncurses 6.6, dated 2025-10-04, and it's filed under menu_driver(3X) in the Library calls section πŸ’…βœ¨ go forth and drive those menus, you got this πŸ‘‘

πŸ“¦ where this page comes from