define wxHAS_RAW_BITMAP (instead of inconsistenly named wxHAVE_RAW_BITMAP) and use...

[wxWidgets.git] / docs / changes.txt

diff --git a/docs/changes.txt b/docs/changes.txt
index f2bcd206b7101122afa1c037a8921c4563e76866..4c271ac1dbbaef603ef656177d94193c9c33de0b 100644 (file)
--- a/docs/changes.txt
+++ b/docs/changes.txt
@@ -5,6 +5,12 @@
 INCOMPATIBLE CHANGES SINCE 2.8.x
 ================================
 
+
+        Notice that these changes are described in more details in
+        the "Changes Since wxWidgets 2.8" section of the manual,
+        please read it if the explanation here is too cryptic.
+
+
 Unicode-related changes
 -----------------------
 
@@ -14,9 +20,10 @@ in the manual for more details but here are the most important incompatible
 changes:
 
 - Many wxWidgets functions taking "const wxChar *" have been changed to take
-  either "const wxString&" so that they accept both Unicode and ANSI strings.
-  and the argument can't be NULL or "const char *" if the strings are always
-  ANSI but may be NULL. This change is normally backwards compatible except:
+  either "const wxString&" (so that they accept both Unicode and ANSI strings;
+  the argument can't be NULL anymore in this case) or "const char *" (if the
+  strings are always ANSI; may still be NULL). This change is normally
+  backwards compatible except:
 
   a) Virtual functions: derived classes versions must be modified to take
      "const wxString&" as well to make sure that they continue to override the
@@ -121,14 +128,26 @@ Changes in behaviour which may result in compilation errors
   and has to be replaced with this:
      switch (str[i].GetValue()) { ... }
 
-- Return type of wxString::c_str() is now wxCStrData struct and not
-  const wxChar*. wxCStrData is implicitly convertible to const char* and
-  const wchar_t*, so this only presents a problem if the compiler cannot
-  convert the type. In particular, Borland C++ and DigitalMars compilers
-  don't correctly convert operator?: operands to the same type and fail with
-  compilation error instead. This can be worked around by explicitly casting
-  to const wxChar*:
-     wxLogError(_("error: %s"), !err.empty() ? (const wxChar*)err.c_str() : "")
+- Return type of wxString::c_str() is now a helper wxCStrData struct and not
+  const wxChar*. wxCStrData is implicitly convertible to both "const char *"
+  and "const wchar_t *", so this only presents a problem if the compiler cannot
+  apply the conversion. This can happen in 2 cases:
+  
+  + There is an ambiguity because the function being called is overloaded to
+    take both "const char *" and "const wchar_t *" as the compiler can't choose
+    between them. In this case you may use s.wx_str() to call the function
+    matching the current build (Unicode or not) or s.mb_str() or s.wc_str() to
+    explicitly select narrow or wide version of it.
+
+    Notice that such functions are normally not very common but unfortunately
+    Microsoft decided to extend their STL with standard-incompatible overloads
+    of some functions accepting "const wchar_t *" so you may need to replace
+    some occurrences of c_str() with wx_str() when using MSVC 8 or later.
+
+  + Some compilers, notably Borland C++ and DigitalMars, don't correctly
+    convert operator?: operands to the same type and fail with compilation
+    error instead. This can be worked around by explicitly casting to const
+    wxChar*: wxLogError(_("error: %s"), !err.empty() ? (const wxChar*)err.c_str() : "")
 
 - wxCtime() and wxAsctime() return char*; this is incompatible with Unicode
   build in wxWidgets 2.8 that returned wchar_t*.
@@ -142,7 +161,7 @@ Changes in behaviour which may result in compilation errors
 
 - Virtual wxHtmlParser::AddText() takes wxString, not wxChar*, argument now.
 
-- Functions that took wxChar* arguments that could by NULL in wxWidgets 2.8.
+- Functions that took wxChar* arguments that could by NULL in wxWidgets 2.8
   are deprecated and passing NULL to them won't compile anymore, wxEmptyString
   must be used instead.
 
@@ -163,6 +182,9 @@ Changes in behaviour which may result in compilation errors
   necessarily allocated consecutively any more. Use GetChildren() to find the
   next/previous control sibling instead.
 
+- Calling wxConfig::Write() with an enum value will fail to compile because
+  wxConfig now tries to convert all unknown types to wxString automatically.
+  The simplest solution is to cast the enum value to int.
 
 Deprecated methods and their replacements
 -----------------------------------------
@@ -248,7 +270,8 @@ All:
   wxQueueEvent() replacing wxPostEvent().
 - wxString now uses std::[w]string internally by default, meaning that it is
   now thread-safe if the standard library provided with your compiler is.
-- Added wxCmdLineParser::AddUsageText() (Marcin 'Malcom' Malich)
+- Added wxCmdLineParser::AddUsageText() (Marcin 'Malcom' Malich).
+- Fix reading/writing UTF-7-encoded text streams.
 
 All (Unix):
 
@@ -326,6 +349,7 @@ All (GUI):
 - Allow having menu separators with ids != wxID_SEPARATOR (Jeff Tupper)
 - Fix appending items to sorted wxComboCtrl after creation (Jaakko Salli)
 - Don't blit area larger than necessary in wxBufferedDC::UnMask (Liang Jian)
+- Fixed wxPixelData<wxImage> compilation (Leonardo Fernandes).
 
 wxGTK: