Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Problems with FilesGroupsAndMasks::Save

<< < (3/7) > >>

grv575:
Was not my point.  Look in string.h in the wx src.  The way wxChar is defined depends on settings in wx/setup.h, version of gcc being used & whether wchar_t is a real type or a typedef to unsigned short (as mentioned in that codeproject link).  Now if wxChar ends up resolving to an unsigned short instead of a real type then it will invoke the operator for an integral value and give you not what you want in Unicode builds:


--- Code: ---wxTextOutputStream& wxTextOutputStream::operator<<(wxUint16 c)
{
    wxString str;
    str.Printf(wxT("%u"), (unsigned int)c);
    WriteString(str);

    return *this;
}

--- End code ---

I'm guessing you can get the same behavior by doing str.Printf(wxt("%u")) to print an unsigned int and not a Unicode character.  Of course if you don't have wx_USEUNICODE defined it will use a different overload and conversion.


--- Code: ---#if wxUSE_UNICODE && wxWCHAR_T_IS_REAL_TYPE

wxTextOutputStream& wxTextOutputStream::operator<<(wchar_t wc)
{
    WriteString( wxString(&wc, m_conv, 1) );

    return *this;
}

#endif // wxUSE_UNICODE

--- End code ---

It looks like << just does a + operation where wxStrings are concatenated.  The source states that no conversion is done - use Printf() instead.  So converting from int / unsigned short to wxString is probably not done properly as you'd expect in Unicode mode.

grv575:
To clairify:

What

--- Code: ---  int i = 64;
    wxChar ch = i;
    wxString str = _(" ");
    str << ch;

--- End code ---

does is take the narrow integral value 64 and convert this to whatever 64 maps to for wide characters ('@').  It does not convert to 36 00 34 00 or whatever the wide character representation of the string "64" happens to be.

thomas:
But... make a new wxWidgets project and modify it like this:


--- Code: ---#include <stdio.h>
#include <typeinfo>
bool MyApp::OnInit()
{
printf("wchar_t %d\n", typeid(wchar_t) == typeid(wxChar));
printf("int %d\n", typeid(int) == typeid(wxChar));
printf("uint %d\n", typeid(unsigned int) == typeid(wxChar));
printf("char %d\n", typeid(char) == typeid(wxChar));
printf("uchar %d\n", typeid(unsigned char) == typeid(wxChar));
// MyFrame* frame = new MyFrame(0L, _("wxWidgets Application Template"));
// frame->Show();
return true;
}


Output non-Unicode:
wchar_t 0
int 0
uint 0
char 1
uchar 0

Output Unicode:
wchar_t 1
int 0
uint 0
char 0
uchar 0
--- End code ---

As you can see, wxChar does not map to unsigned short, but to wchar_t.

EDIT:
Furthermore, we are neither using wxTextOutputStream or anything, nor do we have to deal with wchar_t here at all.
What we use are these two overloaded operators:

wxString::wxString& operator<<(const wxChar *psz) { append(psz); return *this; }
wxString::wxString& operator<<(int i) { return (*this) << Format(_T("%d"), i); }
...
wxStringBase::wxStringBase& append(const wxChar *sz) { ConcatSelf(wxStrlen(sz), sz); return *this; }

...and that does not work for some reason.

thomas:
I modified wx/string.h to narrow the problem.

Look at this:


For some reason, Format() returns an empty string.

EDIT:
The really grotesque points to note are:
1. Format uses PrintfV internally. If you use Printf or PrintfV, it will work fine.
2. If you do someString << Format(_T("%d"), someInt), it will still work fine, but it does not inside string.h

Der Meister:

--- Quote from: grv575 on December 27, 2005, 05:31:10 am ---Don't think so.  Build CB unicode.  Run CB unicode and create a new wxWidgets project.  Set paths to use Unicode wx dll.  Edit wx/setup.h to have     #define wxUSE_UNICODE 1   (<-- essential).

--- End quote ---
Well, I have Code::Blocks build as unicode (you can see this in the first post) and I have build wxWidgets with unicode. And my wx/setup.h has already the #define you mentioned. And of course the paths are setup correct, I even checked that twice. This example works on my maschine.

If I did not have the problems within Code::Blocks, too, I would say it is a problem that occures only with some wxWidgets versions (I'm using wxGTK 2.6.1 (unicode build) on a gentoo linux) and not with all versions. And as some of you have problems with my little example it seems that this isn't just a problem of Code::Blocks. I have no idea what the reason for this problems is. Especially thomas' results are confusing. Maybe we should talk to some wxWidgets developers about this problems?

Navigation

[0] Message Index

[#] Next page

[*] Previous page