Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml
A link to the unicode windows wxWidget dll for Code::Blocks : http://download.berlios.de/codeblocks/wxmsw26u_gcc_cb.7z
For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://download.berlios.de/codeblocks/mingwm10.7z
For support of ansi builds, a link to the ansi windows wxWidget dll for Code::Blocks : http://download.berlios.de/codeblocks/wxmsw26_gcc_cb.7z
The 28 March 2006 build is out.
- Windows : http://download.berlios.de/codeblocks/CB_20060328_rev2272_win32.7z
- Linux :
http://download.berlios.de/codeblocks/CB_20060328_rev2272_ubuntu.deb
http://download.berlios.de/codeblocks/CB_20060328_rev2272_fc4.rpm
Resolved Fixed:
- Keybinder: fixed uninitialized variable; fixed array overflow
- Fixed debugger not working with wx projects (debuggee would segfault)
- Fixed first debugger breakpoint not hitting
- Added printing option to print the line numbers or not
- Moved all common precompilation #includes in new file sdk_common.h. It is included by sdk.h and sdk_precomp.h
- Plugins SDK version pumped to 1.6.12
- Fixed printing line numbers to printout even when disabled in editor settings
- Fixed startup freeze bug when the splash screen was visible and an informational message popped-up (like a project file being upgraded)
- Under windows, the DDE server is always enabled (configuration removed from environment settings). The only way to disable the DDE server is by passing the command-line argument --no-dde, which suggests the user knows what he 's doing
- PlugInWizard : includes cleanup and use cbMessageBox
- DevPak-plugin
- bugfix: save *.entry files as ANSI (UTF8)
- use ConfigManager::GetConfigFolder() folder for mirrors and webupdate files
Regressions/Confirmed/Annoying/Common bugs:
- toolbar-images-not-changing-state (is a wx problem)
- there are several issues with Code Completion (is being redesigned : work in progress)
Hello killerbot,
This release has a lot of interesting corrections.
I will test it as soon as possible.
Thanks a lot and have a nice day.
eh....
how to install
I cover the whole folder
then cant open....
Quote from: aguai on March 29, 2006, 05:06:10 PM
eh....
how to install
I cover the whole folder
then cant open....
Sorry, but I have not fully understood your question/problems. Which are the errors/problems? What cannot open?
Best wishes,
Michael
Probably because he has no default.conf. C::B will not start up if you have no default.conf.
http://developer.berlios.de/bugs/?func=detailbug&bug_id=6829&group_id=5358
I can confirm with SVN revision from yesterday. Can't remeber which one it was......
Quote from: sethjackson on March 29, 2006, 05:53:11 PM
C::B will not start up if you have no default.conf.
I can't confirm this; this 28 March 2006 build starts up fine for me without a default.conf.
I have it with Version 1.0 revision 2274 (gcc 3.4.4 Windows/unicode, build: Mar 28 2006 14:05:04). :P
Fix is here.
http://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=969&group_id=5358
And what exactly does it fix?
The bug that you can't open C::B with no default.conf (C::B uses 99% CPU).
Ok patch was rejected. BUT I removed it from that header and it works perfectly. If that flag was in the header C::B use 99% CPU if I have no default.conf....
EDIT:
See here. I have the same problem AGAIN.
http://forums.next.codeblocks.org/index.php?topic=2608.msg20648#msg20648
Quote from: sethjackson on March 29, 2006, 08:53:30 PM
Ok patch was rejected. BUT I removed it from that header and it works perfectly. If that flag was in the header C::B use 99% CPU if I have no default.conf....
I originally removed that flag from the header, but left it there when updating to Ceniza's newest release of the splash screen class. It is a default parameter, so it was trivial to specify the correct parameter in
app.cpp. This way, we do not have a patched 3rd party component (which would cause problems every time we update it, again). We need not and we should not patch that header.
The flag is, however,
not related to the 99% CPU bug (this one was fixed by Yiannis independently). The flag was related to the message box lockout and later to the update event crash.
So why does removing the flag make the 99% CPU bug go away then? :? I'm not trying to be argumentative just wondering...... Umm so what is my problem? Why can I not start C::B without default.conf?
EDIT:
This build works fine without default.conf.... Unfortunately my version compiled from SVN doesn't. :P
Quote from: sethjackson on March 29, 2006, 09:03:44 PM
So why does removing the flag make the 99% CPU bug go away then? :? I'm not trying to be argumentative just wondering...... Umm so what is my problem? Why can I not start C::B without default.conf?
EDIT:
This build works fine without default.conf.... Unfortunately my version compiled from SVN doesn't. :P
I can confirm the 99% cpu bug is still present. I deleted my
*.conf, started CB. After choosing gcc at the compiler dlg, CB
went into a 99% cpu loop displaying the splash.
Thanks Pecan. At least I'm not alone in this big big world. :lol: Anyways I wonder how to fix it??
If I download the nightly (this one), then delete my default.conf, the nightly runs fine. However, my SVN version doesn't. :shock:
Well, look at app.cpp, line 575. Whatever is in that header, the default value is not used. Changing the default value in the header does not fix anything.
Yiannis was working on the startup problems yesterday afternoon, I thought he had fixed everything. Maybe there's more than one thing. Whatever it is, it is not the wxSTAY_ON_TOP flag, however. :)
Quote from: Pecan on March 29, 2006, 09:11:47 PM
I can confirm the 99% cpu bug is still present. I deleted my
*.conf, started CB. After choosing gcc at the compiler dlg, CB
went into a 99% cpu loop displaying the splash.
However, clearing the STAY_ON_TOP flag did not solve the problem.
sorry
pecan
I still wonder if those bugs are my fault...
The current implementation of cbSplashScreen is really close, almost the same, to that of wxSplashScreen. The main difference is cbSS paints over the frame and wxSS uses an extra Window to draw.
It is not your fault, we had similar problems with wxSplashScreen before, but worked around them ;)
Quote from: thomas on March 29, 2006, 09:24:35 PM
Well, look at app.cpp, line 575. Whatever is in that header, the default value is not used. Changing the default value in the header does not fix anything.
Yiannis was working on the startup problems yesterday afternoon, I thought he had fixed everything. Maybe there's more than one thing. Whatever it is, it is not the wxSTAY_ON_TOP flag, however. :)
Ok. Point taken. :D
This patch seems to have fixed the Splash loop on my XP
system with SVN 2290.
A statement in the wxWidgets book states that the paint
routine should always allocated a DC even if it doesn't do the paint.
This avoids a loop with the lib constantly calling the paint
routine.
I moved the DC allocation to the top of the routine so it was
allocated on every paint call and the hang went away.
Patch submitted.
Index: src/src/splashscreen.cpp
===================================================================
--- src/src/splashscreen.cpp (revision 2290)
+++ src/src/splashscreen.cpp (working copy)
@@ -22,12 +22,16 @@
void cbSplashScreen::OnPaint(wxPaintEvent &)
{
+ // an obscure statement in the wxWidgets book says to
+ // allocate the DC even if you don't paint to avoid
+ // a paint loop. //pecan 2006/04/3
+ wxPaintDC paint_dc(this); //pecan 2006/04/3
if (m_painted)
{
return;
}
- wxPaintDC paint_dc(this);
+ //-wxPaintDC paint_dc(this);
DoPaint(paint_dc);
m_painted = true; // paint once
}
thanks
pecan
Good catch. I was even considering to remove the "paint once" thingy from there.
I'll modify my SVN copy to reflect that so it can be updated from there.
Thanks :)