window.tex

很牛的GUI源码wxWidgets-2.8.0.zip 可在多种平台下运行.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Name:        window.tex
%% Purpose:     wxWindow documentation
%% Author:      wxWidgets Team
%% Modified by:
%% Created:
%% RCS-ID:      $Id: window.tex,v 1.223 2006/12/04 11:19:30 VZ Exp $
%% Copyright:   (c) wxWidgets Team
%% License:     wxWindows license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{\class{wxWindow}}\label{wxwindow}

wxWindow is the base class for all windows and represents any visible object on
screen. All controls, top level windows and so on are windows. Sizers and
device contexts are not, however, as they don't appear on screen themselves.

Please note that all children of the window will be deleted automatically by
the destructor before the window itself is deleted which means that you don't
have to worry about deleting them manually. Please see the \helpref{window
deletion overview}{windowdeletionoverview} for more information.

Also note that in this, and many others, wxWidgets classes some
\texttt{GetXXX()} methods may be overloaded (as, for example,
\helpref{GetSize}{wxwindowgetsize} or
\helpref{GetClientSize}{wxwindowgetclientsize}). In this case, the overloads
are non-virtual because having multiple virtual functions with the same name
results in a virtual function name hiding at the derived class level (in
English, this means that the derived class has to override all overloaded
variants if it overrides any of them). To allow overriding them in the derived
class, wxWidgets uses a unique protected virtual \texttt{DoGetXXX()} method
and all \texttt{GetXXX()} ones are forwarded to it, so overriding the former
changes the behaviour of the latter.

\wxheading{Derived from}

\helpref{wxEvtHandler}{wxevthandler}\\
\helpref{wxObject}{wxobject}

\wxheading{Include files}

<wx/window.h>

\wxheading{Window styles}

The following styles can apply to all windows, although they will not always make sense for a particular
window class or on all platforms.

\twocolwidtha{5cm}%
\begin{twocollist}\itemsep=0pt
\twocolitem{\windowstyle{wxSIMPLE\_BORDER}}{Displays a thin border around the window. wxBORDER is the old name
for this style. }
\twocolitem{\windowstyle{wxDOUBLE\_BORDER}}{Displays a double border. Windows and Mac only.}
\twocolitem{\windowstyle{wxSUNKEN\_BORDER}}{Displays a sunken border.}
\twocolitem{\windowstyle{wxRAISED\_BORDER}}{Displays a raised border.}
\twocolitem{\windowstyle{wxSTATIC\_BORDER}}{Displays a border suitable for a static control. Windows only. }
\twocolitem{\windowstyle{wxNO\_BORDER}}{Displays no border, overriding the default border style for the window.}
\twocolitem{\windowstyle{wxTRANSPARENT\_WINDOW}}{The window is transparent, that is, it will not receive paint
events. Windows only.}
\twocolitem{\windowstyle{wxTAB\_TRAVERSAL}}{Use this to enable tab traversal for non-dialog windows.}
\twocolitem{\windowstyle{wxWANTS\_CHARS}}{Use this to indicate that
the window wants to get all char/key events for all keys - even for
keys like TAB or ENTER which are usually used for dialog navigation
and which wouldn't be generated without this style.  If you need to
use this style in order to get the arrows or etc., but would still like to have
normal keyboard navigation take place, you should create and send a
wxNavigationKeyEvent in response to the key events for Tab and
Shift-Tab.}
\twocolitem{\windowstyle{wxNO\_FULL\_REPAINT\_ON\_RESIZE}}{On Windows, this style used to disable repainting
the window completely when its size is changed. Since this behaviour is now the default, the style is now obsolete
and no longer has an effect.}
\twocolitem{\windowstyle{wxVSCROLL}}{Use this style to enable a vertical scrollbar.}
\twocolitem{\windowstyle{wxHSCROLL}}{Use this style to enable a horizontal scrollbar.}
\twocolitem{\windowstyle{wxALWAYS\_SHOW\_SB}}{If a window has scrollbars,
disable them instead of hiding them when they are not needed (i.e. when the
size of the window is big enough to not require the scrollbars to navigate it).
This style is currently implemented for wxMSW, wxGTK and wxUniversal and does
nothing on the other platforms.}
\twocolitem{\windowstyle{wxCLIP\_CHILDREN}}{Use this style to eliminate flicker caused by the background being
repainted, then children being painted over them. Windows only.}
\twocolitem{\windowstyle{wxFULL\_REPAINT\_ON\_RESIZE}}{Use this style to force
a complete redraw of the window whenever it is resized instead of redrawing
just the part of the window affected by resizing. Note that this was the
behaviour by default before 2.5.1 release and that if you experience redraw
problems with code which previously used to work you may want to try this.
Currently this style applies on GTK+ 2 and Windows only, and full repainting is always
done on other platforms.}
\end{twocollist}

See also \helpref{window styles overview}{windowstyles}.

\wxheading{Extra window styles}

The following are extra styles, set using \helpref{wxWindow::SetExtraStyle}{wxwindowsetextrastyle}.

\twocolwidtha{5cm}%
\begin{twocollist}\itemsep=0pt
\twocolitem{\windowstyle{wxWS\_EX\_VALIDATE\_RECURSIVELY}}{By default, Validate/TransferDataTo/FromWindow()
only work on direct children of the window (compatible behaviour). Set this flag to make them recursively
descend into all subwindows.}
\twocolitem{\windowstyle{wxWS\_EX\_BLOCK\_EVENTS}}{wxCommandEvents and the objects of the derived classes are forwarded to the
parent window and so on recursively by default. Using this flag for the
given window allows to block this propagation at this window, i.e. prevent
the events from being propagated further upwards. Dialogs have this
flag on by default.}
\twocolitem{\windowstyle{wxWS\_EX\_TRANSIENT}}{Don't use this window as an implicit parent for the other windows: this must
be used with transient windows as otherwise there is the risk of creating a
dialog/frame with this window as a parent which would lead to a crash if the
parent is destroyed before the child.}
\twocolitem{\windowstyle{wxWS\_EX\_PROCESS\_IDLE}}{This window should always process idle events, even
if the mode set by \helpref{wxIdleEvent::SetMode}{wxidleeventsetmode} is wxIDLE\_PROCESS\_SPECIFIED.}
\twocolitem{\windowstyle{wxWS\_EX\_PROCESS\_UI\_UPDATES}}{This window should always process UI update events,
even if the mode set by \helpref{wxUpdateUIEvent::SetMode}{wxupdateuieventsetmode} is wxUPDATE\_UI\_PROCESS\_SPECIFIED.}
\end{twocollist}

\wxheading{See also}

\helpref{Event handling overview}{eventhandlingoverview}\\
\helpref{Window sizing overview}{windowsizingoverview}

\latexignore{\rtfignore{\wxheading{Members}}}


\membersection{wxWindow::wxWindow}\label{wxwindowctor}

\func{}{wxWindow}{\void}

Default constructor.

\func{}{wxWindow}{\param{wxWindow*}{ parent}, \param{wxWindowID }{id},
 \param{const wxPoint\& }{pos = wxDefaultPosition},
 \param{const wxSize\& }{size = wxDefaultSize},
 \param{long }{style = 0},
 \param{const wxString\& }{name = wxPanelNameStr}}

Constructs a window, which can be a child of a frame, dialog or any other non-control window.

\wxheading{Parameters}

\docparam{parent}{Pointer to a parent window.}

\docparam{id}{Window identifier. If wxID\_ANY, will automatically create an identifier.}

\docparam{pos}{Window position. wxDefaultPosition indicates that wxWidgets
should generate a default position for the window. If using the wxWindow class directly, supply
an actual position.}

\docparam{size}{Window size. wxDefaultSize indicates that wxWidgets
should generate a default size for the window. If no suitable size can  be found, the
window will be sized to 20x20 pixels so that the window is visible but obviously not
correctly sized. }

\docparam{style}{Window style. For generic window styles, please see \helpref{wxWindow}{wxwindow}.}

\docparam{name}{Window name.}


\membersection{wxWindow::\destruct{wxWindow}}\label{wxwindowdtor}

\func{}{\destruct{wxWindow}}{\void}

Destructor. Deletes all subwindows, then deletes itself. Instead of using
the {\bf delete} operator explicitly, you should normally
use \helpref{wxWindow::Destroy}{wxwindowdestroy} so that wxWidgets
can delete a window only when it is safe to do so, in idle time.

\wxheading{See also}

\helpref{Window deletion overview}{windowdeletionoverview},\rtfsp
\helpref{wxWindow::Destroy}{wxwindowdestroy},\rtfsp
\helpref{wxCloseEvent}{wxcloseevent}


\membersection{wxWindow::AddChild}\label{wxwindowaddchild}

\func{virtual void}{AddChild}{\param{wxWindow* }{child}}

Adds a child window.  This is called automatically by window creation
functions so should not be required by the application programmer.

Notice that this function is mostly internal to wxWidgets and shouldn't be
called by the user code.

\wxheading{Parameters}

\docparam{child}{Child window to add.}


\membersection{wxWindow::CacheBestSize}\label{wxwindowcachebestsize}

\constfunc{void}{CacheBestSize}{\param{const wxSize\& }{size}}

Sets the cached best size value.


\membersection{wxWindow::CaptureMouse}\label{wxwindowcapturemouse}

\func{virtual void}{CaptureMouse}{\void}

Directs all mouse input to this window. Call \helpref{wxWindow::ReleaseMouse}{wxwindowreleasemouse} to
release the capture.

Note that wxWidgets maintains the stack of windows having captured the mouse
and when the mouse is released the capture returns to the window which had had
captured it previously and it is only really released if there were no previous
window. In particular, this means that you must release the mouse as many times
as you capture it, unless the window receives
the \helpref{wxMouseCaptureLostEvent}{wxmousecapturelostevent} event.

Any application which captures the mouse in the beginning of some operation
{\em must} handle \helpref{wxMouseCaptureLostEvent}{wxmousecapturelostevent}
and cancel this operation when it receives the event. The event handler must
not recapture mouse.

\wxheading{See also}

\helpref{wxWindow::ReleaseMouse}{wxwindowreleasemouse}
\helpref{wxMouseCaptureLostEvent}{wxmousecapturelostevent}


\membersection{wxWindow::Center}\label{wxwindowcenter}

\func{void}{Center}{\param{int}{ direction}}

A synonym for \helpref{Centre}{wxwindowcentre}.


\membersection{wxWindow::CenterOnParent}\label{wxwindowcenteronparent}

\func{void}{CenterOnParent}{\param{int}{ direction}}

A synonym for \helpref{CentreOnParent}{wxwindowcentreonparent}.


\membersection{wxWindow::CenterOnScreen}\label{wxwindowcenteronscreen}

\func{void}{CenterOnScreen}{\param{int}{ direction}}

A synonym for \helpref{CentreOnScreen}{wxwindowcentreonscreen}.


\membersection{wxWindow::Centre}\label{wxwindowcentre}

\func{void}{Centre}{\param{int}{ direction = wxBOTH}}

Centres the window.

\wxheading{Parameters}

\docparam{direction}{Specifies the direction for the centering. May be {\tt wxHORIZONTAL}, {\tt wxVERTICAL}\rtfsp
or {\tt wxBOTH}. It may also include {\tt wxCENTRE\_ON\_SCREEN} flag
if you want to center the window on the entire screen and not on its
parent window.}

The flag {\tt wxCENTRE\_FRAME} is obsolete and should not be used any longer
(it has no effect).

\wxheading{Remarks}

If the window is a top level one (i.e. doesn't have a parent), it will be
centered relative to the screen anyhow.

\wxheading{See also}

\helpref{wxWindow::Center}{wxwindowcenter}


\membersection{wxWindow::CentreOnParent}\label{wxwindowcentreonparent}

\func{void}{CentreOnParent}{\param{int}{ direction = wxBOTH}}

Centres the window on its parent. This is a more readable synonym for
\helpref{Centre}{wxwindowcentre}.

\wxheading{Parameters}

\docparam{direction}{Specifies the direction for the centering. May be {\tt wxHORIZONTAL}, {\tt wxVERTICAL}\rtfsp
or {\tt wxBOTH}.}

\wxheading{Remarks}

This methods provides for a way to center top level windows over their
parents instead of the entire screen.  If there is no parent or if the
window is not a top level window, then behaviour is the same as
\helpref{wxWindow::Centre}{wxwindowcentre}.

\wxheading{See also}

\helpref{wxWindow::CentreOnScreen}{wxwindowcenteronscreen}


\membersection{wxWindow::CentreOnScreen}\label{wxwindowcentreonscreen}

\func{void}{CentreOnScreen}{\param{int}{ direction = wxBOTH}}

Centres the window on screen. This only works for top level windows -
otherwise, the window will still be centered on its parent.

\wxheading{Parameters}

\docparam{direction}{Specifies the direction for the centering. May be {\tt wxHORIZONTAL}, {\tt wxVERTICAL}\rtfsp
or {\tt wxBOTH}.}

\wxheading{See also}

\helpref{wxWindow::CentreOnParent}{wxwindowcenteronparent}


\membersection{wxWindow::ClearBackground}\label{wxwindowclearbackground}

\func{void}{ClearBackground}{\void}

Clears the window by filling it with the current background colour. Does not
cause an erase background event to be generated.


\membersection{wxWindow::ClientToScreen}\label{wxwindowclienttoscreen}

\constfunc{virtual void}{ClientToScreen}{\param{int* }{x}, \param{int* }{y}}

\perlnote{In wxPerl this method returns a 2-element list instead of
modifying its parameters.}

\constfunc{virtual wxPoint}{ClientToScreen}{\param{const wxPoint\&}{ pt}}

Converts to screen coordinates from coordinates relative to this window.

\docparam{x}{A pointer to a integer value for the x coordinate. Pass the client coordinate in, and
a screen coordinate will be passed out.}

\docparam{y}{A pointer to a integer value for the y coordinate. Pass the client coordinate in, and
a screen coordinate will be passed out.}

\docparam{pt}{The client position for the second form of the function.}

\pythonnote{In place of a single overloaded method name, wxPython
implements the following methods:\par
\indented{2cm}{\begin{twocollist}
\twocolitem{{\bf ClientToScreen(point)}}{Accepts and returns a wxPoint}
\twocolitem{{\bf ClientToScreenXY(x, y)}}{Returns a 2-tuple, (x, y)}
\end{twocollist}}
}


\membersection{wxWindow::Close}\label{wxwindowclose}

\func{bool}{Close}{\param{bool}{ force = {\tt false}}}

This function simply generates a \helpref{wxCloseEvent}{wxcloseevent} whose
handler usually tries to close the window. It doesn't close the window itself,
however.

\wxheading{Parameters}

\docparam{force}{{\tt false} if the window's close handler should be able to veto the destruction
of this window, {\tt true} if it cannot.}

\wxheading{Remarks}

Close calls the \helpref{close handler}{wxcloseevent} for the window, providing
an opportunity for the window to choose whether to destroy the window.
Usually it is only used with the top level windows (wxFrame and wxDialog
classes) as the others are not supposed to have any special OnClose() logic.

The close handler should check whether the window is being deleted forcibly,
using \helpref{wxCloseEvent::CanVeto}{wxcloseeventcanveto}, in which case it
should destroy the window using \helpref{wxWindow::Destroy}{wxwindowdestroy}.

{\it Note} that calling Close does not guarantee that the window will be
destroyed; but it provides a way to simulate a manual close of a window, which
may or may not be implemented by destroying the window. The default
implementation of wxDialog::OnCloseWindow does not necessarily delete the
dialog, since it will simply simulate an wxID\_CANCEL event which is handled by
the appropriate button event handler and may do anything at all.

To guarantee that the window will be destroyed, call
\helpref{wxWindow::Destroy}{wxwindowdestroy} instead

\wxheading{See also}