Updated some bits in socket docs.
Documented socket samples Moved wxInitAllImageHandlers from 'file functions' (?) to 'misc functions' git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@5643 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
@@ -239,6 +239,61 @@ specifying the foreground and background colours with
|
||||
bitmap is then converted to a wxImage and the foreground colour (black) is
|
||||
replaced with red using \helpref{wxImage::Replace}{wximagereplace}.
|
||||
|
||||
\subsection{Sockets sample}\label{samplesockets}
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
example, that the server application, while being single-threaded
|
||||
(and of course without using fork() or ugly select() loops) can handle
|
||||
an arbitrary number of connections.
|
||||
|
||||
The client starts up unconnected, so you can use the Connect... option
|
||||
to specify the address of the server you are going to connect to (the
|
||||
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},
|
||||
\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.
|
||||
|
||||
The sockets sample is work in progress. Coming soon:
|
||||
|
||||
\begin{itemize}
|
||||
|
||||
\item More tests for basic socket functionality.
|
||||
|
||||
\item Tests for the recently added datagram socket classes.
|
||||
|
||||
\item Tests for protocol classes (wxProtocol and its descendants).
|
||||
|
||||
\item New samples which actually do something useful (suggestions accepted).
|
||||
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Text sample}\label{sampletext}
|
||||
|
||||
This sample demonstrates four features: firstly the use and many variants of
|
||||
|
Reference in New Issue
Block a user