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

Problems with FilesGroupsAndMasks::Save

<< < (2/7) > >>

grv575:

--- Quote from: Der Meister on December 26, 2005, 11:39:16 pm ---I'm not sure if this really would help because as far as I know this is not a general unicode problem but a Code::Blocks specific problem. wxString::operator <<(int) *does* work, even with unicode. Take a look at this example:
...
You see, it works.

--- End quote ---

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).  Now, using your example:


--- Code: ---void MyFrame::OnAbout(wxCommandEvent& event)
{
    int i = 50;
    wxString foo;
    foo << _("/file_groups/group") << i << _("/") << _("name");
    wxLogError(foo);
}

--- End code ---

And the i does not get handled properly:


[attachment deleted by admin]

280Z28:
I've posted patches for most instances of << with integers throughout Code::Blocks in individual patches by topic over at SF. :)

Eventually they'll be committed (as Thomas has time; right now he doesn't have a Unicode build to test on so he can't get to them).

In the meantime, Unicode users can manually apply the following patches:

brings gdb support back to the unicode build
http://sourceforge.net/tracker/index.php?func=detail&aid=1389953&group_id=126998&atid=707418

Syntax highlighting in the unicode build
http://sourceforge.net/tracker/index.php?func=detail&aid=1386025&group_id=126998&atid=707418

http://sourceforge.net/tracker/index.php?func=detail&aid=1385378&group_id=126998&atid=707418

grv575:
Maybe this illustrates the problem:


--- Code: ---    int i = 64;
    wxChar ch = i;
    wxString str = _(" ");
    str << ch;
    wxString foo;
    foo << _("/file_groups/group") << str << _("/") << _("name");
    wxLogError(foo);

--- End code ---

Produces (see below).

Now from that codeproject link:


--- Code: ---wchar_t problems

wchar_t is the type that is used for wide characters and is defined like this:

typedef unsigned short wchar_t ;

Unfortunately, because it is a typedef instead of a real C++ type, defining it like this has one serious flaw: you can't overload on it. Look at the following code:

TCHAR ch = _T('A') ;
tcout << ch << endl ;

Using narrow strings, this does what you would expect: print out the letter A. Using wide strings, it prints out 65. The compiler decides that you are streaming out an unsigned short and prints it out as a numeric value instead of a wide character. Aaargh!!! There is no solution for this other than going through your entire code base, looking for instances where you stream out individual characters and fix them. I wrote a little function to make it a little more obvious what was going on:

#ifdef _UNICODE
    // NOTE: Can't stream out wchar_t's - convert to a string first!
    inline std::wstring toStreamTchar( wchar_t ch )
            { return std::wstring(&ch,1) ; }
#else
    // NOTE: It's safe to stream out narrow char's directly.
    inline char toStreamTchar( char ch ) { return ch ; }
#endif // _UNICODE   

TCHAR ch = _T('A') ;
tcout << toStreamTchar(ch) << endl ;

--- End code ---

So... it looks like you can't directly stream wxChars... (it thinks they are shorts and just uses the ascii equivalent or somesuch...).


[attachment deleted by admin]

tiwag:
that's interesting, i tried this on my ubuntu 5.10 breezy with a CodeBlocks SVN r1595 (gcc 4.0.2,  wx-gtk-2.6.1 unicode)
and it doesn't show the problem, which you're discussing here...


[attachment deleted by admin]

thomas:

--- Quote from: grv575 on December 26, 2005, 10:41:13 pm ---This help?  Wide I/O streams
--- End quote ---

--- Quote from: grv575 on December 27, 2005, 06:21:28 am ---So... it looks like you can't directly stream wxChars... (it thinks they are shorts and just uses the ascii equivalent or somesuch...).
--- End quote ---
Well, we don't actually stream wide characters. What we do is, we invoke an overloaded operator. True, this happens to be the same operator that is used for streams, but that doesn't mean anything. We are only calling an (arbitrary) overloaded operator, which is just as good as if we were calling any other member function. So it really doesn't have to do with streams, it is a wxString bug.

Navigation

[0] Message Index

[#] Next page

[*] Previous page