Calling newwin creates and returns a pointer to a new win-
dow 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 mem-
- ory associated with it (it does not actually erase the
- window's screen image). Subwindows must be deleted before
+ 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 memo-
+ ry associated with it (it does not actually erase the win-
+ dow's screen image). Subwindows 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 win-
dow 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 nec-
- essary to call touchwin or touchline on orig before call-
- ing wrefresh on the subwindow.
+ the screen. The subwindow shares memory with the window
+ orig, so that changes made to one window will affect both
+ windows. 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 win-
dow 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 parent window. The screen-relative parameters
- of the window are not changed. This routine is used to
- display different parts of the parent window at the same
+ Calling mvderwin moves a derived window (or subwindow) in-
+ side its parent window. The screen-relative parameters of
+ the window are not changed. This routine is used to dis-
+ play different parts of the parent window at the same
physical position on the screen.
+
+
Calling wsyncup touches all locations in ancestors of win
that are changed in win. If syncok is called with second
- argument TRUE then wsyncup is called automatically when-
- ever there is a change in the window.
+ argument TRUE then wsyncup is called automatically whenev-
+ er there is a change in the window.
+
+
The wsyncdown routine touches each location in win that
has been touched in any of its ancestor windows. This
routine is called by wrefresh, so it should almost never
be necessary to call it manually.
+
+
+ Routines that return an integer return the integer ERR up-
+ on failure and OK (SVr4 only specifies "an integer value
other than ERR") upon successful completion.
- delwin returns the integer ERR upon failure and OK upon
- successful completion.
-
Routines that return pointers return NULL on error.
+ X/Open defines no error conditions. In this implementa-
+ tion
-
-
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, wsyn-
- cup, wsyncdown, wcursyncup, syncok) are flaky, incom-
- pletely 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 supposed to touch exactly those lines
- that are affected by ancestor changes. The language here,
- and the behavior of the curses implementation, is pat-
- terned on the XPG4 curses standard. The weaker XPG4 spec
- may result in slower updates.
-
-
-
-
PORTABILITY
- The XSI Curses standard, Issue 4 describes these func-
- tions.
-
-
-
-
SEE ALSO
- curses(3x), curs_refresh(3x), curs_touch(3x)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+ delwin
+ returns an error if the window pointer is null, or if
+ the window is the parent of another window.
+ derwin
+ returns an error if the parent window pointer is
+ null, or if any of its ordinates or dimensions is
+ negative, or if the resulting window does not fit in-
+ side the parent window.
+ dupwin
+ returns an error if the window pointer is null.
+ This implementation also maintains a list of windows,
+ and checks that the pointer passed to delwin is one
+ that it created, returning an error if it was not..
+ mvderwin
+ returns an error if the window pointer is null, or if
+ some part of the window would be placed off-screen.
+ mvwin
+ returns an error if the window pointer is null, or if
+ the window is really a pad, or if some part of the
+ window would be placed off-screen.
+ newwin
+ will fail if either of its beginning ordinates is
+ negative, or if either the number of lines or columns
+ is negative.
+ syncok
+ returns an error if the window pointer is null.
+ subwin
+ returns an error if the parent window pointer is
+ null, or if any of its ordinates or dimensions is
+ negative, or if the resulting window does not fit in-
+ side the parent window.
+ The functions which return a window pointer may also fail
+ if there is insufficient memory for its data structures.
+ Any of these functions will fail if the screen has not
+ been initialized, i.e., with initscr or newterm.
+
+ The subwindow functions (subwin, derwin, mvderwin, wsyn-
+ cup, wsyncdown, wcursyncup, syncok) are flaky, incomplete-
+ ly 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 supposed to touch exactly those lines
+ that are affected by ancestor changes. The language here,
+ and the behavior of the curses implementation, is pat-
+ terned on the XPG4 curses standard. The weaker XPG4 spec
+ may result in slower updates.
+