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:

1. Download a nightly build with revision > 5334.
2. Extract them to a folder.
3. Extract CbLauncher.exe to  same folder. After extraction CbLauncher.exe and codeblocks.exe should be in same folder.
4. Now double click on on CbLauncher.exe file to run Code::Blocks in a portable manner.

I’ve uploaded a binary package to the following link to try out Code::Blocks in a portable manner.

http://files.filefront.com/Portable+CB+5526+bin7z/;13582845;/fileinfo.html

CbLauncher package can be downloaded from this post’s attachment.

Known Issues:

1. Code::Blocks still creates an empty folder inside USERPROFILE folder.

Download link: cblauncher_v_0_1_1

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.

So I started to investigate it. To give you a peek of Code::Blocks internals, ConfigManager uses wxStandardPathsBase::Get().GetUserConfigDir() to determine it’s configuration directory. wxWidgets internally uses SHGetFolderPath() function to resolve this call. This function call has higher precedence over environment variables. Thus if you try to set APPDATA before launching Code::Blocks it has no effects.

Now coming to a solution (you may call it a hack, too!), following patch fixes this issue. It reads APPDATA Environment variable first. If it fails to do so, it falls back to wxWidgets based implementation. In this way you can temporarily set APPDATA variable before launching Code::Blocks. You can point to any directory using APPDATA variable and Code::Blocks will use it to save settings.

Index: src/sdk/configmanager.cpp
===================================================================
--- src/sdk/configmanager.cpp	(revision 5519)
+++ src/sdk/configmanager.cpp	(working copy)
@@ -60,6 +60,23 @@
 wxString ConfigManager::temp_folder;
 bool ConfigManager::relo = 0;
 
+#ifdef __WINDOWS__
+wxString GetPortableConfigDir()
+{
+    DWORD bufLen = 32780;
+    TCHAR buffer[32780];
+    int ret = GetEnvironmentVariable(_T("APPDATA"), buffer, bufLen);
+    if (ret == 0)
+    {
+        return wxStandardPathsBase::Get().GetUserDataDir();
+    }
+    else
+    {
+        return wxString::Format(_T("%s\\codeblocks"), buffer);
+    }
+}
+#endif
+
 namespace CfgMgrConsts
 {
     const wxString app_path(_T("app_path"));
@@ -172,7 +189,11 @@
 
     if(cfg.IsEmpty())
     {
+        #ifdef __WINDOWS__
+        cfg = GetPortableConfigDir() + wxFILE_SEP_PATH + personality + _T(".conf");
+        #else
         cfg = wxStandardPathsBase::Get().GetUserDataDir() + wxFILE_SEP_PATH + personality + _T(".conf");
+        #endif
         doc = new TiXmlDocument();
         doc->InsertEndChild(TiXmlDeclaration("1.0", "UTF-8", "yes"));
         doc->InsertEndChild(TiXmlElement("CodeBlocksConfig"));
@@ -187,7 +208,11 @@
 {
     wxPathList searchPaths;
 
+#ifdef __WINDOWS__
+    wxString u(GetPortableConfigDir() + wxFILE_SEP_PATH + filename);
+#else
     wxString u(wxStandardPathsBase::Get().GetUserDataDir() + wxFILE_SEP_PATH + filename);
+#endif
     wxString e(::DetermineExecutablePath() + wxFILE_SEP_PATH +filename);
 
     if(::wxFileExists(u))
@@ -1369,7 +1394,11 @@
 
 void ConfigManager::InitPaths()
 {
+#ifdef __WINDOWS__
+    ConfigManager::config_folder = GetPortableConfigDir();
+#else
     ConfigManager::config_folder = wxStandardPathsBase::Get().GetUserDataDir();
+#endif
     ConfigManager::home_folder = wxStandardPathsBase::Get().GetUserConfigDir();
     ConfigManager::app_path = ::DetermineExecutablePath();
     wxString res_path = ::DetermineResourcesPath();

So far the result is good enough. Core code::Blocks is portable. I’ve checked few plugins. They are now portable too. I’ve written a small launcher. This launcher will run Code::Blocks from the local directory. An AppData folder will be created which Code::Blocks will use to save it’s settings.

Please note following points.

1. Patch is meant for Windows only.
2. Patch is made against latest svn revision. Patch may not work with 8.02 release.
3. A launcher is made available to launch Code::Blocks in a portable way.

Portable Code::Blocks Launcher Source & Binary Download link: cblauncher-v0_1

Have fun!

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.

Following patch has been committed into latest svn trunk which fixes this issue.

--- /trunk/src/sdk/filemanager.cpp	2008/06/22 11:05:11	5103
+++ trunk/src/sdk/filemanager.cpp	2008/06/22 15:57:09	5104
@@ -58,7 +58,7 @@
     len = file.Length();
 
     data = new char[len+4];
-	char *dp = data + len;
+    char *dp = data + len;
     *dp++ = '\0';
     *dp++ = '\0';
     *dp++ = '\0';
@@ -100,7 +100,7 @@
 
     data = buffer.Data();
     len = buffer.Length();
-	buffer.Append("\0\0\0\0", 4);
+    buffer.Append("\0\0\0\0", 4);
     Ready();
 }
 
@@ -274,19 +274,40 @@
     wxString tempName(name + _T(".cbTemp"));
     do
     {
-        wxFile f(tempName, wxFile::write);
-        if(!f.IsOpened())
+        if( !wxCopyFile(name, tempName) )
+        {
             return false;
+        }
 
+        wxFile f(name, wxFile::write);
+        if ( !f.IsOpened() )
+        {
+            return false;
+        }
         if(f.Write(data, len) != len)
         {
             f.Close();
-            wxRemoveFile(tempName);
+            // Keep the backup file as the original file has been destroyed
+            //wxRemoveFile(tempName);
             return false;
         }
+
+        f.Close();
+
     }while(false);
 
-    return ReplaceFile(name, tempName);
+    if (Manager::IsAppShuttingDown())
+    {
+        // app shut down, forget delayed deletion
+        wxRemoveFile(tempName);
+    }
+    else
+    {
+        // issue a delayed deletion of the back'd up (old) file
+        delayedDeleteThread.Queue(new DelayedDelete(tempName));
+    }
+
+    return true;
 }
 
 bool FileManager::Save(const wxString& name, const wxString& data, wxFontEncoding encoding, bool bom)
@@ -309,19 +330,39 @@
     wxString tempName(name + _T(".cbTemp"));
     do
     {
-        wxFile f(tempName, wxFile::write);
-        if(!f.IsOpened())
+        if (!wxCopyFile(name, tempName))
+        {
             return false;
+        }
 
+        wxFile f(name, wxFile::write);
+        if ( !f.IsOpened() )
+        {
+            return false;
+        }
         if(WriteWxStringToFile(f, data, encoding, bom) == false)
         {
             f.Close();
-            wxRemoveFile(tempName);
+            // Keep the backup file as the original file has been destroyed
+            //wxRemoveFile(tempName);
             return false;
         }
+
+        f.Close();
+
     }while(false);
 
-    return ReplaceFile(name, tempName);
+    if (Manager::IsAppShuttingDown())
+    {
+        // app shut down, forget delayed deletion
+        wxRemoveFile(tempName);
+    }
+    else
+    {
+        // issue a delayed deletion of the back'd up (old) file
+        delayedDeleteThread.Queue(new DelayedDelete(tempName));
+    }
+    return true;
 }
 
 bool FileManager::ReplaceFile(const wxString& old_file, const wxString& new_file)

The patch is required for our last release (version 8.02).

Thanks for the bug report.

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.

1. 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).
2. Encoding conversion routine has been overhauled. Now it converts back and forth all supported encodings flawlessly.
3. 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).
4. The file load routine has been moved from a all in one load-plus-encoding detection code to efficiently distributed code.
5. File save routine was overhauled to save files with all supported encodings.
6. Project load routine has been tweaked to reduce the stalling while opening a large project with a large number of open files in it.
7. 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.

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.

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

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.

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.

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

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.

Image1: Renamed Option

Image 2: Advanced Option for GCC