Bold title for a topic :)
Well, I 've updated my local wx installation to wx2.6.2/unicode and fixed all minor incompatibilities.
Except for one thing:
int someint;
wxString astr;
wxString anotherstr;
astr << _T("aval"); // ok
astr << anotherstr; // ok
astr << someint; // *not* ok
I can't stream numbers to wxString :shock:
Anyone else has seen this? Knows a workaround?
The only workaround I found is using wxString::Format() instead of streams but this would mean scanning the entire source tree to find where integers are streamed to wxString and alter the code...
a little bit offtopic, but if you already moved to wx262, what happened to the splitpanel position problem? (the splitter position getting forgotten). Is that fixed already?
What happens if you change these defaults?:
// If enabled (1), compiles wxWidgets streams classes
#define wxUSE_STREAMS 1
// Use standard C++ streams if 1. If 0, use wxWin streams implementation only.
#define wxUSE_STD_IOSTREAM 0
// Enable conversion to standard C++ string if 1.
#define wxUSE_STD_STRING 0
The wxWidgets stream classes may have bugs.
Quote from: rickg22 on November 24, 2005, 06:36:08 PM
a little bit offtopic, but if you already moved to wx262, what happened to the splitpanel position problem? (the splitter position getting forgotten). Is that fixed already?
I 've fixed it for the classbrowser since lastweek.
I 'll fix it for open files list too.
Quote from: Takeshi Miya on November 24, 2005, 06:52:57 PM
What happens if you change these defaults?:
// If enabled (1), compiles wxWidgets streams classes
#define wxUSE_STREAMS 1
// Use standard C++ streams if 1. If 0, use wxWin streams implementation only.
#define wxUSE_STD_IOSTREAM 0
// Enable conversion to standard C++ string if 1.
#define wxUSE_STD_STRING 0
The wxWidgets stream classes may have bugs.
Thanks for the suggestion, but I would like not to tamper with wx settings.
First, because it 'd make the build process more difficult for new users.
Second, because most linux users will use the pre-built wx lib coming with their distro. We should not force them to build wx themselves, not to mention that C::B would never stand a chance to become a part of distros then...
Well, seems like I 'll have to dig through the code and replace those instances with wxString::Format()...
wxString::operator <<
wxString& operator <<(int i)
wxString& operator <<(float f)
wxString& operator <<(double d)
These functions work as C++ stream insertion operators: they insert the given value into the string. Precision or format cannot be set using them, you can use Printf for this.
--
Yiannis, mind explaining exactly why you can't use it? It throws a runtime error or what?
Errm, I suggest those settings only to test if it's a wxWidgets bug in the stream classes.
Quote from: rickg22 on November 24, 2005, 08:46:45 PM
Yiannis, mind explaining exactly why you can't use it? It throws a runtime error or what?
Nope, just it isn't actually added to the string:
wxString astr = "Test";
astr << 5;
astr == "Test", instead of "Test5"...
how about using the stl streams directly, should be portable ;
ostringstream class (things go into a sting buffer which can be requested at the end of all appending); ostringstream is just like cout, only everything get's into a strring.
But then again, you have to replace stuff, which you wanted to prevent doing in the first place ;-)
Yiannis: Mind giving us a particular filename / line no. ?
killerbot: that's why I'm saying to test with the STL streams instead of the wx streams. Only to know if it's a bug of wx or not.
#define wxUSE_STD_IOSTREAM 1
#define wxUSE_STD_STRING 1
Quote from: rickg22 on November 24, 2005, 11:53:36 PM
Yiannis: Mind giving us a particular filename / line no. ?
Sure. Here's the file I noticed the problem:
file: src/plugins/debuggergdb/gdb_commands.h
line: 189
m_Cmd << out << _T(":") << bp->line + 1;
Quote
m_Cmd << out << _T(":") << bp->line + 1;
Try this:
m_Cmd << out << _T(":") << (bp->line + 1);
Or this:
m_Cmd << out << _T(":");
m_Cmd << (bp->line + 1);
Or this:
(m_Cmd << out << _T(":")) << (bp->line + 1);
And tell us what happens.
Just curious, but does this work-around work?:
std::string str;
str << "Hi" << 5;
wxString str_new(_T(str));
Please notice that I've used default std::string for the first one.
(I cannot test it at the moment since I am at work.)
Morten.
Quote from: MortenMacFly on December 02, 2005, 12:19:16 PM
Just curious, but does this work-around work?:
std::string str;
str << "Hi" << 5;
wxString str_new(_T(str));
Please notice that I've used default std::string for the first one.
(I cannot test it at the moment since I am at work.)
Morten.
Using the STL is not an accepted solution...
just curious, why is STL not acceptable ??
Not portable with selection ansi/unicode ??
Quote from: killerbot on December 02, 2005, 01:09:42 PM
just curious, why is STL not acceptable ??
Not portable with selection ansi/unicode ??
For starters, STL is not enabled by default in wxWidgets configuration.
And even, if enabled, we 'd have tons of problems with wxWidgets and STL (tried it). Not to mention the unicode issues...
EDIT: don't get me wrong, in my own non-wx projects I use STL all the time. I don't know what I would have done without it ;)
Quote from: mandrav on December 02, 2005, 01:36:56 PM
EDIT: don't get me wrong, in my own non-wx projects I use STL all the time. I don't know what I would have done without it ;)
Sorry for the question, but what do you use instead of STL in your wx projects?
Thank you.
Best wishes,
Michael
And I can add: Sorry for the question :), but what are your non-wx projects? Something opensource?
Back on topic:
I've diff-compared the string related code from 2.6.1 and 2.6.2 and found nothing relevant. :?
Quote from: Takeshi Miya on December 02, 2005, 02:21:21 PM
And I can add: Sorry for the question :), but what are your non-wx projects? Something opensource?
Unfortunately, no :)
Quote from: Takeshi Miya on December 02, 2005, 02:21:21 PM
Back on topic:
I've diff-compared the string related code from 2.6.1 and 2.6.2 and found nothing relevant. :?
Yes, I know. It makes no sense at all...
Oh well... :| I guess there's nothing else we can do.
Quote from: MortenMacFly on December 02, 2005, 12:19:16 PM
Just curious, but does this work-around work?:
std::string str;
str << "Hi" << 5;
wxString str_new(_T(str));
Please notice that I've used default std::string for the first one.
(I cannot test it at the moment since I am at work.)
Morten.
That wont work because std::string doesn't have formatting -- you'd use a stringstream for that:
std::basic_stringstream<wxChar> ss;
ss << "Hi" << 5;
wxString str_new( ss.str() );
( because iostreams keep all the formatting information in istream and ostream, to avoid excessive duplication )
Note that I
do not think this would be a good solution.
Quote from: me22 on December 02, 2005, 04:46:26 PM
That wont work because std::string doesn't have formatting [...]
I know about that. This was a copy&paste mistake because I had posted this already in another thread using wxString instead of std::string. But i found out that this had already been tested in this thread...
I was hoping that nobody would realise... :oops: :oops: :oops:
Morten.
I'm not sure if thats so easy to do, but I would really appreciate if anyone could write down a "not nice but working" solution to this, a solution that I could just paste into that place in the file and make codeblocks usable until the right fix is found. I tried to convert that number to a string but I only know the basics of c++ and dont know anything about wx so it didnt work ;-). TIA
We could go the old QT <-> KDE relationship way and wrap our workaround in an extended wxString class. That way we wouldn't have to change wx internals, keeping distro makers and users happy. Just my 2 cents on the matter after reading this thread but no related code. Hope it inspires someone :)
I don't know if this helps, but from the wxWiKi:
Converting an integer to wxString
To convert, for example, an integer to a wxString, you can use several methods:
* wxString mynewstring = wxString::Format("%d", myoldinteger)
* wxString s; s.Printf("%d", myint);
* wxString mynewstring = wxString("") << myoldinteger;
If you're going straight into a text control, you can skip the conversion entirely: *textctrl << myint;
using the latest rocket engeeniering and the post above I developed this fix, I suppose its not the best solution, but if someone wants a working debugger with wx-2.6.2 and knows nothing about codeblocks it should be enough:
in /src/plugins/debuggergdb/gdb_commands.h , lines ~ 200 if (!m_BP->temporary)
m_Cmd << _T("break ");
else
m_Cmd << _T("tbreak ");
++ wxString s; s.Printf(_("%d"), m_BP->line + 1);
++ m_Cmd << out << _T(":") << s;
-- m_Cmd << out << _T(":") << m_BP->line + 1;
}
EDIT: the debugger is working now, a pity though it's not highlighting the actual line, nor any other line (breakpoint line, error line)
There shouldn't be any unicode issue with the STL.
there's wstring and string. wstring being the wide character version which is also capable of doing unicode.
Perhaps there is an issue with wxString?
Quote from: anonuser on December 10, 2005, 06:42:39 PM
There shouldn't be any unicode issue with the STL.
there's wstring and string. wstring being the wide character version which is also capable of doing unicode.
Perhaps there is an issue with wxString?
Unfortunatly, wstring is not guaranteed to be unicode =(
In fact, it basically never it, since to be unicode it's have to be UTF-32 ( otherwise you'd have surrogate troubles ) and I've never seen a numeric_limits<wchar_t>::digits large enough for that to be possible.
not according to the gnu standard. wchar must be 32 bits wide. http://www.gnu.org/software/libc/manual/html_node/Extended-Char-Intro.html for more info.
In http://forums.next.codeblocks.org/index.php?topic=1693.0 280Z28 might have stated a solution for the unicode problem. Look at this:
wxString str;
str.Printf(_T("MyString%d"), 5);
This should result in a unicode compatible "MyString5". Does this help?
Morten.
Quote from: me22 on December 10, 2005, 08:14:15 PMIn fact, it basically never it, since to be unicode it's have to be UTF-32 ( otherwise you'd have surrogate troubles ) and I've never seen a numeric_limits<wchar_t>::digits large enough for that to be possible.
On my FC4 box,
sizeof(wchar_t) says 4.
Actually making a u2s (unsigned int to string) function isn't that hard... just keep dividing over 10 and concatenating to a string (it produces a reversed number). Then you just reverse the elements and ta-da :)
a wchar_t will always hold a unicode character as long as you're going by GNU standards.
So there should be no problem.