fixed bug in mouse handling

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

diff --git a/docs/latex/wx/tstring.tex b/docs/latex/wx/tstring.tex
index 609ae9bfff5d49a74199c917bae6a146feefce5d..e57912e91a6541b202cdfff86e8f36232bcd2816 100644 (file)
--- a/docs/latex/wx/tstring.tex
+++ b/docs/latex/wx/tstring.tex
@@ -1,6 +1,6 @@
 \section{wxString overview}\label{wxstringoverview}
 
 \section{wxString overview}\label{wxstringoverview}
 

-Classes: \helpref{wxString}{wxstring}, \helpref{wxArrayString}{wxarray}, \helpref{wxStringTokenizer}{wxstringtokenizer}
+Classes: \helpref{wxString}{wxstring}, \helpref{wxArrayString}{wxarraystring}, \helpref{wxStringTokenizer}{wxstringtokenizer}

 
 \subsection{Introduction}
 
 
 \subsection{Introduction}
 


@@ -13,7 +13,7 @@ wxString only works with ASCII (8 bit characters) strings as of this release,
 but support for UNICODE (16 but characters) is planned for the next one.
 
 This class has all the standard operations you can expect to find in a string class:
 but support for UNICODE (16 but characters) is planned for the next one.
 
 This class has all the standard operations you can expect to find in a string class:

-dynamic memory management (string extends to accomodate new characters),
+dynamic memory management (string extends to accommodate new characters),

 construction from other strings, C strings and characters, assignment operators,
 access to individual characters, string concatenation and comparison, substring
 extraction, case conversion, trimming and padding (with spaces), searching and
 construction from other strings, C strings and characters, assignment operators,
 access to individual characters, string concatenation and comparison, substring
 extraction, case conversion, trimming and padding (with spaces), searching and


@@ -26,8 +26,9 @@ for a list of all functions.
 The advantages of using a special string class instead of working directly with
 C strings are so obvious that there is a huge number of such classes available.
 The most important advantage is the need to always
 The advantages of using a special string class instead of working directly with
 C strings are so obvious that there is a huge number of such classes available.
 The most important advantage is the need to always

-remember to allocate/free memory for C strings; working with fixed size buffers almost inevitably leads to buffer overflows).
-At last, C++ has a standard string class (std::string). So why the need for wxString?
+remember to allocate/free memory for C strings; working with fixed size buffers almost
+inevitably leads to buffer overflows. At last, C++ has a standard string class
+(std::string). So why the need for wxString?

 
 There are several advantages:
 
 
 There are several advantages:
 


@@ -59,8 +60,8 @@ wxString internally by wxWindows.
 However, there are several problems as well. The most important one is probably
 that there are often several functions to do exactly the same thing: for
 example, to get the length of the string either one of 
 However, there are several problems as well. The most important one is probably
 that there are often several functions to do exactly the same thing: for
 example, to get the length of the string either one of 

-\helpref{length()}{wxstringlength}, \helpref{Len()}{wxstringlen} or 
-\helpref{Length()}{wxstringLength} may be used. The first function, as almost
+length(), \helpref{Len()}{wxstringlen} or 
+\helpref{Length()}{wxstringlength} may be used. The first function, as almost

 all the other functions in lowercase, is std::string compatible. The second one
 is "native" wxString version and the last one is wxWindows 1.xx way. So the
 question is: which one is better to use? And the answer is that:
 all the other functions in lowercase, is std::string compatible. The second one
 is "native" wxString version and the last one is wxWindows 1.xx way. So the
 question is: which one is better to use? And the answer is that:


@@ -72,7 +73,7 @@ in both wxWindows and other programs (by just typedefing wxString as std::string
 when used outside wxWindows) and by staying compatible with future versions of
 wxWindows which will probably start using std::string sooner or later too.
 
 when used outside wxWindows) and by staying compatible with future versions of
 wxWindows which will probably start using std::string sooner or later too.
 

-In the situations where there is no correspondinw std::string function, please
+In the situations where there is no corresponding std::string function, please

 try to use the new wxString methods and not the old wxWindows 1.xx variants
 which are deprecated and may disappear in future versions.
 
 try to use the new wxString methods and not the old wxWindows 1.xx variants
 which are deprecated and may disappear in future versions.
 


@@ -137,18 +138,25 @@ string with a NULL) and are in general not very safe (passing NULL to them will
 probably lead to program crash). Moreover, some very useful functions are not
 standard at all. This is why in addition to all wxString functions, there are
 also a few global string functions which try to correct these problems: 
 probably lead to program crash). Moreover, some very useful functions are not
 standard at all. This is why in addition to all wxString functions, there are
 also a few global string functions which try to correct these problems: 

-\helpref{IsEmpty()}{wxstringisempty} verifies whether the string is empty (returning
-TRUE for NULL pointers), \helpref{Strlen()}{wxstringstrlen} also handles NULLs correctly
-and returns 0 for them and \helpref{Stricmp()}{wxstringstricmp} is just a
+\helpref{IsEmpty()}{IsEmpty} verifies whether the string is empty (returning
+TRUE for NULL pointers), \helpref{Strlen()}{Strlen} also handles NULLs correctly
+and returns 0 for them and \helpref{Stricmp()}{Stricmp} is just a

 platform-independent version of case-insensitive string comparison function
 known either as stricmp() or strcasecmp() on different platforms.
 
 platform-independent version of case-insensitive string comparison function
 known either as stricmp() or strcasecmp() on different platforms.
 

+The {\tt <wx/string.h>} header also defines \helpref{wxSnprintf}{wxsnprintf} 
+and \helpref{wxVsnprintf}{wxvsnprintf} functions which should be used instead
+of the inherently dangerous standard {\tt sprintf()} and which use {\tt
+snprintf()} instead which does buffer size checks whenever possible. Of
+course, you may also use \helpref{wxString::Printf}{wxstringprintf} which is
+also safe.
+

 There is another class which might be useful when working with wxString: 
 \helpref{wxStringTokenizer}{wxstringtokenizer}. It is helpful when a string must
 be broken into tokens and replaces the standard C library {\it
 strtok()} function.
 
 There is another class which might be useful when working with wxString: 
 \helpref{wxStringTokenizer}{wxstringtokenizer}. It is helpful when a string must
 be broken into tokens and replaces the standard C library {\it
 strtok()} function.
 

-And the very last string-related class is \helpref{wxArrayString}{wxarray}: it
+And the very last string-related class is \helpref{wxArrayString}{wxarraystring}: it

 is just a version of the "template" dynamic array class which is specialized to work
 with strings. Please note that this class is specially optimized (using its
 knowledge of the internal structure of wxString) for storing strings and so it is
 is just a version of the "template" dynamic array class which is specialized to work
 with strings. Please note that this class is specially optimized (using its
 knowledge of the internal structure of wxString) for storing strings and so it is


@@ -163,7 +171,7 @@ share the same data.
 
 But as soon as one of the two (or more) strings is modified, the data has to be
 copied because the changes to one of the strings shouldn't be seen in the
 
 But as soon as one of the two (or more) strings is modified, the data has to be
 copied because the changes to one of the strings shouldn't be seen in the

-otheres. As data copying only happens when the string is written to, this is
+others. As data copying only happens when the string is written to, this is

 known as COW.
 
 What is important to understand is that all this happens absolutely
 known as COW.
 
 What is important to understand is that all this happens absolutely


@@ -175,7 +183,7 @@ Probably the unique case when you might want to think about reference
 counting is when a string character is taken from a string which is not a
 constant (or a constant reference). In this case, due to C++ rules, the
 "read-only" {\it operator[]} (which is the same as 
 counting is when a string character is taken from a string which is not a
 constant (or a constant reference). In this case, due to C++ rules, the
 "read-only" {\it operator[]} (which is the same as 

-\helpref{GetChar()}{wxstringgetchar}) cannot be chosen and the "read/write"
+\helpref{GetChar()}{wxstringgetchar}) cannot be chosen and the "read/write" 

 {\it operator[]} (the same as 
 \helpref{GetWritableChar()}{wxstringgetwritablechar}) is used instead. As the
 call to this operator may modify the string, its data is unshared (COW is done)
 {\it operator[]} (the same as 
 \helpref{GetWritableChar()}{wxstringgetwritablechar}) is used instead. As the
 call to this operator may modify the string, its data is unshared (COW is done)


@@ -195,7 +203,7 @@ never arise because for constant references the correct operator is called autom
 absolutely not necessary to read for using wxString class. Please skip it unless
 you feel familiar with profilers and relative tools. If you do read it, please
 also read the preceding section about 
 absolutely not necessary to read for using wxString class. Please skip it unless
 you feel familiar with profilers and relative tools. If you do read it, please
 also read the preceding section about 

-\helpref{reference counting}{wxstringrefcounting}.}
+\helpref{reference counting}{wxstringrefcount}.}

 
 For the performance reasons wxString doesn't allocate exactly the amount of
 memory needed for each string. Instead, it adds a small amount of space to each
 
 For the performance reasons wxString doesn't allocate exactly the amount of
 memory needed for each string. Instead, it adds a small amount of space to each


@@ -251,7 +259,7 @@ which tells the wxString class to collect performance statistics and to show
 them on stderr on program termination. This will show you the average length of
 strings your program manipulates, their average initial length and also the
 percent of times when memory wasn't reallocated when string concatenation was
 them on stderr on program termination. This will show you the average length of
 strings your program manipulates, their average initial length and also the
 percent of times when memory wasn't reallocated when string concatenation was

-done but the alread preallocated memory was used (this value should be about
+done but the already preallocated memory was used (this value should be about

 98\% for the default allocation policy, if it is less than 90\% you should
 really consider fine tuning wxString for your application).
 
 98\% for the default allocation policy, if it is less than 90\% you should
 really consider fine tuning wxString for your application).