--- In kicad-devel@xxxxxxxxxxxxxxx, Dick Hollenbeck <dick@...> wrote:
Wayne Stambaugh wrote:
emmedics4 wrote:
--- In kicad-devel@xxxxxxxxxxxxxxx, Wayne Stambaugh <stambaughw@>
Has anyone tried using the (const wxChar *) cast operator? I've been
using it in Printf and the logging function calls and it appears to work
fine. It is just a typedef for wxString::const_pointer but it returns
the correct character type depending on the character set used in
wxWidgets. I like it because it is reasonably descriptive and it
appears to work with most versions of wxWidgets. Using the example
above, it is used as follows:
s.Printf( wxT( "%s" ), (const wxChar*) formatMe );
It also works with the gettext _() macro.
Indeed but wxChar is going to be wiped in new versions, i think Dick was talking taking in consideration a more long term approach: changing code style to enhance code longevity and issues tomorrow.
Please take a look to:
http://docs.wxwidgets.org/trunk/overview_unicode.html#overview_unicode_pitfalls
http://docs.wxwidgets.org/trunk/classwx_string.html#conv
I did not read anywhere in these two links that wxChar is going away just that it's behavior is changing. In <http://docs.wxwidgets.org/trunk/overview_changes_since28.html#overview_changes_unicode>, I found this: "You also don't need to use wxChar any longer but can directly use the standard wchar_t type even if, again, wxChar continues to work". So I'm not sure what to think at this point. I'm going to work under the assumption that wxChar is going away which raises another problem. A quick grep of the code will show a lot of places where wxChar* is used a function parameter, function return value, or a variable. If wxChar goes away, then all this code will break. I will change wxChar* to wxString& as I find them.
Wayne
