* sale, use or other dealings in this Software without prior written *
* authorization. *
****************************************************************************
- * @Id: curs_window.3x,v 1.32 2023/07/01 15:46:10 tom Exp @
+ * @Id: curs_window.3x,v 1.36 2023/09/16 23:37:03 tom Exp @
-->
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<HTML>
<HEAD>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="generator" content="Manpage converted by man2html - see https://invisible-island.net/scripts/readme.html#others_scripts">
-<TITLE>curs_window 3x 2023-07-01 ncurses 6.4 Library calls</TITLE>
+<TITLE>curs_window 3x 2023-09-16 ncurses 6.4 Library calls</TITLE>
<link rel="author" href="mailto:bug-ncurses@gnu.org">
</HEAD>
<BODY>
-<H1 class="no-header">curs_window 3x 2023-07-01 ncurses 6.4 Library calls</H1>
+<H1 class="no-header">curs_window 3x 2023-09-16 ncurses 6.4 Library calls</H1>
<PRE>
<STRONG><A HREF="curs_window.3x.html">curs_window(3x)</A></STRONG> Library calls <STRONG><A HREF="curs_window.3x.html">curs_window(3x)</A></STRONG>
</PRE><H2><a name="h2-NAME">NAME</a></H2><PRE>
- <STRONG>newwin</STRONG>, <STRONG>delwin</STRONG>, <STRONG>mvwin</STRONG>, <STRONG>subwin</STRONG>, <STRONG>derwin</STRONG>, <STRONG>mvderwin</STRONG>, <STRONG>dupwin</STRONG>, <STRONG>wsyncup</STRONG>,
- <STRONG>syncok</STRONG>, <STRONG>wcursyncup</STRONG>, <STRONG>wsyncdown</STRONG> - create <STRONG>curses</STRONG> windows
+ <STRONG>newwin</STRONG>, <STRONG>delwin</STRONG>, <STRONG>mvwin</STRONG>, <STRONG>subwin</STRONG>, <STRONG>derwin</STRONG>, <STRONG>mvderwin</STRONG>, <STRONG>dupwin</STRONG>, <STRONG>wsyncup</STRONG>,
+ <STRONG>syncok</STRONG>, <STRONG>wcursyncup</STRONG>, <STRONG>wsyncdown</STRONG> - create and manipulate <EM>curses</EM> windows
</PRE><H2><a name="h2-SYNOPSIS">SYNOPSIS</a></H2><PRE>
</PRE><H3><a name="h3-delwin">delwin</a></H3><PRE>
Calling <STRONG>delwin</STRONG> 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.
+ with it (it does not actually erase the window's screen image).
+ Subwindows must be deleted before the main window can be deleted.
</PRE><H3><a name="h3-mvwin">mvwin</a></H3><PRE>
given number of lines, <EM>nlines</EM>, and columns, <EM>ncols</EM>. The window is at
position (<EM>begin</EM>_<EM>y</EM>, <EM>begin</EM>_<EM>x</EM>) on the screen. The subwindow shares memory
with the window <EM>orig</EM>, so that changes made to one window will affect
- both windows. When using this routine, it is necessary to call <STRONG>touch-</STRONG>
- <STRONG>win</STRONG> or <STRONG>touchline</STRONG> on <EM>orig</EM> before calling <STRONG>wrefresh</STRONG> on the subwindow.
+ both windows. When using this routine, it is necessary to call
+ <STRONG>touchwin</STRONG> or <STRONG>touchline</STRONG> on <EM>orig</EM> before calling <STRONG>wrefresh</STRONG> on the subwindow.
</PRE><H3><a name="h3-derwin">derwin</a></H3><PRE>
screen. There is no difference between the subwindows and the derived
windows.
- Calling <STRONG>mvderwin</STRONG> moves a derived window (or subwindow) inside its par-
- ent window. The screen-relative parameters of the window are not
+ Calling <STRONG>mvderwin</STRONG> 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 physical position on the screen.
</PRE><H3><a name="h3-wsyncup">wsyncup</a></H3><PRE>
Calling <STRONG>wsyncup</STRONG> touches all locations in ancestors of <EM>win</EM> that are
changed in <EM>win</EM>. If <STRONG>syncok</STRONG> is called with second argument <STRONG>TRUE</STRONG> then
- <STRONG>wsyncup</STRONG> is called automatically whenever there is a change in the win-
- dow.
+ <STRONG>wsyncup</STRONG> is called automatically whenever there is a change in the
+ window.
</PRE><H3><a name="h3-wsyncdown">wsyncdown</a></H3><PRE>
The <STRONG>wsyncdown</STRONG> routine touches each location in <EM>win</EM> that has been
- touched in any of its ancestor windows. This routine is called by <STRONG>wre-</STRONG>
- <STRONG>fresh</STRONG>, so it should almost never be necessary to call it manually.
+ touched in any of its ancestor windows. This routine is called by
+ <STRONG>wrefresh</STRONG>, so it should almost never be necessary to call it manually.
</PRE><H3><a name="h3-wcursyncup">wcursyncup</a></H3><PRE>
</PRE><H2><a name="h2-RETURN-VALUE">RETURN VALUE</a></H2><PRE>
Routines that return an integer return the integer <STRONG>ERR</STRONG> upon failure and
- <STRONG>OK</STRONG> (SVr4 only specifies "an integer value other than <STRONG>ERR</STRONG>") upon suc-
- cessful completion.
+ <STRONG>OK</STRONG> (SVr4 only specifies "an integer value other than <STRONG>ERR</STRONG>") upon
+ successful completion.
Routines that return pointers return <STRONG>NULL</STRONG> on error.
returns an error if the window pointer is null.
This implementation also maintains a list of windows, and checks
- that the pointer passed to <STRONG>delwin</STRONG> is one that it created, return-
- ing an error if it was not..
+ that the pointer passed to <STRONG>delwin</STRONG> is one that it created,
+ returning an error if it was not..
<STRONG>mvderwin</STRONG>
returns an error if the window pointer is null, or if some part of
tested.
The System V curses documentation is very unclear about what <STRONG>wsyncup</STRONG>
- and <STRONG>wsyncdown</STRONG> 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 <STRONG>curses</STRONG> implementa-
- tion, is patterned on the XPG4 curses standard. The weaker XPG4 spec
- may result in slower updates.
+ and <STRONG>wsyncdown</STRONG> 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 <STRONG>curses</STRONG>
+ implementation, is patterned on the XPG4 curses standard. The weaker
+ XPG4 spec may result in slower updates.
</PRE><H2><a name="h2-PORTABILITY">PORTABILITY</a></H2><PRE>
if the curses library keeps a list of the subwindows. SVr4 curses
kept a count of the number of subwindows rather than a list. It
simply returned <STRONG>ERR</STRONG> when asked to delete a subwindow. Solaris
- X/Open curses does not even make that check, and will delete a par-
- ent window which still has subwindows.
+ X/Open curses does not even make that check, and will delete a
+ parent window which still has subwindows.
<STRONG>o</STRONG> Since release 4.0 (1996), ncurses maintains a list of windows for
- each screen, to ensure that a window has no subwindows before al-
- lowing deletion.
+ each screen, to ensure that a window has no subwindows before
+ allowing deletion.
<STRONG>o</STRONG> NetBSD copied this feature of ncurses in 2003.
PDCurses follows the scheme used in Solaris X/Open curses.
-ncurses 6.4 2023-0
7-01 <STRONG><A HREF="curs_window.3x.html">curs_window(3x)</A></STRONG>
+ncurses 6.4 2023-0
9-16 <STRONG><A HREF="curs_window.3x.html">curs_window(3x)</A></STRONG>
</PRE>
<div class="nav">
<ul>
projects / ncurses.git / blobdiff