ugh. Nesting the (per class) plugin sentries can require them to

[wxWidgets.git] / docs / latex / wx / tstream.tex

diff --git a/docs/latex/wx/tstream.tex b/docs/latex/wx/tstream.tex
index 5709db71d80c56e6fdd53933c1176b6b355f1811..a472c2f0e1b3af936332430b0e2302fd3c1aba06 100644 (file)
--- a/docs/latex/wx/tstream.tex
+++ b/docs/latex/wx/tstream.tex
@@ -1,4 +1,4 @@
-\section{Streams in wxWindows overview}\label{wxstreamoverview}
+\section{wxStreams overview}\label{wxstreamoverview}

 
 Classes: \helpref{wxStreamBase}{wxstreambase},
  \helpref{wxStreamBuffer}{wxstreambuffer}, \helpref{wxInputStream}{wxinputstream},
 
 Classes: \helpref{wxStreamBase}{wxstreambase},
  \helpref{wxStreamBuffer}{wxstreambuffer}, \helpref{wxInputStream}{wxinputstream},


@@ -8,17 +8,18 @@ Classes: \helpref{wxStreamBase}{wxstreambase},
 
 \wxheading{Purpose of wxStream}
 
 
 \wxheading{Purpose of wxStream}
 

-We went into troubles with C++ std streams on several platforms:
-they react quite well in most cases, but in multi-threaded case, for example,
+We had troubles with standard C++ streams on several platforms:
+they react quite well in most cases, but in the multi-threaded case, for example,

 they have many problems. Some Borland Compilers refuse to work at all
 with them and using iostreams on Linux makes writing programs, that are
 binary compatible across different Linux distributions, impossible.
 
 Therefore, wxStreams have been added to wxWindows because an application should 
 they have many problems. Some Borland Compilers refuse to work at all
 with them and using iostreams on Linux makes writing programs, that are
 binary compatible across different Linux distributions, impossible.
 
 Therefore, wxStreams have been added to wxWindows because an application should 

-compile and run on all supported platforms and we don't want users depend on release
+compile and run on all supported platforms and we don't want users to depend on release

 X.XX of libg++ or some other compiler to run the program.
 
 wxStreams is divided in two main parts:
 X.XX of libg++ or some other compiler to run the program.
 
 wxStreams is divided in two main parts:

+

 \begin{enumerate}\itemsep=0pt
 \item the core: wxStreamBase, wxStreamBuffer, wxInputStream, wxOutputStream,
 wxFilterIn/OutputStream
 \begin{enumerate}\itemsep=0pt
 \item the core: wxStreamBase, wxStreamBuffer, wxInputStream, wxOutputStream,
 wxFilterIn/OutputStream


@@ -26,7 +27,7 @@ wxFilterIn/OutputStream
 \end{enumerate}
 
 wxStreamBase is the base definition of a stream. It defines, for example,
 \end{enumerate}
 
 wxStreamBase is the base definition of a stream. It defines, for example,

-the API of OnSysRead, OnSysWrite, OnSysSeek and OnSysTell. These functions are
+the API of OnSysRead, OnSysWrite, OnSysSeek and OnSysTell. These functions 

 are really implemented by the "IO" classes.
 wxInputStream and wxOutputStream inherit from it.
 
 are really implemented by the "IO" classes.
 wxInputStream and wxOutputStream inherit from it.
 


@@ -38,8 +39,8 @@ wxInputStream is the base class for read-only streams. It implements Read,
 SeekI (I for Input), and all read or IO generic related functions.
 wxOutputStream does the same thing but it is for write-only streams.
 
 SeekI (I for Input), and all read or IO generic related functions.
 wxOutputStream does the same thing but it is for write-only streams.
 

-wxFilterIn/OutputStream is base class definition for stream filtering.
-I mean by stream filtering, a stream which does no syscall but filter datas
+wxFilterIn/OutputStream is the base class definition for stream filtering.
+Stream filtering means a stream which does no syscall but filters data

 which are passed to it and then pass them to another stream.
 For example, wxZLibInputStream is an inline stream decompressor.
 
 which are passed to it and then pass them to another stream.
 For example, wxZLibInputStream is an inline stream decompressor.
 


@@ -50,7 +51,7 @@ wxStreamBuffer. This could also be a simple link to the a true syscall
 
 \wxheading{Generic usage: an example}
 
 
 \wxheading{Generic usage: an example}
 

-About its usage, it's simple. We can take the example of wxFileInputStream and here is a sample
+Usage is simple. We can take the example of wxFileInputStream and here is some sample

 code:
 
 \begin{verbatim}
 code:
 
 \begin{verbatim}


@@ -61,13 +62,13 @@ code:
 
  // Ok, read some bytes ... nb_datas is expressed in bytes.
  in_stream.Read(data, nb_datas);
 
  // Ok, read some bytes ... nb_datas is expressed in bytes.
  in_stream.Read(data, nb_datas);

- if (in_stream.LastError() != wxStream_NOERROR) {
+ if (in_stream.LastError() != wxSTREAM_NOERROR) {

    // Oh oh, something bad happens.
    // For a complete list, look into the documentation at wxStreamBase.
  }
 
  // You can also inline all like this.
    // Oh oh, something bad happens.
    // For a complete list, look into the documentation at wxStreamBase.
  }
 
  // You can also inline all like this.

- if (in_stream.Read(data, nb_datas).LastError() != wxStream_NOERROR) {
+ if (in_stream.Read(data, nb_datas).LastError() != wxSTREAM_NOERROR) {

    // Do something.
  }
 
    // Do something.
  }
 


@@ -84,7 +85,7 @@ code:
  // wxFileInputStream will close the file descriptor on the destruction.
 \end{verbatim}
 
  // wxFileInputStream will close the file descriptor on the destruction.
 \end{verbatim}
 

-\wxheading{Compatibility with c++ stream}
+\wxheading{Compatibility with C++ streams}

 
 As I said previously, we could add a filter stream so it takes an istream
 argument and builds a wxInputStream from it: I don't think it should 
 
 As I said previously, we could add a filter stream so it takes an istream
 argument and builds a wxInputStream from it: I don't think it should