don't use _T() inside wxGetTranslation() and related macros (wxTRANSLATE, _, ...) to preserve compatibility with the old ASCII build (even at the expense with the Unicode build compatibility)

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@48603 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Vadim Zeitlin
2007-09-07 21:47:45 +00:00
parent 066f3611df
commit e6d4038a8b
8 changed files with 45 additions and 31 deletions

View File

@@ -5,6 +5,23 @@
INCOMPATIBLE CHANGES SINCE 2.8.x
================================
Unicode-related changes
-----------------------
The biggest changes in wxWidgets 3.0 are the changes due to the merge of the
old ANSI and Unicode build modes in a single build. See the Unicode overview
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&" if they should accept both Unicode or ANSI strings
and the argument can't be NULL or "const char *" if the strings are always
ANSI but may be NULL.
- Some structure fields have been changed from "wxChar *" to "char *" too:
e.g. wxCmdLineEntryDesc fields.
Changes in behaviour not resulting in compilation errors, please read this!
---------------------------------------------------------------------------

View File

@@ -1801,11 +1801,9 @@ build. In fact, its definition is:
\func{const wxChar *}{wxTRANSLATE}{\param{const char *}{s}}
This macro doesn't do anything in the program code -- it simply expands to the
value of its argument (except in Unicode build where it is equivalent to
\helpref{wxT}{wxt} which makes it unnecessary to use both wxTRANSLATE and wxT
with the same string which would be really unreadable).
value of its argument.
However it does have a purpose and it is to mark the literal strings for the
However it does have a purpose which is to mark the literal strings for the
extraction into the message catalog created by {\tt xgettext} program. Usually
this is achieved using \helpref{\_()}{underscore} but that macro not only marks
the string for extraction but also expands into a
@@ -1820,7 +1818,7 @@ translated (note that it is a bad example, really, as
day names already). If you write
\begin{verbatim}
static const wxChar * const weekdays[] = { _("Mon"), ..., _("Sun") };
static const char * const weekdays[] = { _("Mon"), ..., _("Sun") };
...
// use weekdays[n] as usual
\end{verbatim}
@@ -1829,7 +1827,7 @@ the code wouldn't compile because the function calls are forbidden in the array
initializer. So instead you should do
\begin{verbatim}
static const wxChar * const weekdays[] = { wxTRANSLATE("Mon"), ..., wxTRANSLATE("Sun") };
static const char * const weekdays[] = { wxTRANSLATE("Mon"), ..., wxTRANSLATE("Sun") };
...
// use wxGetTranslation(weekdays[n])
\end{verbatim}
@@ -1841,6 +1839,7 @@ wxTRANSLATE() in the above, it wouldn't work as expected because there would be
no translations for the weekday names in the program message catalog and
wxGetTranslation wouldn't find them.
\membersection{::wxVsnprintf}\label{wxvsnprintf}
\func{int}{wxVsnprintf}{\param{wxChar *}{buf}, \param{size\_t }{len}, \param{const wxChar *}{format}, \param{va\_list }{argPtr}}