Allow marking wxTreeBook nodes to expand initially in XRC.

[wxWidgets.git] / docs / doxygen / overviews / changes_since28.h

diff --git a/docs/doxygen/overviews/changes_since28.h b/docs/doxygen/overviews/changes_since28.h
index 73ea3787f113eff97b3701c3be2d0f79fb2f59ac..8ec1c9fc1e467464e7e057cb6d1490bfc4684b3f 100644 (file)
--- a/docs/doxygen/overviews/changes_since28.h
+++ b/docs/doxygen/overviews/changes_since28.h
@@ -4,7 +4,7 @@
 // Author:      Vadim Zeitlin
 // Created:     2008-05-08
 // RCS-ID:      $Id$
-// Licence:     wxWindows license
+// Licence:     wxWindows licence
 /////////////////////////////////////////////////////////////////////////////
 
 /**
@@ -61,6 +61,24 @@ to use, e.g.:
     OpenLogFile(s.mb_str());    // OK: always calls narrow string overload
     OpenLogFile(s.wc_str());    // OK: always calls wide string overload
 @endcode
+A common example of such problem arises with @c std::fstream class constructor
+in Microsoft Visual C++ standard library implementation. In addition to a
+constructor from @c const @c char * which this class must have, it also
+provides a constructor taking a wide character file name. Because of this, code
+like the following
+@code
+    #include <fstream>
+
+    void MyFunc(const wxString& filename)
+    {
+        std::ifstream ifs(filename.c_str());
+        ...
+    }
+@endcode
+does not compile when using Microsoft Visual C++ and needs to be changed to use
+mb_str() (which will not work for file names containing Unicode characters,
+consider using wxWidgets classes and functions to work with such file names as
+they are not supported by standard C++ library).
 
 The other class of incompatible changes is due to modifying some virtual
 methods to use @c wxString parameters instead of @c const @c wxChar* ones to
@@ -109,5 +127,60 @@ Finally, a few structure fields, notable @c wxCmdLineEntryDesc::shortName,
   your code if you overrode these functions and change the functions in the
   derived classes to use const reference as well.
 
+- Calling wxConfig::Write() with an enum value will fail to compile because
+  wxConfig now tries to convert all unknown types to wxString automatically
+  using wxToString() function.
+
+  The simplest solution is to cast the enum value to int, e.g.
+  @code
+    enum Colour { Red, Green, Blue };
+
+    wxConfig conf;
+    conf.Write("MyFavouriteColour", Red);       // ERROR: no match
+    conf.Write("MyFavouriteColour", int(Red));  // OK
+  @endcode
+
+  Another possibility which exists now is to provide an overload of
+  wxToString() (and wxFromString()) for your own type, e.g.
+
+  @code
+    wxString wxToString(Colour col)
+    {
+        return col == Red ? "R" : col == Green ? "G" : "B";
+    }
+
+    bool wxFromString(const wxString& s, Colour* col)
+    {
+        if ( s.length() != 1 )
+            return false;
+
+        switch ( s[0].GetValue() )
+        {
+            case 'R': *col = Red; return true;
+            case 'G': *col = Green; return true;
+            case 'B': *col = Blue; return true;
+        }
+
+        return false;
+    }
+  @endcode
+
+  Of course, this will change the format of the wxConfig output which may be
+  undesirable.
+
+- wxTE_AUTO_SCROLL style is deprecated as it's always on by default anyhow in
+  the ports which support it so you should simply remove any mentions of it
+  from your code.
+
+- If you use wxScrolled<T>::SetTargetWindow() you must override
+  wxScrolled<T>::GetSizeAvailableForScrollTarget() method to compute the size
+  available for the scroll target as function of the main window size, please
+  see the documentation of this method for more details.
+
+- Signatures of wxDataViewCustomRenderer::Activate(),
+  wxDataViewCustomRenderer::LeftClick() and
+  wxDataViewCustomRenderer::StartDrag() virtual methods changed.  You will need
+  to change them in your derived renderer class too if you override them.
+
 */