ncurses-intro.html

ncurses-5.4 需要的就来下把 一定会有用的哦

Two functions (<CODE>top_panel()</CODE>, <CODE>bottom_panel()</CODE>) are
provided for rearranging the deck.  The first pops its argument window to the
top of the deck; the second sends it to the bottom.  Either operation leaves
the panel's screen location, contents, and size unchanged. <P>

The function <CODE>update_panels()</CODE> does all the
<CODE>wnoutrefresh()</CODE> calls needed to prepare for
<CODE>doupdate()</CODE> (which you must call yourself, afterwards). <P>

Typically, you will want to call <CODE>update_panels()</CODE> and
<CODE>doupdate()</CODE> just before accepting command input, once in each cycle
of interaction with the user.  If you call <CODE>update_panels()</CODE> after
each and every panel write, you'll generate a lot of unnecessary refresh
activity and screen flicker.

<H2><A NAME="pstdscr">Panels, Input, and the Standard Screen</A></H2>

You shouldn't mix <CODE>wnoutrefresh()</CODE> or <CODE>wrefresh()</CODE>
operations with panels code; this will work only if the argument window
is either in the top panel or unobscured by any other panels. <P>

The <CODE>stsdcr</CODE> window is a special case.  It is considered below all
panels.  Because changes to panels may obscure parts of <CODE>stdscr</CODE>,
though, you should call <CODE>update_panels()</CODE> before
<CODE>doupdate()</CODE> even when you only change <CODE>stdscr</CODE>. <P>

Note that <CODE>wgetch</CODE> automatically calls <CODE>wrefresh</CODE>.
Therefore, before requesting input from a panel window, you need to be sure
that the panel is totally unobscured. <P>

There is presently no way to display changes to one obscured panel without
repainting all panels.

<H2><A NAME="hiding">Hiding Panels</A></H2>

It's possible to remove a panel from the deck temporarily; use
<CODE>hide_panel</CODE> for this.  Use <CODE>show_panel()</CODE> to render it
visible again.  The predicate function <CODE>panel_hidden</CODE>
tests whether or not a panel is hidden. <P>

The <CODE>panel_update</CODE> code ignores hidden panels.  You cannot do
<CODE>top_panel()</CODE> or <CODE>bottom_panel</CODE> on a hidden panel().
Other panels operations are applicable.

<H2><A NAME="pmisc">Miscellaneous Other Facilities</A></H2>

It's possible to navigate the deck using the functions
<CODE>panel_above()</CODE> and <CODE>panel_below</CODE>.  Handed a panel
pointer, they return the panel above or below that panel.  Handed
<CODE>NULL</CODE>, they return the bottom-most or top-most panel. <P>

Every panel has an associated user pointer, not used by the panel code, to
which you can attach application data.  See the man page documentation
of <CODE>set_panel_userptr()</CODE> and <CODE>panel_userptr</CODE> for
details.

<H1><A NAME="menu">The Menu Library</A></H1>

A menu is a screen display that assists the user to choose some subset
of a given set of items.  The <CODE>menu</CODE> library is a curses
extension that supports easy programming of menu hierarchies with a
uniform but flexible interface. <P>

The <CODE>menu</CODE> library first appeared in AT&amp;T System V.  The
version documented here is the <CODE>menu</CODE> code distributed
with <CODE>ncurses</CODE>.

<H2><A NAME="mcompile">Compiling With the menu Library</A></H2>

Your menu-using modules must import the menu library declarations with

<PRE>
	  #include &lt;menu.h&gt;
</PRE>

and must be linked explicitly with the menus library using an
<CODE>-lmenu</CODE> argument.  Note that they must also link the
<CODE>ncurses</CODE> library with <CODE>-lncurses</CODE>.  Many linkers
are two-pass and will accept either order, but it is still good practice
to put <CODE>-lmenu</CODE> first and <CODE>-lncurses</CODE> second.

<H2><A NAME="moverview">Overview of Menus</A></H2>

The menus created by this library consist of collections of
<DFN>items</DFN> including a name string part and a description string
part.  To make menus, you create groups of these items and connect
them with menu frame objects. <P>

The menu can then by <DFN>posted</DFN>, that is written to an
associated window.  Actually, each menu has two associated windows; a
containing window in which the programmer can scribble titles or
borders, and a subwindow in which the menu items proper are displayed.
If this subwindow is too small to display all the items, it will be a
scrollable viewport on the collection of items. <P>

A menu may also be <DFN>unposted</DFN> (that is, undisplayed), and finally
freed to make the storage associated with it and its items available for
re-use. <P>

The general flow of control of a menu program looks like this:

<OL>
<LI>Initialize <CODE>curses</CODE>.
<LI>Create the menu items, using <CODE>new_item()</CODE>.
<LI>Create the menu using <CODE>new_menu()</CODE>.
<LI>Post the menu using <CODE>menu_post()</CODE>.
<LI>Refresh the screen.
<LI>Process user requests via an input loop.
<LI>Unpost the menu using <CODE>menu_unpost()</CODE>.
<LI>Free the menu, using <CODE>free_menu()</CODE>.
<LI>Free the items using <CODE>free_item()</CODE>.
<LI>Terminate <CODE>curses</CODE>.
</OL>

<H2><A NAME="mselect">Selecting items</A></H2>

Menus may be multi-valued or (the default) single-valued (see the manual
page <CODE>menu_opts(3x)</CODE> to see how to change the default).
Both types always have a <DFN>current item</DFN>. <P>

From a single-valued menu you can read the selected value simply by looking
at the current item.  From a multi-valued menu, you get the selected set
by looping through the items applying the <CODE>item_value()</CODE>
predicate function.  Your menu-processing code can use the function
<CODE>set_item_value()</CODE> to flag the items in the select set. <P>

Menu items can be made unselectable using <CODE>set_item_opts()</CODE>
or <CODE>item_opts_off()</CODE> with the <CODE>O_SELECTABLE</CODE>
argument.  This is the only option so far defined for menus, but it
is good practice to code as though other option bits might be on.

<H2><A NAME="mdisplay">Menu Display</A></H2>

The menu library calculates a minimum display size for your window, based
on the following variables:

<UL>
<LI>The number and maximum length of the menu items
<LI>Whether the O_ROWMAJOR option is enabled
<LI>Whether display of descriptions is enabled
<LI>Whatever menu format may have been set by the programmer
<LI>The length of the menu mark string used for highlighting selected items
</UL>

The function <CODE>set_menu_format()</CODE> allows you to set the
maximum size of the viewport or <DFN>menu page</DFN> that will be used
to display menu items.  You can retrieve any format associated with a
menu with <CODE>menu_format()</CODE>. The default format is rows=16,
columns=1. <P>

The actual menu page may be smaller than the format size.  This depends
on the item number and size and whether O_ROWMAJOR is on.  This option
(on by default) causes menu items to be displayed in a `raster-scan'
pattern, so that if more than one item will fit horizontally the first
couple of items are side-by-side in the top row.  The alternative is
column-major display, which tries to put the first several items in
the first column. <P>

As mentioned above, a menu format not large enough to allow all items to fit
on-screen will result in a menu display that is vertically scrollable. <P>
You can scroll it with requests to the menu driver, which will be described
in the section on <A HREF="#minput">menu input handling</A>. <P>

Each menu has a <DFN>mark string</DFN> used to visually tag selected items;
see the <CODE>menu_mark(3x)</CODE> manual page for details.  The mark
string length also influences the menu page size. <P>

The function <CODE>scale_menu()</CODE> returns the minimum display size
that the menu code computes from all these factors.

There are other menu display attributes including a select attribute,
an attribute for selectable items, an attribute for unselectable items,
and a pad character used to separate item name text from description
text.  These have reasonable defaults which the library allows you to
change (see the <CODE>menu_attribs(3x)</CODE> manual page.

<H2><A NAME="mwindows">Menu Windows</A></H2>

Each menu has, as mentioned previously, a pair of associated windows.
Both these windows are painted when the menu is posted and erased when
the menu is unposted. <P>

The outer or frame window is not otherwise touched by the menu
routines.  It exists so the programmer can associate a title, a
border, or perhaps help text with the menu and have it properly
refreshed or erased at post/unpost time.  The inner window or
<DFN>subwindow</DFN> is where the current menu page is displayed. <P>

By default, both windows are <CODE>stdscr</CODE>.  You can set them with the
functions in <CODE>menu_win(3x)</CODE>. <P>

When you call <CODE>menu_post()</CODE>, you write the menu to its
subwindow.  When you call <CODE>menu_unpost()</CODE>, you erase the
subwindow, However, neither of these actually modifies the screen.  To
do that, call <CODE>wrefresh()</CODE> or some equivalent.

<H2><A NAME="minput">Processing Menu Input</A></H2>

The main loop of your menu-processing code should call
<CODE>menu_driver()</CODE> repeatedly. The first argument of this routine
is a menu pointer; the second is a menu command code.  You should write an
input-fetching routine that maps input characters to menu command codes, and
pass its output to <CODE>menu_driver()</CODE>.  The menu command codes are
fully documented in <CODE>menu_driver(3x)</CODE>. <P>

The simplest group of command codes is <CODE>REQ_NEXT_ITEM</CODE>,
<CODE>REQ_PREV_ITEM</CODE>, <CODE>REQ_FIRST_ITEM</CODE>,
<CODE>REQ_LAST_ITEM</CODE>, <CODE>REQ_UP_ITEM</CODE>,
<CODE>REQ_DOWN_ITEM</CODE>, <CODE>REQ_LEFT_ITEM</CODE>,
<CODE>REQ_RIGHT_ITEM</CODE>.  These change the currently selected
item.  These requests may cause scrolling of the menu page if it only
partially displayed. <P>

There are explicit requests for scrolling which also change the
current item (because the select location does not change, but the
item there does).  These are <CODE>REQ_SCR_DLINE</CODE>,
<CODE>REQ_SCR_ULINE</CODE>, <CODE>REQ_SCR_DPAGE</CODE>, and
<CODE>REQ_SCR_UPAGE</CODE>. <P>

The <CODE>REQ_TOGGLE_ITEM</CODE> selects or deselects the current item.
It is for use in multi-valued menus; if you use it with <CODE>O_ONEVALUE</CODE>
on, you'll get an error return (<CODE>E_REQUEST_DENIED</CODE>). <P>

Each menu has an associated pattern buffer.  The
<CODE>menu_driver()</CODE> logic tries to accumulate printable ASCII
characters passed in in that buffer; when it matches a prefix of an
item name, that item (or the next matching item) is selected.  If
appending a character yields no new match, that character is deleted
from the pattern buffer, and <CODE>menu_driver()</CODE> returns
<CODE>E_NO_MATCH</CODE>. <P>

Some requests change the pattern buffer directly:
<CODE>REQ_CLEAR_PATTERN</CODE>, <CODE>REQ_BACK_PATTERN</CODE>,
<CODE>REQ_NEXT_MATCH</CODE>, <CODE>REQ_PREV_MATCH</CODE>.  The latter
two are useful when pattern buffer input matches more than one item
in a multi-valued menu. <P>

Each successful scroll or item navigation request clears the pattern
buffer.  It is also possible to set the pattern buffer explicitly
with <CODE>set_menu_pattern()</CODE>. <P>

Finally, menu driver requests above the constant <CODE>MAX_COMMAND</CODE>
are considered application-specific commands.  The <CODE>menu_driver()</CODE>
code ignores them and returns <CODE>E_UNKNOWN_COMMAND</CODE>.

<H2><A NAME="mmisc">Miscellaneous Other Features</A></H2>

Various menu options can affect the processing and visual appearance
and input processing of menus.  See <CODE>menu_opts(3x) for
details.</CODE> <P>

It is possible to change the current item from application code; this
is useful if you want to write your own navigation requests.  It is
also possible to explicitly set the top row of the menu display.  See
<CODE>mitem_current(3x)</CODE>.

If your application needs to change the menu subwindow cursor for
any reason, <CODE>pos_menu_cursor()</CODE> will restore it to the
correct location for continuing menu driver processing. <P>

It is possible to set hooks to be called at menu initialization and
wrapup time, and whenever the selected item changes.  See
<CODE>menu_hook(3x)</CODE>. <P>

Each item, and each menu, has an associated user pointer on which you
can hang application data.  See <CODE>mitem_userptr(3x)</CODE> and
<CODE>menu_userptr(3x)</CODE>.

<H1><A NAME="form">The Forms Library</A></H1>

The <CODE>form</CODE> library is a curses extension that supports easy
programming of on-screen forms for data entry and program control. <P>

The <CODE>form</CODE> library first appeared in AT&amp;T System V.  The
version docu