I'm compiling VERSION_1_0 on windows using Makefile.wx2.6 (just appended u suffix to wx libs and msw dir). It errors out when linking the new wxscintilla code. Can't find an ansi (const char*) version of a wxStringBase method in the wx dll (since it is compiled to use unicode strings). Not sure why this is happening, because wxscintilla seems to be able to handle unicode builds (going by the
#if wxUSE_UNICODE
#include "UniConversion.h"
in sdk/wxscintilla/src/PlatWX.cpp)
Screens:
(http://www.geocities.com/grv575/error.jpg)
(http://www.geocities.com/grv575/error2.jpg)
Ideas?
I haven't built the unicode system here (wx/codeblocks) yet, so I can't help much for now...
Maybe one of the other devs can?
Yiannis.
Are you using the correct wx/setup.h (that is, one that #defines wxUSE_UNICODE to 1)?
Wow, that's horrible. Thanks for the tip Urxae. Looks like wxWidgets defines wxUSE_UNICODE to 0 by default even when built as a unicode dll (citing windows9x compatibility). Recompiling now, but so far so good.
Another problem now. Looks like a unicode conversion issue. startherepage.cpp has:
wxString buf;
...
wxInputStream* is = f->GetStream();
char tmp[1024] = {};
while (!is->Eof() && is->CanRead())
{
memset(tmp, 0, sizeof(tmp));
is->Read(tmp, sizeof(tmp) - 1);
buf << tmp;
}
The error below. I don't know the proper way to convert the (char*) tmp buffer to wxString. Any unicode conversion devs know? (Or is the code really ok as is -- some other compilation problem?)
(http://www.geocities.com/grv575/error3.jpg)
Yeah, I did that. I 'm not fully aware of the new unicode conventions for the project (I was away) so another dev will correct this hopefully.
In the meantime you can comment this block of code out so that compilation goes on. You 'll only notice something strange in the "Start here" page :P
Yiannis.
I did:
buf << wxConvCurrent->cMB2WC(tmp);
Someone let me know if that's wrong (compiles ok).
Is the makefile working for the wxDockit compile:
Compiling resources...
mingw32-make: *** No rule to make target `..\wxDockit\lib\libwxdockit.a', needed
by `devel/codeblocks.exe'. Stop.
i also did a unicode build first, to see if everything works as expected,
and corrected it this way :
\src\src\startherepage.cpp:77
buf << _U((const char*)tmp);
and updated in cvs last night nearly midnight UTC (to version 1.4.2.3)
so it should be available for all of you to update from cvs.
a diff can be found here:
http://cvs.sourceforge.net/viewcvs.py/codeblocks/codeblocks/src/src/startherepage.cpp?r1=1.4.2.2&r2=1.4.2.3
Perfect thx. You have no idea how many casts I tried :)
It builds now. Running it looks ok except maybe the resources are odd (compile, rebuild buttons):
(http://www.geocities.com/grv575/compile_rebuild.jpg)
in my build even the buttons are displayed correctly,
there must be some (?) difference :lol: between our builds.
nevermind. it was a max path lengths problem. don't run update.bat from the desktop...
I changed to c:\codeblocks and resources zip fine.
crashes on exit and hovering over debug toolbar (step into, step over, stop debug, etc). maybe a tooltip bug.
Quote from: grv575 on August 22, 2005, 04:34:06 PM
...
crashes on exit and hovering over debug toolbar...
yeah, there are still a few bugs left 8)
Quote from: grv575 on August 22, 2005, 04:34:06 PM
nevermind. it was a max path lengths problem. don't run update.bat from the desktop...
I changed to c:\codeblocks and resources zip fine.
crashes on exit and hovering over debug toolbar (step into, step over, stop debug, etc). maybe a tooltip bug.
This crash is a wx2.6 bug which is addressed by patching wxWidgets. Go to www.wxwidgets.org and download the patch for wxMSW-2.6.1...
Yiannis.
I wish the wxwidgets guys would release wxMSW2.6.1-1 or something... having to patch the distros is awfully annoying.
Got a question: in the codeblocks.RPT stack trace I get:
0040138A C:\codeblocks\src\devel\codeblocks.exe:0040138A WinMain C:/codeblocks/src/src/app.cpp:297
but there is no WinMain @ 297, it's in the middle of a function:
if(m_ClearConf)
{
ClearConf();
return false;
} // line 297
ShowSplashScreen();
and the splash screen has already shown...
is this due to the BEGIN_EVENT_TABLE(CodeBlocksApp, wxApp) macros.. they throw line #s off?
Quote from: grv575 on August 22, 2005, 09:30:41 PM
is this due to the BEGIN_EVENT_TABLE(CodeBlocksApp, wxApp) macros.. they throw line #s off?
Welcome to macros hell...
That's one of the main reasons macros are evil. They bite and they bite hard :?
Yiannis.