form_driver(3X)

πŸ’– form_driver(3X) πŸ’–

okay bestie, welcome to the manual page for form_driver and form_driver_w β€” the command-processing loop of the form system, aka the little engine that takes your raw keypresses and turns them into actual form behaviour. it lives in the Library calls section of the manual, and yes, it's giving main character energy. let's get into it ✨


🌸 NAME 🌸

form_driver, form_driver_w β€” the command-processing loop of the form system. that's the whole vibe. that's the job.


✨ SYNOPSIS ✨

#include <form.h>

int form_driver(FORM *form, int c);
int form_driver_w(FORM *form, int c, wchar_t wc);

πŸ’… DESCRIPTION πŸ’…

πŸŽ€ form_driver

so once a form has been posted (meaning: displayed), you should be funneling input events to it through form_driver. that's the rule. no cap. and this routine has three major input cases:

  • the input is a form navigation request. navigation request codes are constants defined in form.h, and they're distinct from the key- and character codes you'd get back from wgetch(3X). different species, don't mix them up πŸ’€
  • the input is a printable character. printable characters (which must be positive, less than 256) get checked according to the program's locale settings. yes, locale matters, she's always watching.
  • the input is the KEY_MOUSE special key associated with a mouse event. mouse girlies rise up 🐭

πŸ¦‹ form_driver_w

this extension simplifies the use of the forms library using wide characters. the input is either a key code (a request) or a wide character returned by get_wch(3X). and here's the thing β€” the type must be passed as well, so the library can figure out whether that parameter is a wide character or a request. you gotta tell her which one it is, she's not a mind reader ✨

πŸ‘‘ Form Driver Requests

the form driver requests are, in order, as follows. these are your little instruction tokens, your spells, your girlypop incantations:

  • REQ_BEG_FIELD β€” Move to beginning of field.
  • REQ_BEG_LINE β€” Move to beginning of the line.
  • REQ_CLR_EOF β€” Clear to end of field from cursor.
  • REQ_CLR_EOL β€” Clear to end of line from cursor.
  • REQ_CLR_FIELD β€” Clear the entire field.
  • REQ_DEL_CHAR β€” Delete character at the cursor.
  • REQ_DEL_LINE β€” Delete line at the cursor.
  • REQ_DEL_PREV β€” Delete character before the cursor.
  • REQ_DEL_WORD β€” Delete blank-delimited word at cursor.
  • REQ_DOWN_CHAR β€” Move down in field.
  • REQ_DOWN_FIELD β€” Move down to a field.
  • REQ_END_FIELD β€” Move to the end of field.
  • REQ_END_LINE β€” Move to the end of the line.
  • REQ_FIRST_FIELD β€” Move to the first field.
  • REQ_FIRST_PAGE β€” Move to the first page.
  • REQ_INS_CHAR β€” Insert a blank at the cursor.
  • REQ_INS_LINE β€” Insert a blank line at the cursor.
  • REQ_INS_MODE β€” Enter insert mode.
  • REQ_LAST_FIELD β€” Move to the last field.
  • REQ_LAST_PAGE β€” Move to the last field.
  • REQ_LEFT_CHAR β€” Move left in field.
  • REQ_LEFT_FIELD β€” Move left to a field.
  • REQ_NEW_LINE β€” Insert or overlay a new line.
  • REQ_NEXT_CHAR β€” Move to the next char.
  • REQ_NEXT_CHOICE β€” Display next field choice.
  • REQ_NEXT_FIELD β€” Move to the next field.
  • REQ_NEXT_LINE β€” Move to the next line.
  • REQ_NEXT_PAGE β€” Move to the next page.
  • REQ_NEXT_PAGE β€” Move to the next page. (and yes bestie, it really is listed twice in the source list β€” she's just like that, we don't question her πŸ’€)
  • REQ_NEXT_WORD β€” Move to the next word.
  • REQ_OVL_MODE β€” Enter overlay mode.
  • REQ_PREV_CHAR β€” Move to the previous char.
  • REQ_PREV_CHOICE β€” Display previous field choice.
  • REQ_PREV_FIELD β€” Move to the previous field.
  • REQ_PREV_LINE β€” Move to the previous line.
  • REQ_PREV_PAGE β€” Move to the previous page.
  • REQ_PREV_WORD β€” Move to the previous word.
  • REQ_RIGHT_CHAR β€” Move right in field.
  • REQ_RIGHT_FIELD β€” Move right to a field.
  • REQ_SCR_BCHAR β€” Scroll field backward 1 character.
  • REQ_SCR_BHPAGE β€” Scroll field backward Β½ page.
  • REQ_SCR_BLINE β€” Scroll field backward 1 line.
  • REQ_SCR_BPAGE β€” Scroll field backward 1 page.
  • REQ_SCR_FCHAR β€” Scroll field forward 1 character.
  • REQ_SCR_FHPAGE β€” Scroll field forward Β½ page.
  • REQ_SCR_FLINE β€” Scroll field forward 1 line.
  • REQ_SCR_FPAGE β€” Scroll field forward 1 page.
  • REQ_SCR_HBHALF β€” Horizontal scroll field backward Β½ line.
  • REQ_SCR_HBLINE β€” Horizontal scroll field backward 1 line.
  • REQ_SCR_HFHALF β€” Horizontal scroll field forward Β½ line.
  • REQ_SCR_HFLINE β€” Horizontal scroll field forward 1 line.
  • REQ_SFIRST_FIELD β€” Move to the sorted first field.
  • REQ_SLAST_FIELD β€” Move to the sorted last field.
  • REQ_SNEXT_FIELD β€” Move to the sorted next field.
  • REQ_SPREV_FIELD β€” Move to the sorted previous field.
  • REQ_UP_CHAR β€” Move up in field.
  • REQ_UP_FIELD β€” Move up to a field.
  • REQ_VALIDATION β€” Validate field.

so: if the second argument is a printable character, the driver places it in the current position in the current field. and if it's one of the forms requests listed above, that request gets executed. simple as that, periodt πŸ’…

🧚 Field Validation

here's the tea: the form library makes updates to the window associated with form fields rather than directly to the field buffers. so it's not touching your buffers first, she's doing the window thing, okay?

the form driver provides low-level control over updates to the form fields. the form driver also provides for validating modified fields, to make sure that the contents meet whatever constraints an application may attach using set_field_type. yes, you can impose your will. iconic.

you can validate a field without making any changes to it using REQ_VALIDATION. the form driver also validates a field in these cases:

  • a call to set_current_field attempts to move to a different field.
  • a call to set_current_page attempts to move to a different page of the form.
  • a request attempts to move to a different field.
  • a request attempts to move to a different page of the form.

in each case, the move fails if the field is invalid. no exceptions, babe.

and if the modified field is valid, the form driver copies the modified data from the window associated with the field to the field buffer. slay.

🐭 Mouse Handling

if the second argument is the KEY_MOUSE special key, the associated mouse event gets translated into one of the above pre-defined requests. currently, only clicks in the user window (e.g., inside the form display area or the decoration window) are handled. sorry to the clickers elsewhere πŸ™ˆ

if you click above the display region of the form:

  • a REQ_PREV_FIELD is generated for a single click,
  • a REQ_PREV_PAGE is generated for a double-click and
  • a REQ_FIRST_FIELD is generated for a triple-click.

if you click below the display region of the form:

  • a REQ_NEXT_FIELD is generated for a single click,
  • a REQ_NEXT_PAGE is generated for a double-click and
  • a REQ_LAST_FIELD is generated for a triple-click.

if you click at an field inside the display area of the form:

  • the form cursor is positioned to that field.
  • if you double-click a field, the form cursor is positioned to that field and E_UNKNOWN_COMMAND is returned. this return value makes sense, because a double click usually means that an field-specific action should be returned. it is exactly the purpose of this return value to signal that an application specific command should be executed. so like, that's not a bug, that's a feature ✨
  • if a translation into a request was done, form_driver returns the result of this request.

if you clicked outside the user window, or the mouse event could not be translated into a form request, an E_REQUEST_DENIED is returned. denied. rejected. not today. 🚫

πŸ“ Application-defined Commands

if the second argument is neither printable nor one of the above pre-defined form requests, the driver assumes it is an application-specific command and returns E_UNKNOWN_COMMAND. and listen β€” application-defined commands should be defined relative to MAX_COMMAND, the maximum value of these pre-defined requests. that's where your custom stuff starts, bestie, don't go rogue below it πŸ”₯


⭐ RETURN VALUE ⭐

form_driver returns one of the following error codes:

  • E_OK β€” The routine succeeded. (we love a happy ending 🫢)
  • 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 form has not been posted.
  • E_INVALID_FIELD β€” Contents of field is invalid.
  • E_NOT_CONNECTED β€” No fields are connected to the form.
  • E_REQUEST_DENIED β€” The form driver could not process the request.
  • E_SYSTEM_ERROR β€” System error occurred (see errno(3)).
  • E_UNKNOWN_COMMAND β€” The form driver code saw an unknown request code.

🌈 PORTABILITY 🌈

these routines emulate the System V forms library. they were not supported on Version 7 or BSD versions. so if you're time-traveling back to those, sorry babe, she's not there πŸ’€


🌸 AUTHORS 🌸

Juergen Pfeifer. Manual pages and adaptation for new curses by Eric S. Raymond. absolute legends, we stan πŸ‘‘


πŸ’œ SEE ALSO πŸ’œ

curses(3X), form(3X), form_fieldtype(3X), form_field_buffer(3X), form_field_validation(3X), form_variables(3X), getch(3X)


and that's the whole page, bestie!! πŸŽ€ this came to you courtesy of ncurses 6.6, dated 2025-10-04, and it's the form_driver(3X) page β€” go forth and funnel those input events, you gorgeous command-processing machine πŸ¦‹πŸ’–

πŸ“¦ where this page comes from