\subsection{Scroll subwindow sample}\label{samplescrollsub}
-This sample demonstrates the use of the \helpref{wxScrolledWindow}{wxscrolledwindow}
+This sample demonstrates the use of the \helpref{wxScrolledWindow}{wxscrolledwindow}
class including placing subwindows into it and drawing simple graphics. It uses the
\helpref{SetTargetWindow}{wxscrolledwindowsettargetwindow} method and thus the effect
of scrolling does not show in the scrolled window itself, but in one of its subwindows.
Eight HTML samples (you can find them in directory {\tt samples/html})
cover all features of HTML sub-library.
-{\bf Test} demonstrates how to create \helpref{wxHtmlWindow}{wxhtmlwindow}
+{\bf Test} demonstrates how to create \helpref{wxHtmlWindow}{wxhtmlwindow}
and also shows most of supported HTML tags.
{\bf Widget} shows how you can embed ordinary controls or windows within
{\bf Virtual} is yet another VFS demo. This one generates pages at run-time.
You may find it useful if you need to display some reports in your application.
-{\bf Printing} explains use of \helpref{wxHtmlEasyPrinting}{wxhtmleasyprinting}
+{\bf Printing} explains use of \helpref{wxHtmlEasyPrinting}{wxhtmleasyprinting}
class which serves as as-simple-as-possible interface for printing HTML
documents without much work. In fact, only few function calls are sufficient.
by wxWindows. When starting the program, you will see a frame with some
controls and some graphics. The controls will change their size whenever
you resize the entire frame and the exact behaviour of the size changes
-is determined using the \helpref{wxLayoutConstraints}{wxlayoutconstraints}
-class. See also the \helpref{overview}{constraintsoverview} and the
-\helpref{wxIndividualLayoutConstraint}{wxindividuallayoutconstraint}
+is determined using the \helpref{wxLayoutConstraints}{wxlayoutconstraints}
+class. See also the \helpref{overview}{constraintsoverview} and the
+\helpref{wxIndividualLayoutConstraint}{wxindividuallayoutconstraint}
class for further information.
The menu in this sample offers two more tests, one showing how to use
a \helpref{wxBoxSizer}{wxboxsizer} in a simple dialog and the other one
-showing how to use sizers in connection with a \helpref{wxNotebook}{wxnotebook}
+showing how to use sizers in connection with a \helpref{wxNotebook}{wxnotebook}
class. See also \helpref{wxNotebookSizer}{wxnotebooksizer} and
\helpref{wxSizer}{wxsizer}.
The sockets sample demonstrates how to use the communication facilities
provided by \helpref{wxSocket}{wxsocketbase}. There are two different
-applications in this sample: a server, which is implemented as a
-\helpref{wxSocketServer}{wxsocketserver} object, and a client, which is
-implemented with \helpref{wxSocketClient}{wxsocketclient}.
-
-The server binds to the local address, using TCP port number 3000, sets
-up an event handler to be notified of incoming connection requests
-({\bf wxSOCKET\_CONNECTION} event), and stands there, waiting (listening
-in the socket parlance) for clients. For each incoming client, a new
-\helpref{wxSocketBase}{wxsocketbase} object is created, which represents
-the connection. Connections are independent from the server that created
-them, so they set up their own event handler, and stay awaiting for
-{\bf wxSOCKET\_INPUT} (incoming data) or {\bf wxSOCKET\_LOST} (connection
-closed at the remote end) events. This event handler is the same for all
-connections, and demonstrates how to determine which socket the event
-is addressed to by using the \helpref{Socket}{wxsocketeventsocket} function
-in the \helpref{wxSocketEvent}{wxsocketevent} class.
+applications in this sample: a server, which is implemented using a
+\helpref{wxSocketServer}{wxsocketserver} object, and a client, which
+is implemented as a \helpref{wxSocketClient}{wxsocketclient}.
+
+The server binds to the local address, using TCP port number 3000,
+sets up an event handler to be notified of incoming connection requests
+({\bf wxSOCKET\_CONNECTION} events), and stands there, waiting for clients
+({\it listening} in the socket parlance). For each accepted connection,
+a new \helpref{wxSocketBase}{wxsocketbase} object is created. These
+socket objects are independent from the server that created them, so
+they set up their own event handler, and then request to be notified
+of {\bf wxSOCKET\_INPUT} (incoming data) or {\bf wxSOCKET\_LOST}
+(connection closed at the remote end) events. In the sample, the event
+handler is the same for all connections; to find out which socket the
+event is addressed to, the \helpref{GetSocket}{wxsocketeventgetsocket}
+function is used.
Although it might take some time to get used to the event-oriented
system upon which wxSocket is built, the benefits are many. See, for
TCP port number is hard-coded as 3000). Once connected, a number of
tests are possible. Currently, three tests are implemented. They show
how to use the basic IO calls in \helpref{wxSocketBase}{wxsocketbase},
-such as \helpref{Read}{wxsocketbaseread}, \helpref{Write}{wxsocketbasewrite},
+such as \helpref{Read}{wxsocketbaseread}, \helpref{Write}{wxsocketbasewrite},
\helpref{ReadMsg}{wxsocketbasereadmsg} and \helpref{WriteMsg}{wxsocketbasewritemsg},
and how to set up the correct IO flags depending on what you are going to
-do. See the comments in the code for more information (a lengthy explanation
-on socket flags is available in \helpref{SetFlags}{wxsocketbasesetflags}).
-Note that because both clients and connection objects in the server set
-up an event handler to catch {\bf wxSOCKET\_LOST} events, each one is
-immediately notified if the other end closes the connection.
+do. See the comments in the code for more information. Note that because
+both clients and connection objects in the server set up an event handler
+to catch {\bf wxSOCKET\_LOST} events, each one is immediately notified
+if the other end closes the connection.
-There is also an URL test which demonstrates how to use the \helpref{wxURL}{wxurl}
-class.
+There is also an URL test which shows how to use the \helpref{wxURL}{wxurl}
+class to fetch data from a given URL.
-The sockets sample is work in progress. Coming soon:
+The sockets sample is work in progress. Some things to do:
\begin{itemize}\itemsep=0pt
\item More tests for basic socket functionality.
\item More tests for protocol classes (wxProtocol and its descendants).
-\item Tests for the recently added datagram socket classes.
+\item Tests for the recently added (and still in alpha stage) datagram sockets.
\item New samples which actually do something useful (suggestions accepted).
\end{itemize}
keys, you can test some actions in the text ctrl as well as get statitics on the
text ctrls, which is useful for testing if these statitics actually are correct.
-Thirdly, on platforms which support it, the sample will offer to copy text to the
+Thirdly, on platforms which support it, the sample will offer to copy text to the
\helpref{wxClipboard}{wxclipboard} and to paste text from it. The GTK version will
use the so called PRIMARY SELECTION, which is the pseudo clipboard under X and
best known from pasting text to the XTerm program.
access the GUI class simultaneously. One way to prevent that is have a normal
GUI program in the main thread and some worker threads which work in the
background. In order to make communication between the main thread and the
-worker threads possible, wxWindows offers the \helpref{wxPostEvent}{wxpostevent}
+worker threads possible, wxWindows offers the \helpref{wxPostEvent}{wxpostevent}
function and this sample makes use of this function.
-The other way to use a so called Mutex (such as those offered in the \helpref{wxMutex}{wxmutex}
+The other way to use a so called Mutex (such as those offered in the \helpref{wxMutex}{wxmutex}
class) that prevent threads from accessing the GUI classes as long as any other
-thread accesses them. For this, wxWindows has the \helpref{wxMutexGuiEnter}{wxmutexguienter}
+thread accesses them. For this, wxWindows has the \helpref{wxMutexGuiEnter}{wxmutexguienter}
and \helpref{wxMutexGuiLeave}{wxmutexguileave} functions, both of which are
used and tested in the sample as well.