is most often used by the end user.
\item The \helpref{wxFileSystemHandler}{wxfilesystemhandler} is the core
of virtual file systems mechanism. You can derive your own handler and pass it to
-of the VFS mechanism. You can derive your own handler and pass it to
+the VFS mechanism. You can derive your own handler and pass it to
wxFileSystem's AddHandler() method. In the new handler you only need to
override the OpenFile() and CanOpen() methods.
\end{itemize}
with a list of possible file filters -- one for each wxDocTemplate. Selecting
the filter selects the wxDocTemplate, and when
a file is selected, that template will be used for creating a document
-and view. Under non-Windows platforms, the user will be prompted for
-a list of templates before the file selector is shown, since most file selectors
-do not allow a choice of file filters.
+and view.
For the case where an application has one document type and one view type,
a single document template is constructed, and dialogs will be appropriately
Returns \true if the thread is alive (i.e. started and not terminating).
-Note that this function can only be safely used with joinable threads, not
+Note that this function can only safely be used with joinable threads, not
detached ones as the latter delete themselves and so when the real thread is
-not alive any longer it is not possible to call this function neither because
-the wxThread object doesn't exist any more as well.
-
+no longer alive, it is not possible to call this function because
+the wxThread object no longer exists.
\membersection{wxThread::IsDetached}\label{wxthreadisdetached}
\wxheading{Purpose of wxStream}
-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
+Standard C++ streams can cause problems on several platforms:
+they work 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 wxWidgets because an application should
-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.
+Therefore, wxStreams have been added to wxWidgets so that applications can
+reliably compile and run on all supported platforms without dependence on a
+particular release of libg++.
wxStreams is divided in two main parts:
are really implemented by the "IO" classes.
wxInputStream and wxOutputStream inherit from it.
-wxStreamBuffer is a cache manager for wxStreamBase (it manages a stream buffer
-linked to a stream). One stream can have multiple stream buffers but one stream
+wxStreamBuffer is a cache manager for wxStreamBase: it manages a stream buffer
+linked to a stream. One stream can have multiple stream buffers but one stream
have always one autoinitialized stream buffer.
wxInputStream is the base class for read-only streams. It implements Read,
// What is my current position ?
off_t position = in_stream.TellI();
- // wxFileInputStream will close the file descriptor on the destruction.
+ // wxFileInputStream will close the file descriptor on destruction.
\end{verbatim}
-\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
-be difficult to implement it and it may be available in the fix of wxWidgets 2.0.
-
projects / wxWidgets.git / commitdiff
