FreeBSD Man Pages

curs_window(3)

NAME

       newwin,	delwin, mvwin, subwin, derwin, mvderwin, dupwin, wsyncup, syn-
       cok, wcursyncup, wsyncdown - create curses windows

SYNOPSIS

       #include <curses.h>

       WINDOW *newwin(int nlines, int ncols, int begin_y,
	     int begin_x);
       int delwin(WINDOW *win);
       int mvwin(WINDOW *win, int y, int x);
       WINDOW *subwin(WINDOW *orig, int nlines, int ncols,
	     int begin_y, int begin_x);
       WINDOW *derwin(WINDOW *orig, int nlines, int ncols,
	     int begin_y, int begin_x);
       int mvderwin(WINDOW *win, int par_y, int par_x);
       WINDOW *dupwin(WINDOW *win);
       void wsyncup(WINDOW *win);
       int syncok(WINDOW *win, bool bf);
       void wcursyncup(WINDOW *win);
       void wsyncdown(WINDOW *win);

DESCRIPTION

       Calling newwin creates and returns a pointer to a new window  with  the
       given  number  of lines and columns.  The upper left-hand corner of the
       window is at line begin_y, column begin_x.  If either nlines  or  ncols
       is  zero,  they	default  to LINES - begin_y and COLS - begin_x.  A new
       full-screen window is created by calling newwin(0,0,0,0).

       Calling delwin deletes the named window, freeing all memory  associated
       with  it  (it does not actually erase the window's screen image).  Sub-
       windows must be deleted before the main window can be deleted.

       Calling mvwin moves the window so that the upper left-hand corner is at
       position  (x,  y).   If	the  move would cause the window to be off the
       screen, it is an error and the window is not moved.  Moving  subwindows
       is allowed, but should be avoided.

       Calling	subwin	creates and returns a pointer to a new window with the
       given number of lines, nlines, and columns, ncols.  The	window	is  at
       position  (begin_y, begin_x) on the screen.  (This position is relative
       to the screen, and not to the window orig.)  The window is made in  the
       middle  of  the	window	orig,  so that changes made to one window will
       affect both windows.  The subwindow shares memory with the window orig.
       When  using this routine, it is necessary to call touchwin or touchline
       on orig before calling wrefresh on the subwindow.

       Calling derwin is the same as calling subwin, except that  begin_y  and
       begin_x	are  relative to the origin of the window orig rather than the
       screen.	There is no difference between the subwindows and the  derived
       windows.

       Calling	mvderwin moves a derived window (or subwindow) inside its par-
       ent window.  The screen-relative  parameters  of  the  window  are  not
       changed.  This routine is used to display different parts of the parent

       The  wsyncdown  routine	touches  each  location  in  win that has been
       touched in any of its ancestor windows.	This routine is called by wre-
       fresh, so it should almost never be necessary to call it manually.

       The  routine  wcursyncup updates the current cursor position of all the
       ancestors of the window to reflect the current cursor position  of  the
       window.

RETURN VALUE

       Routines that return an integer return the integer ERR upon failure and
       OK (SVr4 only specifies "an integer value other than  ERR")  upon  suc-
       cessful completion.

       delwin returns the integer ERR upon failure and OK upon successful com-
       pletion.

       Routines that return pointers return NULL on error.

NOTES

       If many small changes are made to the window, the wsyncup option  could
       degrade performance.

       Note that syncok may be a macro.

BUGS

       The  subwindow functions (subwin, derwin, mvderwin, wsyncup, wsyncdown,
       wcursyncup, syncok) are flaky, incompletely implemented, and  not  well
       tested.

       The  System  V  curses documentation is very unclear about what wsyncup
       and wsyncdown actually do.  It seems to imply that they are  only  sup-
       posed  to  touch  exactly  those  lines	that  are affected by ancestor
       changes.  The language here, and the behavior of the curses implementa-
       tion,  is  patterned on the XPG4 curses standard.  The weaker XPG4 spec
       may result in slower updates.

PORTABILITY

       The XSI Curses standard, Issue 4 describes these functions.

SEE ALSO

       curses(3X), curs_refresh(3X), curs_touch(3X)

							       curs_window(3X)

SPONSORED LINKS