Various development tips

From Code::Blocks
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
This article contains outdated information.

You can help the Code::Blocks Wiki by updating the article.

This page contains various tips for developing for Code::Blocks. It is meant for developers wanting to extend Code::Blocks.

Using Code::Blocks' global configuration

NOTE: All of this info is only valid up to 1.0RC2. New versions will have another way to access the configuration. Please update this with the new info.

There are many cases where you may need to have persistent configuration values. For example, you may be writing a new plugin (or extend an existing). The global configuration object is a singleton, meaning that only one exists for the program's lifetime. It can be accessed like this:


#include <configmanager.h>
...
ConfigManager::Get()->Read(...); // "read" example
ConfigManager::Get()->Write(...); // "write" example


As you can see, all that's needed is to include the relevant header file. To access the configuration then, you use the static member function ConfigManager::Get() which returns a ConfigManager object (the only). ConfigManager descends from wxConfigBase and so it inherits all its public methods for working with configuration files.

Let's see a real world example. Suppose you 're writing a new plugin and it needs to keep a directory path in a configuration value. To write the configuration value, possibly prior to exiting (or after its imaginary configuration window is closed), do this:

// somehow set pluginDir to the value you want
wxString pluginDir;
// write it in the global configuration
ConfigManager::Get()->Write("/new_plugin/directory", pluginDir);

And to read the saved value, do this:

// write it in the global configuration
// if we never written the value before, "default" will be returned
wxString pluginDir = ConfigManager::Get()->Read("/new_plugin/directory", "default");

In the above examples, the "/new_plugin" part of the string should be replaced with something unique for the plugin you 're writing. For example, the compiler plugin uses "/compiler_gcc", the internal editor class uses "/editor" and so on. That's how simple is to use Code::Blocks' global configuration :)

One more thing: if you want your plugin's configuration to be included in the import/export list in "Settings->Import/export configuration", just add in your plugin's constructor(s) the following:

ConfigManager::AddConfiguration(m_PluginInfo.title, "/new_plugin");

This line will add your plugin in the import/export list. Neat huh?

JIT debugging

cd C:\mingw\bin
drmingw -i -v

this will install drmingw as the jit debugger (drmingw -u to later uninstall) (windbg from the platform sdk can be installed as the jit debugger with windbg -I but it doesn't support gcc debug symbols. it does support vc5/6/7 .pdb files generated by vc++ toolkit, providing true source level debugging)

to test:

- create a win32 project using the gcc compiler as default
- place
 __asm("int3");
 somewhere in the code
- compile & run
 gcc -g
- create a win32 project using vc++ toolkit compiler as default
- place
 __asm{ int 3 };
 somewhere in the code
- compile & run
 cl /Zi
 link /debug