admin April 13th, 2009
To update all I have committed patch in trunk (in revision 5334). It should be available with the next nightly.
To run Code::Blocks portably you can write a batch file, set APPDATA variable to any directory you want and then launch Code::Blocks.
Alternatively you can download the CbLauncher v0.1.1 from my blog to run Code::Blocks portably.
Steps to use Cblauncher: Continue Reading »
Biplab April 5th, 2009
Recently I was irritated by the fact that Code::Blocks is not truly portable on Windows. Usually I keep two versions of Code::Blocks in my PC. One is the last released nightly and the other one is the one that I build from trunk. I use last released nightly to write code. However as Code::Blocks is not truly portable, these two versions of Code::Blocks share same configuration file. Sometimes I run my newly built Code::Blocks from trunk, it crashes and corrupts my customised configuration file. And this irritates me a lot.
Other than this, you really can’t copy your configuration folder in a portable drive and expect entire Code::Blocks installation to behave as a truly portable software. There is one way; using personality feature of Code::Blocks. but that solves only one half of the problem. Yes, this makes your Code::Blocks portable. But your plugins are not! They still read their own settings from the default folder which is %APPDATA%\CodeBlocks folder. Continue Reading »
Biplab June 23rd, 2008
A nasty bug was discovered by one of our user couple of months ago. The bug was affecting our last stable release as well as our latest nightly.
The bug was due to the way a file was being saved by C::B to avoid corrupting the existing file. C::B used to write the new contents to a temporary file before deleting the old one and then renaming the temp file to new file. But this created a bug as the temporary file may/may not get the file permission attributes of the original. Continue Reading »
Biplab October 26th, 2007
Code::Blocks (C::B) had a long known problem of crashing / locking up while an accented character is used in the code. Or even worse when the encoding of a file is changed from one encoding to another. It was able to support upto UTF-8 encoding with occasional lock-up.
I started working on this around 2-3 months back. But during testing we found that C::B still hangs and it is due to Code-Completion (CC) plugin. The issue was due to the presence of some ANSI functions in Code-Completion parser. Morten then started his work to fix this. It almost resulted to a small re-write of Code-Completion. And we could finally test our Unicode changes with CC enabled.
We tested it for couple of weeks before we found it to be stable enough for further real-life testing by our users. In revision 4548, the first collection of patches were committed (including Morten’s patch on CC). Few users posted some issues which were then quickly resolved. As of writing, the code seems to be quite stable.
So what are the changes that have been made??
There were a number of changes that has been made.
- Encoding detection code has been improved by using a portion of MadEdit’s encoding detection code. Currently it can detect, UTF-8, UTF-16 BE/LE, UTF-32 BE/LE with/without BOM. The fall back code has been kept to ANSI (CP-1252 on Windows).
- Encoding conversion routine has been overhauled. Now it converts back and forth all supported encodings flawlessly.
- Now all the encoding detection and conversion code is much more efficient as it involves minimum disk reads and most of the operation is done in memory buffers (Thanks Thomas for keeping this strict criteria).
- The file load routine has been moved from a all in one load-plus-encoding detection code to efficiently distributed code.
- File save routine was overhauled to save files with all supported encodings.
- Project load routine has been tweaked to reduce the stalling while opening a large project with a large number of open files in it.
- Morten made CC parser Unicode compliant so that it can now parse any files without a single lock-up.
I would request users to use Build Revision 4553 onwards to get the most benefit out of it. Please post any related issues in the forum itself.
Biplab May 25th, 2007
wxWidgets (wx) 2.8.4 has been released recently. Since Code::Blocks was switched to wx 2.8.x series wx-2.8.3 runtime dll was being used on Windows. But wx 2.8.3 had some serious issues which were crippling some of the features of Code::Blocks on Windows and as well as on Linux. Well let me explain them.
On Windows, the pop-up menu were not responding to clicks. This became an annoying issue for Code::Blocks as a major portion of pop-up menus were not working. This bug existed in wx-2.8.3 and has been fixed in wx-2.8.4.
So if you are facing such issue where the Pop-Up menus are not working, just upgrade to wx-2.8.4. A link to a new DLL is now available with the Nightly Build links. Please check the Code::Blocks forum for the link.
On Linux the issue was quite serious, though. There is a bug in wx-2.8.3 in which an application may run into an endless loop if a statictext control is added to menu. This issue was making Code::Blocks to hang-at-start-up. So if your Code::Blocks installation is showing such weird behaviour, it’s time to upgrade.
For Linux, you need to upgrade on your own. As such no wxGTK runtime will be provided by Code::Blocks team (including me). You may build it on your own or can check wxWidgets website’s Download section.
So if you face any of these two issues, please don’t file a bug-report. Rather update wxWidgets runtime.
Signing off today.
Biplab May 4th, 2007
Hello all,
The wxWidgets Wizard of Code::Blocks have been updatd recently. In this article I’ll explain the changes that I’ve committed.
Earlier wizard had two pages to add additional libraries in Non-Monolithic build of wxWidgets in Windows. Now those two pages have been changed to a more user-friendly one page list. All the libraries are now available as a single list and selecting them is also easier. Please see the following screenshot for more details.

Another important update has been committed in the wizard. Wizard is now able to add additional dependencies if you’ve forgot to add them in your project. This would be helpful in resolving linking errors due to missing dependencies.
In past couple of months, several users requested to add support for a wxWidgets target addition. In this update I’ve added that, too. Now you’ll be able to add a target to an existing project even with a different compiler and configuration.
To use this, please click File > New > Build target menu. Now you’ll see the following screen.

Select wxWidgets from the list and the target wizard will start. Now follow the steps in the wizard and use appropriate settings. The wizard will create a New target for you.
Please note that to add a new target, a project should be open in Code::Blocks.
Hopefully you’ll find this new addition to be useful.
Regards,
Biplab
Biplab April 12th, 2007
Hi All,
Posting after a long time. Got busy with studies and coding.
Last month wxWidgets-2.6.4 was released. This is primarily a bug-fix release. Though newer releases are already available, a number of projects are still using wxWidgets 2.6.x for their projects. Code::Blocks is one such example.
Since it’s release I’ve been compiling Code::Blocks with it to find out any issues. The first issue that I noticed was incorrect File-type icons in Code::Blocks. All the icons that C::B associates with different file types were getting mangled after I compiled it with wxWidgets-2.6.4.
Finally the bug has been found out and the fix is pretty easy. Just apply the following patch to wx.rc file.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| --- C:/wxWidgets-2.6.4/include/wx/msw/wx.rc Mon Mar 26 18:15:59 2007
+++ C:/wxWidgets-2.6.4/include/wx/msw/wx.rc Mon Mar 26 18:17:13 2007
@@ -79,7 +79,7 @@// Low alphabetically to make it the default, but not so low as to
// affect applications that use 'a'
-bICON ICON "wx/msw/std.ico"
+//bICON ICON "wx/msw/std.ico"
//////////////////////////////////////////////////////////////////////////////
// |
With this new wx code, an additional Icon was getting inserted into the exe file which was screwing up the associated icons.
Is it reported to wx-dev team? Answer is No and not necessary. This bug has been fixed in wx 2.8.x code. But unfortunately, the buggy code came with wxWidgets 2.6.4.
So if you want to compile Code::Blocks or any other app with wxWidgets 2.6.4, then please pay attention to this bug. Or otherwise it may haunt you for no reasons.
Another bug that has been noticed in Code::Blocks after switching to wx 2.6.4 is that it’s Find and Replace dialogs are now not responding to Escape key!
This bug is new and still not confirmed whether it’s an issue with wxWidgets 2.6.4 or Code::Blocks code. As far as I’m concerned, I’m quite sure that C::B code is not responsible for this.
I’m presently working on this to see if this can be fixed or not.
Hope this unofficial bug report and it’s fix will help you.
Biplab March 7th, 2007
Hello Everybody,
This week I’m posting wxWidgets Wizard update alongwith a number of other feature improvements that has been added in Code::Blocks.
A number of users had complained about the support of OpenWatcom in Code::Blocks. The support was there but it was broken as it was written quite a while ago. Thus I rewrote some of the parts to improve the support. Now it has been tested with OpenWatcom 1.6 and found to be working perfectly with different types of projects.
After improving OpenWatcom support the goal was set to make the wxWidgets Wizard compatible with OpenWatcom. It has been updated to work with latest OpenWatcom release. I’ve personally tested it with OpenWatcom 1.6 and found to be working perfectly. OpenWatcom support for wxWidgets Wizard has been added in Revision 3660.
Till date if anyone wishes to develop wxWidgets based application with OpenWatcom makefile was the only option. Latest Nightlies of Code::Blocks have changed the equation. The OpenWatcom support is also available in 3rd-Party GUI builder integration part of wxWidgets Wizard.
One feature is presently lacking in OpenWatcom support in wizard. It does not support PCH files. But soon this limitation will be resolved.
Another interesting feature addition to wizard is support for wxSmith, the default GUI builder in Code::Blocks. I’m thankful to Byo for his support making the integration possible.
I hope you’ll all find the latest changes more interesting and useful.
Thanks for visiting the Blog. Please visit again for more updates.
Biplab February 28th, 2007
An interesting feature has been added in the wxWidgets Project Wizard of Code::Blocks. Support for external GUI builder. Presently wxFormBuilder is supported. Code::Blocks also comes with an integrated GUI builder named wxSmith. Next release of this wizard will be focusing on integrating wxSmith.
So what more user need to do to enable this feature? Truly speaking, not much. User have to select an option which asks which GUI builder to use (See the following screenshot for more details). There is another option to generate either wxDialog based or wxFrame based app.

Screenshot showing GUI builder selection page
Selecting No GUI Builder will create an working project with sample code.
Changelog:
- Wizard now supports creation of wxDialog / wxFrame based app.
- Wizard now supports wxFormBuilder to be selected as 3rd-Party GUI Builder alongwith wxDialog / wxFrame option.
- PCH include header has been reverted to wx_pch.h and PCH Pre-Processor definition is changed to WX_PRECOMP
- EVT_CLOSE has been added in all templates to ensure proper exit.
The new wizard will be available from Revision 3645 onwards and it has been released with 26th February 2007 Nightly Release. Download it from -
http://forums.codeblocks.org/index.php/topic,5289.0.html
Biplab February 22nd, 2007
Hello Everybody,
There has been couple of significant changes to wxWidgets project wizard of Code::Blocks. The update will help advanced users who want to debug their application in Debug mode but linking with Release library of wxWidgets. Yes! this is now possible but only for GCC. Other compilers may not support this feature and thus it has been internally disabled.
Changelog:
- Set Target Types option has been renamed to Configure Advanced Options. (See screenshot 1)
- Now wizard can setup debug target using Release wxWidgets lib and without __WXDEBUG__. Please remember that this is available only for GCC in Windows. (See screenshot 2)
This option was requested by several developer of Code::Blocks. This option will enable a developer to compile application in debug mode (using -g flag to be particular) but using release lib of wxWidgets to avoid mixing of bugs. Please remember that this option will not work for any other compilers other than GCC.
Committed in revision 3610