Code::Blocks - User contributions [en]

Code Snippets plugin

2007-01-04T22:53:02Z

Artojon: bump version

[[Category: Code::Blocks Contrib Plugins]]
{{Infobox_Plugin|
name = Code snippets |
logo = [[Image:Generic-plugin.png]] |
developer = [[User:Artojon|Arto Jonsson]] |
maintainer = Arto Jonsson |
version = 0.3.2
}}

'''Code snippets''' plugin is a simple snippets management plugin for Code::Blocks. It integrates with the interface by creating a floating docking window which shows all the snippets. Snippets can be assigned to categories or they can be in the global category called ''All snippets''.

== Snippet management ==

=== Creating a new snippet ===

To create a snippet you must first write the code. The plugin does not use any dialogs (currently no message boxes either) so you have to write the code in the editor. Select your code and and drag it to a category, either in the ''All snippets'' or in other category you may have created.

You might noticed that the code you wrote is gone, this is how the drag and drop works; you move by default. If you want to copy the code and then create a new snippet, hold '''Ctrl''' and then drag it.

To assign a piece of code to a existing snippet you simply drag and drop the code to that snippet.

=== Applying a snippet ===

To apply a snippet, double click it and it will be applied to the currently active editor. You can alternatively right click on the snippet and select ''Apply''.

=== Creating a new category ===

Snippets can be added to categories. Each snippet can be at one category at a time. The number of categories and sub-categories is not limited however.

Each user created category has a parent category, the categories created in root have the ''All snippets'' category as parent. So if you want to create a category to the root, right click ''All snippets'' and select ''Add subcategory''.

== Searching ==

Snippets can be searched by typing words to the text edit control at the top of the docking window. Searching is performed by find-as-you-type method so you don't have to press any search buttons or Enter key. Searching by default includes both snippets and categories.

Searching is case-sensitive by default so "C++" and "c++" are seen as different search terms.

== File format ==

Code snippets plugin uses XML (UTF-8 encoded) file to save all code snippets.

The XML file starts with root item, snippets, which holds all the categories and code snippets. Code snippets and categories use the same element called item. The item's attributes tell what type of item it is, category or code snippet.

=== Elements ===

'''snippets'''
* Attributes: None
* Sub-elements: All snippets and categories

'''item'''
* Attributes:
** name -- Name of the element
** type -- Type of the element, either ''snippet'' or ''category''
* Sub-elements:
** snippet -- The actual code snippet (only if the item's type is ''snippet'')
** Sub-items and categories (only if the item's type is ''category'')

=== Example file ===

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<snippets>
<item name="Test category" type="category" />
<item name="Test item 1" type="snippet" />
<snippet>// Test 1</snippets>
</item>
</item>
<item name="Test item 2" type="snippet" />
<snippet>// Test 2</snippets>
<item>
</snippets>

The file would create the following structure:

All snippets
|
|- Test category
| |
| |- Test item 1
|
|- Test item 2

== Known Issues ==

=== wxMSW ===

'''Using the Tab key in snippet editor causes the focus to move to the next control'''

: Most likely a bug in wxWidgets, I haven't investigated it much yet. Broken also in wxWidgets 2.8, works correctly in wxGTK.

'''Snippet tool tips show garbage text (squares) instead of line breaks (wxWidgets 2.6)'''

: A bug in wxWidgets, fixed in wxWidgets 2.8.

=== wxGTK ===

'''Snippet tool tips don't work'''

: A limitation in wxWidgets, not implemented as of wxWidgets 2.8.0.

'''"Name:" and "Snippet:" text labels in Edit snippet dialog don't have underscores; makes keyboard navigation hard'''

: A bug in wxWidgets, fixed in wxWidgets 2.8. The fix might be backported to 2.6.

Code Snippets plugin

2007-01-03T16:37:14Z

Artojon: added known issues section

[[Category: Code::Blocks Contrib Plugins]]
{{Infobox_Plugin|
name = Code snippets |
logo = [[Image:Generic-plugin.png]] |
developer = [[User:Artojon|Arto Jonsson]] |
maintainer = Arto Jonsson |
version = 0.3.1
}}

'''Code snippets''' plugin is a simple snippets management plugin for Code::Blocks. It integrates with the interface by creating a floating docking window which shows all the snippets. Snippets can be assigned to categories or they can be in the global category called ''All snippets''.

== Snippet management ==

=== Creating a new snippet ===

To create a snippet you must first write the code. The plugin does not use any dialogs (currently no message boxes either) so you have to write the code in the editor. Select your code and and drag it to a category, either in the ''All snippets'' or in other category you may have created.

You might noticed that the code you wrote is gone, this is how the drag and drop works; you move by default. If you want to copy the code and then create a new snippet, hold '''Ctrl''' and then drag it.

To assign a piece of code to a existing snippet you simply drag and drop the code to that snippet.

=== Applying a snippet ===

To apply a snippet, double click it and it will be applied to the currently active editor. You can alternatively right click on the snippet and select ''Apply''.

=== Creating a new category ===

Snippets can be added to categories. Each snippet can be at one category at a time. The number of categories and sub-categories is not limited however.

Each user created category has a parent category, the categories created in root have the ''All snippets'' category as parent. So if you want to create a category to the root, right click ''All snippets'' and select ''Add subcategory''.

== Searching ==

Snippets can be searched by typing words to the text edit control at the top of the docking window. Searching is performed by find-as-you-type method so you don't have to press any search buttons or Enter key. Searching by default includes both snippets and categories.

Searching is case-sensitive by default so "C++" and "c++" are seen as different search terms.

== File format ==

Code snippets plugin uses XML (UTF-8 encoded) file to save all code snippets.

The XML file starts with root item, snippets, which holds all the categories and code snippets. Code snippets and categories use the same element called item. The item's attributes tell what type of item it is, category or code snippet.

=== Elements ===

'''snippets'''
* Attributes: None
* Sub-elements: All snippets and categories

'''item'''
* Attributes:
** name -- Name of the element
** type -- Type of the element, either ''snippet'' or ''category''
* Sub-elements:
** snippet -- The actual code snippet (only if the item's type is ''snippet'')
** Sub-items and categories (only if the item's type is ''category'')

=== Example file ===

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<snippets>
<item name="Test category" type="category" />
<item name="Test item 1" type="snippet" />
<snippet>// Test 1</snippets>
</item>
</item>
<item name="Test item 2" type="snippet" />
<snippet>// Test 2</snippets>
<item>
</snippets>

The file would create the following structure:

All snippets
|
|- Test category
| |
| |- Test item 1
|
|- Test item 2

== Known Issues ==

=== wxMSW ===

'''Using the Tab key in snippet editor causes the focus to move to the next control'''

: Most likely a bug in wxWidgets, I haven't investigated it much yet. Broken also in wxWidgets 2.8, works correctly in wxGTK.

'''Snippet tool tips show garbage text (squares) instead of line breaks (wxWidgets 2.6)'''

: A bug in wxWidgets, fixed in wxWidgets 2.8.

=== wxGTK ===

'''Snippet tool tips don't work'''

: A limitation in wxWidgets, not implemented as of wxWidgets 2.8.0.

'''"Name:" and "Snippet:" text labels in Edit snippet dialog don't have underscores; makes keyboard navigation hard'''

: A bug in wxWidgets, fixed in wxWidgets 2.8. The fix might be backported to 2.6.

Creating a custom lexer for Code::Blocks editor

2006-11-12T18:01:11Z

Artojon: use level 2 headlines across the article

[[Category:Developer Documentation]]
The files that add syntax highlighting support for specific files are found under <tt>sdk/resources/lexers</tt>. They're simple XML files named as <tt>lexer_*.xml</tt>.

Let's take <tt>lexer_cpp.xml</tt> as an example and disect it.

==XML==

<?xml version="1.0"?>

Basically this says "I am an XML file". '''Very Important'''

==DOCTYPE==

<!DOCTYPE CodeBlocks_lexer_properties>

This needs to be in every lexer file. Code::Blocks '''will not''' load the lexer if this is not present.

==Lexers==

<Lexer name="C/C++"
index="3"
filemasks="*.c,*.cpp,*.cc,*.cxx,*.h,*.hpp,*.hh,*.hxx,*.inl">

Pretty much self explanatory, except for the "magic" ''index'' number (we'll come to it in a sec).

* '''name''' is the lexer's configuration name. This will appear in the editor's configuration dialog, in the languages drop down box (in colors editing page).

* '''filemasks''' is a comma separated list of the extensions that this lexer should be used for. This is case-insensitive.

* '''index''' corresponds with the <tt>wxSCI_LEX_*</tt> constants, found in <tt>sdk/wxscintilla/include/wx/wxscintilla.h</tt>. In this example, if you look in <tt>sdk/wxscintilla/include/wx/wxscintilla.h</tt>, you'll see that ''index 3'' matches <tt>wxSCI_LEX_CPP</tt>. That is the ''lexer id'' for C/C++ syntax highlighting.

If we were building a lexer configuration for let's say, XML (random choice) we would look up the constant <tt>wxSCI_LEX_XML</tt> which is defined to be number ''5''. So ''index=5''. Simple.

==Styles==

Next follows many <tt><Style></tt> tags defining the different styles:

<Style name="Default"
index="0"
fg="0,0,0"
bg="255,255,255"
bold="0"
italics="0"
underlined="0" />

* '''name''' is the style's name. It appears in the editor's configuration dialog, in the colors editing page.

* '''fg''' is the foreground color. Comma separated list of three numbers from 0 to 255. In order: red, green and blue (RGB).

* '''bg''' is the background color.

* '''bold''' is <tt>"0"</tt> for disabled, <tt>"1"</tt> for enabled.

* '''italics''' is <tt>"0"</tt> for disabled, <tt>"1"</tt> for enabled.

* '''underlined''' is <tt>"0"</tt> for disabled, <tt>"1"</tt> for enabled.

You don't have to define all of these attributes. It's good to define them all for the <tt>"default"</tt> style (all lexers have a default style), but only the attributes needed should be defined for the rest of the styles.

* The '''index''' number in the <tt><Style></tt> tags, comes from a different set of constants defined in <tt>sdk/wxscintilla/include/wx/wxscintilla.h</tt>.

For each language supported by scintilla, there is a set of styles ''(lexical states)'' defined (these are what we're trying to configure with these files).

For example, for C/C++ files (<tt>wxSCI_LEX_CPP</tt>, remember?) the styles are defined as <tt>wxSCI_C_*</tt>.

For the <tt>"default"</tt> style shown above, this would be <tt>wxSCI_C_DEFAULT</tt> which is defined to be ''0''. Hence ''index=0'' for <tt>"default"</tt>.

<Style name="Comment (normal)"
index="1,2"
fg="160,160,160" />

This is the style definition for normal comments. As you can see you can define a single style for more than one style index, in this case two: ''1'' and ''2'' (always comma separated).

''1'' is for <tt>wxSCI_C_COMMENT</tt> (the C comment <tt>/* */</tt>) and ''2'' is for <tt>wxSCI_C_COMMENTLINE</tt> (the C++ comment to end of line <tt>// </tt>).

There are some special styles defined by Code::Blocks and are available to all lexers:

* '''index -99''' is the selected text style.
* '''index -98''' is the active line style (the line the caret is on).
* '''index -2''' is the breakpoint line style.
* '''index -3''' is the debugger active line style (while stepping the debugger).
* '''index -4''' is the compiler warning/error line style. ('''Note: this index was removed completely?''')

==Keywords==

Now on to the keywords.

<Keywords>
<Set index="0"
value="if int long try while and-so-on" />
<Set index="1" />
<Set index="2"
value="param remarks return $ @ \ & < > # { } and-so-on" />
</Keywords>

If the language you're defining a lexer configuration for, has keywords they should be added in the <tt><Keywords></tt> tag.
In the scintilla version used by Code::Blocks, you can setup up to 9 keyword sets (the "index" attribute). What each set does and which sets are used by a lexer, is defined by the lexer itself.

If you open LexCPP.cxx (from the scintilla sources), you will find the following:

static const char * const cppWordLists[] = {
"Primary keywords and identifiers",
"Secondary keywords and identifiers",
"Documentation comment keywords",
"Unused",
"Global classes and typedefs",
0,
};

This tells us which indices are valid and what each one represents:

Index 0, "Primary keywords and identifiers"

Index 1, "Secondary keywords and identifiers"

Index 2, "Documentation comment keywords"

(notice that index "3" is not used)

Index 4, "Global classes and typedefs"

==Sample Code==

The tag left is <tt>SampleCode</tt>. This is much pretty self explanatory:

<SampleCode value="lexer_cpp.sample"
breakpoint_line="20"
debug_line="22"
error_line="23"/>

* '''value''' is the filename of the code that will be shown in the Preview window.
When creating a <tt>lexer_*.sample</tt> try to do it with simple and concise sample code (like the ones found in a typical "Hello world!"), yet include all the keywords of the lexer.

There are other optional options ('''Note: this index was removed completely?''')
* '''breakpoint_line''' is the number of the line in which a breakpoint line will be previewed.
* '''debug_line''' is the number of the line in which a debug line will be previewed.
* '''error_line''' is the number of the line in which an error line will be previewed.

==Tips==
When writting a lexer, this can be useful:
* .properties files of SciTE (the official Scintilla-based text editor) [http://scintilla.sourceforge.net/SciTE.html]

==Adding support for code-folding==

'''Note: support for code-folding can't be done from the lexer files. It must be done right in the Scintilla code'''.

See here: http://sphere.sourceforge.net/flik/docs/scintilla-folding.html

==Adding support for a lexer not supported in Scintilla==

'''Note: support for a lexer not supported in Scintilla is out of scope of Code::Blocks. It must be done right in the Scintilla code.'''

Here are some instructions: http://scintilla.sourceforge.net/Lexer.txt

* After you've written the Scintilla lexer, submit the files to the [http://sourceforge.net/tracker/?group_id=2439 Scintilla tracker], following their own [http://scintilla.sourceforge.net/SciCoding.html coding style].

* After that, make any necesary change to wxScintilla and sumbit the files to the [http://sourceforge.net/tracker/?group_id=51305&atid=462818 wxScintilla tracker] or send a mail to the autor wyo@users.sourceforge.net (Otto Wyss).

* And finishing, be sure to send all to the [http://developer.berlios.de/patch/?func=addpatch&group_id=5358 Code::Blocks tracker] (Category: Lexer), and announce it at the [/index.php?board=7.0 Forum] and the [[Announcement for plugins/patches|Wiki announcement for plugins/patches]].

Creating a Plug-in which modifies CB's Menus

2006-11-12T17:53:38Z

Artojon: flagged as outdated

[[Category:Plugin development]]
[[Category:Outdated]]
{{outdated}}
== Environment ==

NOTE : Also an update for wx 2.6.1 and creating a menu in the menu toolbar are in the pipeline.

The following has been carried out with/on :

* Windows XP SP2
* Code::Blocks RC1-1
* wxWindows 2.4.2

The entire project is available in [http://users.pandora.be/lieven.de.cock/CodeBlocks/Ldc2.zip this zip file]

== Create the plug-in project ==

First thing we need to do is create a plug-in project. For more info on how to setup everything see [https://wiki.codeblocks.org/index.php/Creating_a_simple_%22Hello_World%22_plugin this page] on the wiki. In our tutorial we create a plug-in of type General.
I gave it the name LDC2, and selected the settings :

* Needs to create menu items
* Needs to create menu items in pop-up menus
[[Image:Menu0.PNG]]

Afterwards the code get's generated (LDC2.h/cpp). Try to build the project. I encountered 1 problem : I had to change the line in the header file :
void BuildToolBar(wxToolBar* toolBar){ return; }
to :
bool BuildToolBar(wxToolBar* toolBar){ return false; }
After doing this it compiled fine for me.

== Logging during the plug-in ==

During the implementation I am going to write some feedback stuff on the screen. I chose to use the log facilities that allow you to write to the Code::Blocks tab in the output pane (which also contains a "Search Results", "Compiler", ... tabs).
To do this we need to do the following things :

* Get hold of the Manager interface which we can use to retrieve other interfaces
* Get hold of the MessageManager interface, which we will be using for the logging

Both can be done in 1 statement : Manager::Get()->GetMessageManager() .
To be able to call those functions we need to add the declarations of those functions, therefor we add the following include statements in the implemenation file :
#include <manager.h>
#include <messagemanager.h>
The method I use for logging is Log(), which has a similar syntax as nasty old printf.

== Menu adjusting ==

If your plug-in wants to adjust the menu, the correct place to do it is in the BuildMenu method.
When Code::Blocks is starting up it will call your plug-in by this method, allowing you to change the menu. Therefor it provides as an argument it's menuBar.
The normal menuBar consists out of 11 menus, starting with "File", "Edit", "View" and so on. These menus are ordered, or otherwise stated they have a position. Where the first position is position "0". So "File" is at position 0, "Edit " at position 1, ...
So let's get our feet wet and start by adjusting the "Edit" menu.

== Adjusting the "Edit" menu ==

The first thing we need to do is get hold of the "Edit" menu. The class wxMenuBar, the type of our menuBar parameter, provides the method "FindMenu" to search for certain menus. The menu to search for is the argument of the method, and is specified by it's textual id, and returns the position of the menu. So in our case we get :
int pos = menuBar->FindItem(_("Edit"));
If this menu would not be found the return value is wxNOT_FOUND.
In the example code, we write out the position of the menu to the Log. Check that this should be 1.
Now that we have the position of the menu, we can get hold of it's interface (or pointer to the menu object), this is done by calling the GetMenu() method of he wxMenuBar class. The argument is the position of the menu, from which we want the interface.
wxMenu* EditMenu = menuBar->GetMenu(pos);
Now that we have hold of the actual menu we want to adjust, we can start by adding new entries to the menu.
We have several locations where we can add our own entries :

* at the start/beginning/top => Prepend
* at the end/bottom => Append
* in the middle => Insert

It is good practice when you add new entries, that you seperate them visually from the already existing entries, or to group them logically. This can be done by use of a separator, this is a vertical line that goes from left to right in the menu. The menu class wxMenu provides for the 3 cases above, 3 different methods :

* AppendSeparator()
* PrependSeparator()
* InsertSeperator(int pos), where pos is the position of the entry at which it should be inserted.

For our entries we have the following methods at our disposal according to the 3 situations described above :

* Append()
* Prepend()
* Insert()

There is however one more thing we need to take care of, before we can proceed for adding our own entries. Every menu entry needs to have a unique id in the program. Since we are a plug-in, and those can be added dynamically, we have no idea of which id's are already taken and which are available. Luckily the underlying wxWindows mechanism takes care of that for us. We can ask the wxWindows mechanism to generate a new id for us, and then we use that one. This is done by calling the function "wxNewId". So for our first entry we do like this :
int idMenuEntry1 = wxNewId();
This id can be used to identiy our own menu entries.

Now let's add our first extra entry in the menu :
EditMenu->Append(idMenuEntry1, _("Menu Entry 1\tCtrl-Shift-1"));
So the id is specified as the first parameter to the Append method, and as a second argument we specify the Caption of the menu entry "Menu Entry 1", and in the mean time we specify the keyboard accelerator/shortcut. Both are specified in a string seperated by a tab character (\t).
The picture below show the result of adding our first extra menu entry together with a separator.

[[Image:Menu1.PNG]]

Next in our code example we add a menu entry at the top of the menu, and we use a third argument (works with all 3 methods to add entries) where we specify a help text to be displayed in the status bar of Code::Blocks.
EditMenu->Prepend(idMenuEntry2, _("Menu Entry 2\tCtrl-Shift-2"), _("Help text"));
The result looks like this :

[[Image:Menu2.PNG]]

Next we add a third entry somewhere in between, we add it after the Redo entry and the following separator. That Redo is the 4th entry, so counting from zero : pos 3. Menu entry 2 is at O, Seperator at 1, Undo at 2, Redo at 3. So our new entry is at position 4..
EditMenu->Insert(4, idMenuEntry3, _("Menu Entry 3\tCtrl-Shift-3"));
Wich gives the following result :

[[Image:Menu3.JPG]]

So by locating our menu, getting it's interface, and using some methods we were able to add new menu entries.

== Adding a submenu ==

Let's take our manipulation of the menu 1 step further. Let's create a submenu, which has its own entries.
Since a submenu is nothing more then a menu, we first need to create a new menu object; this new object has to live as long as the plug-in itself, so it can not be a local variable, it needs to be stored in the class itself. Therefor we added the member m_SubMenu1, initialized to NULL, and released during the destructor.
We will allocate it now :
m_SubMenu1 = new wxMenu();
And we append this new menu to our EditMenu :
EditMenu->Append(idSubMenu1, _("SubMenu1"), m_SubMenu1);
The result looks like :

[[Image:Menu4.JPG]]

The next task is adding an entry into this new menu.
We already have hold of the menu interface (we just created it), nevertheless let's see what we need to do in the case we would not have it's interface yet (for example if we want to add entries to an existing submenu).
As submenu together with the other entries in the menu are called menuItem's. So within the "Edit" menu we need to search for the item "SubMenu1" and we will get in return, in the case it is found, it's position.
int idSub = EditMenu->FindItem(_("SubMenu1"));
Once we have the position we can retrieve the interface of the item.
wxMenuItem* SubMenu1Item = EditMenu->FindItem(idSub, NULL);
Just fill in NULL as the second argument (I still need to find out what's its purpose).
From the item we can retrieve the actual submenu as follows :
wxMenu* SubMenu1 = SubMenu1Item->GetSubMenu();
And now we add like before a new entry.
The result looks like :

[[Image:Menu5.JPG]]

== Modifying the context menu of the editor ==

Another menu we can adjust is the pop-up menu you get by right-clicking in the editor pane of an open source file, sometimes also called the context menu.
As with the regular menu, the application will call a method of our plug-in to allow us to adjust the context menu. The method is "BuildModuleMenu", as arguments we get the type of the Module generating the context menu, and the interface of that menu. So things are very easy here, we get the menu interface directly.
We only need to make sure that :

* we are attached
* the menu does exist
* the module type is that of the editor manager

In code the test on the type looks like :
if(type == mtEditorManager)
And next we can add an entry like :
menu->Append(idContextMenuEntry1, _("Context Menu Entry 1"));

The result looks like :

[[Image:Menu6.JPG]]

So this was a piece of cake.

== Making all those menus do something ==

Now that we have added all those new menu entries, it would be nice that they actually do something. If you select them at this moment nothing happens. Nevertheless they already did something behind the scenes. When you click on a menu entry they generate a wxCommand event. It is our duty to listen to those events and provide a handler for them. A handler can be seen as a method that does the stuff we want to happen when the menu entry is selected.
Those handlers should have the following signature :
void ClassName::MethodName(wxCommandEvent& event);
So for our 4 menu entries we have now, we add the following declarations in the header, in the private section :
void OnMenuEntry1(wxCommandEvent& event);
void OnMenuEntry2(wxCommandEvent& event);
void OnMenuEntry3(wxCommandEvent& event);
void OnMenuEntry4(wxCommandEvent& event);
And we provide some dummy implementation, they just write to the Log, telling us they were selected, now how about that for usefull functionality.

All that's left to do is provide the missing link : connect the event to it's handler.
What we already know is that each menu entry has an unique id. The way wxWindows work is that we have to link that id with the event handler.
Those links are specified in the implementation file in the block :
BEGIN_EVENT_TABLE(Ldc2, cbPlugin)
// add events here...
END_EVENT_TABLE()
This was placed in the generated code by the Plug-In wizard. Also in the class declaration we find such a directive : DECLARE_EVENT_TABLE()
The BEGIN_EVENT_TABLE directive tells that our class Ldc2 listens to the same events as the cbPlugIn (our class was derived from cbPlugIn). Personal note : I hope this statement is correct.
Next we create mappings as follows :
EVT_MENU(idMenuEntry1, Ldc2::OnMenuEntry1)
By means of the directive EVT_MENU we map our id idMenuEntry1 to the handler Ldc2::OnMenuEntry1
Where in our example the end result is :
BEGIN_EVENT_TABLE(Ldc2, cbPlugin)
// add events here...
EVT_MENU(idMenuEntry1, Ldc2::OnMenuEntry1)
EVT_MENU(idMenuEntry2, Ldc2::OnMenuEntry2)
EVT_MENU(idMenuEntry3, Ldc2::OnMenuEntry3)
EVT_MENU(idMenuEntry4, Ldc2::OnMenuEntry4)
END_EVENT_TABLE()
Note : no semicolons at the end.
If you have compiled our example code, put the dll in the subdir .\share\CodeBlocks\plugins of Code::Blocks installation directory, you can try out the menus and see how it actually does work. ;-)
In the project zip file, the dll is also included.
The following screenshot shows the Log when we choose some of our menu entries.

[[Image:Menu7.JPG]]

That's all for now, more tutorials will follow. Enjoy.
I would like to thank Mandrav and the rest of the Code::Blocks team for this great IDE, and also Thomas who gave me my first pointers on where to find some information.

Creating a simple "Hello World" plugin

2006-11-12T17:49:16Z

Artojon: flagged as outdated

[[Category:Plugin development]]
[[Category:Outdated]]
{{outdated}}
'''NOTE''': This tutorial was written using the Code::Blocks final beta under windows.

==Prerequisites==

This tutorial assumes you have a working version of Code::Blocks installed and some knowledge of how to deal with projects, in particular how to compile them. In order to use the Code::Blocks SDK you must also have a working version of wxWidgets installed. For more information see
[[Compiling wxWidgets 2.6.2 to develop Code::Blocks (MSW)|Compiling wxWidgets 2.6.2 to develop Code::Blocks]]

To develop Code::Blocks plugins you will also need a copy of the Code::Blocks SDK, which can be found on the Code::Blocks [https://www.codeblocks.org/downloads.shtml download page]. Install this to somewhere sensible that you will remember later on. Personally I keep the SDK in a folder called CodeBlocks\sdk (which contains the include/ and lib/ from in the zip). This means that the header files refered to in the tutorial would be found under ''Codeblocks\sdk\include'', so ''cbPlugin.h'' is ''Codeblocks\sdk\include\cbPlugin.h'' for example.

==Overview==

This tutorial will guide you through the creation of a simple "Hello World" plugin, which when activated displays "Hello World!" in the Code::Blocks log tab below the editor. This could be done completely by hand, but Code::Blocks contains a very useful plugin project generator (which, incidentally, is a plugin itself), so we'll use that.

==Creating the Plugin Project==

Select the '''Plugins->Code::Blocks Plugin Wizard''' option from the main menu bar and choose a suitable project name and location. Save the project, and another dialog will be shown which allows you to select various options for your plugin.

===Plugin Type===

The Code::Blocks SDK contains interfaces for various different types of plugins in the ''cbPlugin.h'' file. The drop down ''Plugin type'' list in the wizard allows you to select which type of plugin you wish to build - essentially which class the main plugin interface class will inherit from. We want to build a Tool plugin, so select that from the list. Tool type plugins are added to the Plugins main menu submenu automatically, and their ''Execute'' method is called when they are selected by the user. We will use this later in order to display our message.

===Plugin Info===

The ''Plugin name'' field is the name of the plugin interface class which the wizard will create. Enter "HelloWorldPlugin" here. More information can be provided by clicking on the ''Enter Plugin Info'' button. The fields here are fairly self explanitory, but one which you should pay particular attention to is the ''Title'' field, since this is what Code::Blocks will use to refer to the plugin in the menus. In the generated code, the plugin info is kept in the plugin class' ''m_PluginInfo'' member, which is of the type ''PluginInfo'' and is set in the plugin interface class' constructor. ''PluginInfo'' is detailed in ''cbPlugin.h'', if you want to go take a look.

===Provides Configuration Dialog===

This indicates whether or not the plugin is to provide a configuration dialog which can be accessed through the '''Settings->Configure Plugins''' submenu. We don't need one, so leave this box unchecked.

===Filenames===

The filenames should have been filled in automatically by the dialog when you entered the Plugin name, if you used the name "HelloWorldPlugin", for example, these should be helloworldplugin.h and helloworldplugin.cpp respectively. If you want to change the names of the files generated, this is where to do it (this tutorial will assume you have left them as the default values).

The guard-block box is simply if you wish to place inclusion guards in the header file, and if you do what symbol to use. If you don't know what these are then just leave it as it is.

Click '''Create''' and take note of the next dialog box's message about the SDK include and library directories, that's what we'll be dealing with next.

==Letting the project know where to find the SDK==

Code::Blocks should have created a new project called "Custom Plugin". Before we can compile anything we need to make sure that the compiler knows where the sdk files are in order to include headers and link the libraries. If your compiler has not been setup to know where wxWidgets is yet then this must also be done (see the links in Prerequisites for more details).

Right click on the project and select '''Build Options''' then the '''Directories''' tab. Here, make sure the '''Compiler''' tab is selected then click on the '''Add''' button. Browse to where you unzipped the SDK and select the ''include'' directory (for example ''C:\CodeBlocks\sdk\include'' if you installed the SDK there), then click okay and select whether or not the path should remain relative. Go to the "Linker" tab and add the "lib" directory under where the SDK was installed in similar fashion (following my install, this would be in ''C:\CodeBlocks\sdk\lib'').

===Linker Options===

If you click on the '''Linker Options''' tab at the top level in the Build Options dialog, you will see that the plugin is being linked to the Code::Blocks core library (codeblocks) and the wxWidgets library (wxmsw242 under windows ''NOTE: The plugin generator uses 2.4.2, if you're using a different version of wxWidgets then change this'').

===Compiler Options===

The '''Compiler Options''' tab shows that several symbols have been defined when the plugin is compiled: ''__GNUWIN32__'', ''WXUSINGDLL'' and ''BUILDING_PLUGIN'' in this case (using windows). The first two are indicators to wxWidgets of the compiler and DLL options to use, and the last is an indicator to the Code::Blocks SDK headers that they are being used to build a plugin (which affects whether or not symbols are exported or imported for the DLL - see ''cbPlugin.h'' for example).

==Adding Functionality==

The plugin wizard should have generated us helloworldplugin.h and helloworldplugin.cpp. The header file contains the class definition and a C function declaration which is used to load the plugin when asked by the main Code::Blocks program (''GetPlugin''). What we're interested in, however, is the definition of the class methods in helloworldplugin.cpp. The plugin wizard has generated us a constructor in which the ''m_PluginInfo'' information is set, and three methods. ''OnAttatch'' and ''OnRelease'' are methods called to inform the plugin when it is attached (the user has selected it and Code::Blocks has loaded it) or released (Code::Blocks no longer has a use for it or is shutting down). Since our plugin does not need to perform any actions on loading or shutting down, we can leave these as they are.

The ''Execute'' method, as mentioned earlier, is what we are really interested in. We are going to use the MessageManager class to add a log message in the window beneath the editor. To do this we will need access to both the Manager class and the MessageManager class. Manager is and internal Code::Blocks class which is used to keep track of internal information and the various task specific managers (like the MessageManager and EditorManager - which is used to keep track of all the open files and their editors). MessageManager is responsible for both normal output and debugging output (see ''messagemanager.h'' for more details). Replace the generated Execute method with this new one:

int HelloWorldPlugin::Execute()
{
if( !IsAttached() )
return -1;
Manager::Get()->GetMessageManager()->Log( _("Hello World!") );
return 0;
}

This new method uses the Manager's static Get method to return the singleton Manager object, then uses that to access the MessageManager through the GetMessageManager method. MessageManager has a method called ''Log'' which appends a string to the bottom of the output log, so we use this to add the "Hello World!" message. The _() construct is part of wxWidgets' internationalisation utilities, and more information on it can be found in the wxWidgets [http://wiki.wxwidgets.org/wiki.pl?WxWidgets_Source_Oddities documentation].

The first two lines check to see if the plugin has been attatched (in other words selected by the user in the '''Plugins->Plugin Manager''' menu), and thus whether it should perform any action at all. As far as I can tell, the return value of Execute is not used anywhere, but all the default plugins use -1 for failure and 0 for success (much like the main function in a C program) so that is what is used here.

Add headfiles to helloworldplugin.cpp

#include <manager.h>
#include <messagemanager.h>

Now we have our code in place we are ready to...

==Compile! (And test)==

This should produce a file called HelloWorldPlugin.dll, which can be tested by copying to the ''CodeBlocks\share\CodeBlocks\plugins\'' directory and restarting Code::Blocks. There should now be an option in the '''Plugins''' menu for "Hello World" (or whatever the title field was set to when the plugin was generated - or in ''m_PluginInfo''). Click on this and "Hello World!" should appear in the Code::Blocks logging window. Congratulations, you've just created your first plugin!

==Further Information==

It is essential to learn how wxWidgets works if you seriously plan on working on plugins, since most of Code::Blocks depends on it, and you will find it easier to add and manipulate components if you have a firm grasp of its principles. More information on this can be found in the wxWidgets [http://www.wxwidgets.org/docs.htm documentation]. Another good place to learn from is the source code from the existing Code::Blocks plugins, which can be downloaded along with the rest of the Code::Blocks source code from the [https://www.codeblocks.org/downloads.shtml download page].

Hopefully this tutorial has helped you work through a few fundamentals in terms of creating plugins, happy coding!

Comparison of wxSmith features

2006-11-11T19:38:05Z

Artojon: removed extra category

[[Category:wxSmith Documentation]]
Here is a list of [[wxSmith]] features when compared to other [[wikipedia:WxWidgets|wxWidgets]] [[wikipedia:Rapid application development|RAD]] solutions.

Note that support for new features are added on a daily basis for some of these [[wikipedia:Rapid application development|RADs]].

Please update this list when something gets added.

==General information==
Basic general information about the [[wikipedia:Rapid application development|RADs]]: developer, license/price etc.
{| border="1" cellpadding="1" cellspacing="0" style="font-size: 85%; border: gray solid 1px; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec; border: solid 1px gray;"
! style="width:12em" | [[wikipedia:Rapid application development|RAD]]
! Developer
! Cost ([[wikipedia:United States dollar|USD]])
! [[wikipedia:Open source|Open source]]
! [[wikipedia:Software licence|Software licence]]
|- style="border: solid 1px gray;"
! style="text-align: left; background: #ececec;" | [[wxSmith]]
| Bartlomiej Swiecki
| Free
| Yes
| [[wikipedia:GNU General Public License|GPL]]
|- style="border: solid 1px gray;"
! style="text-align: left; background: #ececec;" | [http://www.anthemion.co.uk/dialogblocks/ DialogBlocks]
| Julian Smart
| Free (trial), €66 (normal), €35 (student)
| No
| [[wikipedia:Proprietary software|Proprietary]]
|- style="border: solid 1px gray;"
! style="text-align: left; background: #ececec;" | [http://www.roebling.de/ wxDesigner]
| Robert Roebling
| Free (trial), €129 (normal), €29 (student)
| No
| [[wikipedia:Proprietary software|Proprietary]]
|- style="border: solid 1px gray;"
! style="text-align: left; background: #ececec;" | [http://wxformbuilder.org/ wxFormBuilder]
| José Antonio Hurtado, Juan Antonio Ortega
| Free
| Yes
| [[wikipedia:GNU General Public License|GPL]]
|- style="border: solid 1px gray;"
! style="text-align: left; background: #ececec;" | [http://visualwx.altervista.org/ VisualWx]
| {{dunno}}
| Free
| No
| {{dunno}}
|- style="border: solid 1px gray;"
! style="text-align: left; background: #ececec;" | [http://wxdsgn.sf.net/ wxDevC++]
| Guru Kathiresan , Tony Reina, Malcolm Nealon, Joel Low
| Free
| Yes
| [[wikipedia:GNU General Public License|GPL]]
|- style="background: #ececec; border: solid 1px gray;"
! [[wikipedia:Rapid application development|RAD]]
! Developer
! Cost ([[wikipedia:United States dollar|USD]])
! [[wikipedia:Open source|Open source]]
! [[wikipedia:Software licence|Software licence]]
|-
|}

==Widgets supported==
{| border="1" cellpadding="1" cellspacing="0" style="font-size: 85%; border: gray solid 1px; border-collapse: collapse; text-align: center; width: 100%; table-layout: fixed;"
|- style="background: #ececec;"
! style="width: 12em" | Widget
! wxSmith
! DialogBlocks
! wxDesigner
! wxFormBuilder
! VisualWx
! wxDevC++
|-
! style="text-align: left; background: #ececec;" | wxBitmapButton
| {{no}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxBoxSizer
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxButton
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxCalendarCtrl
| {{yes}}
| {{yes}}
| {{no}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxCheckBox
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxCheckListBox
| {{yes}}
| {{yes}}
| {{no}}
| {{no}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxChoice
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxChoicebook
| {{yes}}
| {{yes}}
| {{no}}
| {{yes}}
| {{yes}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | wxColourDialog
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxComboBox
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxContextHelpButton
| {{no}}
| {{yes}}
| {{no}}
| {{no}}
| {{yes}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | wxDatePickerCtrl
| {{yes}}
| {{yes}}
| {{no}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxDialUpManager
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxDirDialog
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxDynamicSashWindow
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | wxFlexGridSizer
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxFileDialog
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxFindReplaceDialog
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxFontDialog
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxGauge
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxGenericDirCtrl
| {{yes}}
| {{yes}}
| {{no}}
| {{no}}
| {{yes}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | wxGrid
| {{no}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxGridBagSizer
| {{no}}
| {{yes}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | wxGridSizer
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxHtmlEasyPrinting
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxHtmlListBox
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | wxHtmlWindow
| {{yes}}
| {{yes}}
| {{no}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxHyperLinkCtrl
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxListbook
| {{yes}}
| {{yes}}
| {{no}}
| {{yes}}
| {{yes}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | wxListBox
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxListCtrl
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxListView
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | wxMediaCtrl
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxMenu
| {{no}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxMessageDialog
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxMultiChoiceDialog
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxNotebook
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxOwnerDrawnComboBox
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxPanel
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxPasswordEntryDialog
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxPrintDialog
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxProgressDialog
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxPropertySheetDialog
| {{no}}
| {{yes}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | wxRadioBox
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{no}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxRadioButton
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxRichTextCtrl
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxSashLayoutWindow
| {{no}}
| {{yes}}
| {{no}}
| {{no}}
| {{yes}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | wxSashWindow
| {{no}}
| {{yes}}
| {{no}}
| {{no}}
| {{yes}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | wxScrollBar
| {{yes}}
| {{yes}}
| {{no}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxScrolledWindow
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxSingleChoiceDialog
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxSlider
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxSpacer
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | wxSpinButton
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxSpinCtrl
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxSplitterWindow
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxStaticBitmap
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxStaticBox
| {{yes}}
| {{yes}}
| {{no}}
| {{no}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxStaticBoxSizer
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxStaticLine
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxStaticText
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxStatusBar
| {{no}}
| {{yes}}
| {{no}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxStdDialogButtonSizer
| {{yes}}
| {{yes}}
| {{no}}
| {{yes}}
| {{no}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | wxTextCtrl
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxTextEntryDialog
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxToggleButton
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxToolbar
| {{no}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxTreebook
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | wxTreeCtrl
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | wxVListBox
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | wxVScrolledWindow
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | wxWindow (Foreign)
| {{no}}
| {{yes}}
| {{yes}}
| {{no}}
| {{yes}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | wxWizardPage
| {{no}}
| {{yes}}
| {{no}}
| {{no}}
| {{yes}}
| {{no}}
|- style="background: #ececec;"
! Widget
! wxSmith
! DialogBlocks
! wxDesigner
! wxFormBuilder
! VisualWx
! wx-DevC++
|-
|}

==Contrib widgets supported==
{| border="1" cellpadding="1" cellspacing="0" style="font-size: 85%; border: gray solid 1px; border-collapse: collapse; text-align: center; width: 100%; table-layout: fixed;"
|- style="background: #ececec;"
! style="width: 12em" | Widget
! wxSmith
! DialogBlocks
! wxDesigner
! wxFormBuilder
! VisualWx
! wxDevC++
|-
! style="text-align: left; background: #ececec;" | awxLed
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
| {{no}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | wxEditableListBox
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | wxFlatNotebook
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
| {{no}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | wxLEDNumberCtrl
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | wxPlotWindow
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
| {{yes}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | wxPropertyGrid
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
| {{no}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | wxPropertyGridManager
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
| {{no}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | wxScintilla
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
| {{no}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | wxStyledTextCtrl
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | wxTreeListCtrl
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
|- style="background: #ececec;"
! Widget
! wxSmith
! DialogBlocks
! wxDesigner
! wxFormBuilder
! VisualWx
! wxDevC++
|-
|}

==Languages supported==
{| border="1" cellpadding="1" cellspacing="0" style="font-size: 85%; border: gray solid 1px; border-collapse: collapse; text-align: center; width: 100%; table-layout: fixed;"
|- style="background: #ececec;"
! style="width: 12em" | Feature
! wxSmith
! DialogBlocks
! wxDesigner
! wxFormBuilder
! VisualWx
! wxDevC++
|-
! style="text-align: left; background: #ececec;" | C++ code output
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | Python code output
| {{no}}
| {{yes}}
| {{yes}}
| {{no}}
| {{yes}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | Lua code output
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | Ruby code output
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | Perl code output
| {{no}}
| {{no}}
| {{yes}}
| {{no}}
| {{yes}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | C# code output
| {{no}}
| {{no}}
| {{yes}}
| {{no}}
| {{no}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | Basic code output
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
|- style="background: #ececec;"
! Feature
! wxSmith
! DialogBlocks
! wxDesigner
! wxFormBuilder
! VisualWx
! wxDevC++
|-
|}

==Features supported==
{| border="1" cellpadding="1" cellspacing="0" style="font-size: 85%; border: gray solid 1px; border-collapse: collapse; text-align: center; width: 100%; table-layout: fixed;"
|- style="background: #ececec;"
! style="width: 12em" | Feature
! wxSmith
! DialogBlocks
! wxDesigner
! wxFormBuilder
! VisualWx
! wxDevC++
|-
! style="text-align: left; background: #ececec;" | XRC input
| {{yes}}{{refun|XRCnotworks}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | XRC output
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | XRC code loading
| {{yes}}
| {{yes}}
| {{no}}
| {{no}}
| {{dunno}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | Validators{{refun|Validators}}
| {{no}}
| {{yes}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | Conditional UI{{refun|ConditionalUI}}
| {{no}}
| {{yes}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | Event table and handler generation{{refun|EventTable}}
| {{partial}}
| {{yes}}
| {{partial}}
| {{no}}
| {{partial}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | Bitmaps support{{refun|Bitmaps}}
| {{no}}
| {{yes}}
| {{yes}}
| {{no}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | English descriptions{{refun|EnglishDesc}}
| {{no}}
| {{yes}}
| {{no}}
| {{no}}
| {{yes}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | Easy access to window pointers{{refun|WindowPointers}}
| {{yes}}
| {{yes}}
| {{no}}
| {{no}}
| {{dunno}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | Visually creating custom controls
| {{partial}}
| {{yes}}
| {{partial}}
| {{no}}
| {{partial}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | Template controls{{refun|TemplateControls}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | Sizer design
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
|-
! style="text-align: left; background: #ececec;" | Non-sizer design
| {{partial}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
| {{yes}}
|- style="background: #ececec;"
! Feature
! wxSmith
! DialogBlocks
! wxDesigner
! wxFormBuilder
! VisualWx
! wxDevC++
|-
|}

*{{note|XRCnotworks}} Currently, only one dialog resource per XRC file is imported.

=== Features explained ===

==== {{note|Validators}}Validators ====

The aim of the validator concept is to make dialogs very much easier to write. A validator is an object that can be plugged into a control (such as a wxTextCtrl), and mediates between C++ data and the control, transferring the data in either direction and validating it. It also is able to intercept events generated by the control, providing filtering behaviour without the need to derive a new control class.

How to use validators in a RAD that supports this concept: Just add a variable, select the variable and a validator, and the data transfer between variable and control is done for you.

==== {{note|ConditionalUI}}Conditional UI ====

It's the ability to adapt the user interface to the UI guidelines of different platform.

Just mark elements as for one platform (or several), and preview the look for any given platform.

[[Image:Conditional ui.PNG|Example of how it looks on DialogBlocks]]

==== {{note|EventTable}}Event table and handler generation ====

The RAD generates the event tables and empty handlers (including UI update handlers) so you can immediately concentrate on writing code to make the dialog come to life.

It includes a choice of event types for each window, with function name editing.

'''DialogBlocks Event Handler'''

Here DialogBlocks haves the list of event handlers.

The most noticeable feature here is that if you do a double-click on a event, you're transported to the function associated in the code. It's very handy.

[[Image:Event handler dialogblocks.PNG|Event Tables in DialogBlocks]]

'''VisualWx Event Handler'''

Here VisualWx filters the events:
* Base wxWidgets Events
* Component Events
* Windows Events
* VisualWx Events
* Custom Events

[[Image:Event handler visualwx.PNG|Event Tables in VisualWx]]

==== {{note|Bitmaps}}Bitmap support ====

Bitmaps support means that you can import images into your project from a variety of formats and associate them with your static bitmap and bitmap button controls.

You can specify whether the bitmaps will converted into XPM format (the standard format for small bitmaps in wxWidgets) and whether the XPM image will be inserted as inline C++ code, or loaded from a file.

==== {{note|EnglishDesc}}English descriptions ====

English descriptions show a brief description of each element, to help you get used to sizers and also to make it easier to see at a glance the important aspects of your dialog element.

[[Image:Rad english descriptions.PNG|An example of DialogBlocks English descriptions]]

==== {{note|WindowPointers}}Easy access to window pointers ====

The ''easy access to window pointers'' concept means:

Give each window a variable name, and the RAD will add the name to the class declaration, and initialise it to the appropriate window in the implementation.

In XRC mode, the RAD can generate the code to find the window and assign it to the pointer variable.

==== {{note|TemplateControls}}Template controls ====

Template controls are sets of most common widgets together, like an Ok/Cancel pair buttons inside a sizer, being user-definable.

Category:Installing Code::Blocks

2006-11-11T19:36:59Z

Artojon: moved to "User Documentation"

[[Category:User Documentation]]
:''Main article: [[Installing Code::Blocks]]''

WxSmith Tutorial & Pointers

2006-11-11T19:32:42Z

Artojon: removed extra category

[[Category:wxSmith Documentation]]
= "Hello world" Tutorial =

Since wxSmith is able to do something already it's high time to write a small tutorial on how to use it.
At the very beginning, I must point out that to use wxSmith you MUST have wxWidgets compiled (version 2.6 or later). Build instructions can be found [[Compiling wxWidgets 2.6.2 to develop Code::Blocks (MSW)|here]]

WARNING: wxSmith is still unstable. So use it at Your own risk. And there's no undo yet. I warned You ;)

Ok, let's start :)

== wxWidgets starts to breathe ==

wxSmith can be used inside any wxWidgets project. However, we currently have only one option to ''easily'' create a wxWidgets app.
Simply select '''File -> New Project -> wxWidgets Application''' from the menu.
If You have compiled wxWidgets using the wiki tutorial, select '''Using wxWidgets DLL''' in '''Project Options'''. Hit Create and save the project.
If you're running on Windows, you probably will have to change the WX_DIR Custom variable. It should point to the root wxWidgets directory and it can be changed in '''Project -> Build Options''' menu in the '''Custom variables''' tab.

After this step you should be able to produce an app like this:

[[Image:WXSMITH1.JPG]]

=== Let's add some fireworks ===

Now it's time to fill the empty frame with our "Hello World" message. We will do this by placing a panel over the frame.
Select '''wxSmith -> Add Panel''' from menu. If you're doing this for the first time in a project, it should display this message box:

[[Image:WXSMITH2.JPG]]

Just click Yes, it will bring up a configuration dialog. You can set-up following options here:
* Class Name - name of class which will contain our panel
* Header File / Source File - files which will contain the panel's class
* Xrc File - selecting this option allow you to use a xrc file containing the panel's data

In our tutorial we will use a class named "HelloWorldPnl" (notice that usually when typing a class name, header and source file names are generated automatically). The config dialog should look like this:

[[Image:WXSMITH3.JPG]]

Click Create and we have our panel right in the editor

== Building window ==

wxWidgets comes with something called ''Sizers''. But what is this for?
If You have been working with java you will remember something called Layout managers. Implementation in wxWidgets differs a little bit but it does almost the same.
Ok, but let's put some explanation here:
Usually when adding items into windows You must specify the item's position and size. wxWidgets tries to automate this process and it uses sizers for that. They are automatic positioning and sizing window items. Sizers have one big advantage. When You write cross-platform applications, you cannot assume that fonts, buttons, etc. are sized the same from one platform to another. This can even occur on the same platform. When You use sizers, You don't have to worry about that. All sizing is done automatically. And one more thing - sizers can even reposition and resize window items when the window itself changes size.
So, let's add some sizers here. But first...

=== How can I add something ? ===

In a newly opened editor you will see eight black boxes around something which looks like a button without a label

[[Image:WXSMITH4.JPG]]

These black boxes are surrounding a currently selected item. In our case it's a whole panel.
Adding new item is simply done by clicking on one of the buttons in the palette at the bottom of the C::B window.

[[Image:WXSMITH5.JPG]]

These buttons have small pictures showing what they add. If you're unsure, hold the mouse over the button and, after a moment, you will see the name of the wxWidgets class that the button represents - that's our item.

New items are added relatively to the current selection. You can add new item in one of three ways:
* Before the currently selected widget
* After the currently selected widget
* Into the currently selected widget
You change the insert method via a palette (it should be easy to find ;)). (big buttons, far right)
Note that all three insertions settings are not always accessible. For example You cannot add anything into a button. There are also some special situations when You cannot add new item:
* When an item has sizer inside, it cannot contain anything else. Items can be added into the sizer only
* When an item has anything but a sizer inside, you cannot add a sizer into it.
* Spacers (empty fields added into sizers instead of real items) can be added into a sizers only

Always make sure that a valid item is selected and that a valid insertion method is chosen.

=== Adding items ===

There are five types of sizers in wxWidgets, four are currently supported inside wxSmith (wxGridBagSizer is not supported yet). If You wish to learn about sizers I propose [http://www.wxwidgets.org/manuals/2.6.1/wx_sizeroverview.html#sizeroverview wxWidgets doccumentation]
In our sample we will add wxFlexGridSizer. Perform the following:

* Select panel by clicking on it.
* Click on the wxFlexGridSizer button (third in Layout row).

You probably noticed that our panel decreased it's sizer. This is because the sizer automatically adjusts to the minimal size of it's parent. And there's an additional red border - it shows where the sizer is located.

Because this is a "Hello World" application, we'll put the text into a newly created sizer. To do this:

* Select sizer (click somewhere insided red border)
* Make sure that the Insetion Type is ''Into''
* Click on the wxStaticText button
* Click on the newly created text item (should be "Label") and go to properties (The Properties panel is inside the Resources tab at the left of C::B Use the little arrows at the top of the Management panel to find the Resources Panel if its hidden )
* Change the Label property to "Hello World !!"

And because this text looks so lonely, we'll add another button here:

* Select the newly created text (now "Hello World !!")
* Chose the "''After''" Insertion type
* Click on the wxButton icon

Ok, now we have this:

[[Image:WXSMITH6.JPG]]

But I would prefer to put this button below the text. How to do this ?
As I mentioned before, sizers are automatic positioning items and, in our case, the sizer decided to put the widgets in a horizontal row, one next to another. If we want them to be in a vertical colume, we need to change some properties for the sizer:
* Select wxFlexGridSizer in the resources tree representing the structure of our window (to the left, in the Resources panel)
* Expand "Cols x Rows" property and change the X value to 1.
What have we done ?
We instructed the sizer to create only one column of widgets. Alternatively, we could have set the number of rows (Y) to 2. The effect would have been the same. Setting the values to 0 means that the sizer has to find its values automatically. Ok, let's see what we've done.

=== Using the created panel ===

In this tutorial we will put our panel over the main frame. To do this:
* Open the main.cpp file
* Add '''#include "helloworldpnl.h"''' to the beginning of the file
* At the end of '''MyFrame::MyFrame''' add the statement '''new HelloWorldPnl(this);'''
* Compile and Run

You should see something like this:

[[Image:WXSMITH7.JPG]]

=== But I want it to look better ===

Let's see. I would like my panel to be more interesting, I want it to change when we resize our window. And I want a bigger font, and let's say, a blue font colour. The first can be done using the previously created wxFlexGridSizer. It needs just a few modifications:

* Select wxFlexGridSizer from the resource browser
* Change growable cols property to 0 (zero)
* Change growable rows property to 0 (zero)
The changed properties keep information about columns and rows which should expand when the window changes size. Values are integers (zero-based indexes) separated by commas.

The second is also easy:
* Select wxStaticText from the resource browser (or click on it in the editor)
* Find font property and expand it
* Change Use Font to True
* Click on font property below - a button with "..." will appear, click on it
* Select new font, I used "Times New Roman", Bold, size: 20
* Find foreground property and expand it
* Change Use Colour to true
* In Colour below select Custom, colour dialog will appear
* Select colour You like :)

Ok, let's compile & run.
Now when we resize the window, our panel changes dynamically, the font is bigger and the colour has changed :)

[[Image:WXSMITH8.JPG]]

=== How to make buttons respond ===

Now we'll add an action to our button. Let's say it will close the program. First, let's change the button label to "Close". This should be pretty easy and I hope You won't have any problems with it.
Ok, now let's add some action.

wxWidgets works like many other GUI systems - through events. An event is a small peace of information saying that something has happened - for example, the user clicked on a button. But we want to ''do'' something when such and event happens. To connect events with actions we have to create an event handler. wxSmith can do this automatically:

* Select the button
* Switch to the Events tab (if you see properties, it's right there)
* In the line named EVT_BUTTON choose "-- Add new handler --"
* Change the event handler name to something you like (I will leave it as it is ;)) and click OK

As You can see, a new empty function has been created

void HelloWorldPnl::OnButton1Click(wxCommandEvent& event)
{
}

Here we can write some code that will be executed when you press the button.
So, let's add a Close() command

void HelloWorldPnl::OnButton1Click(wxCommandEvent& event)
{
Close();
}

and see what happens. I click on Close button and... nothing happens. Why ?
Because we closed the panel, not the whole window. How do I know that ?
Our event handler is a member of the HelloWorldPnl class. Everything inside the event handler pertains to the panel, not the outer window. When we called Close() we called this function in the wxPanel class.
But how can we close the main frame? Change the code to:

void HelloWorldPnl::OnButton1Click(wxCommandEvent& event)
{
GetParent()->Close();
}

The GetParent() function will return a pointer to the parent window - frame. Now Close() is being called on the panels parent, the window. But be careful. Our example was easy and we just assumed that main frame will be the panel's parent. Usually we can not be so sure.

Our Hello World application is ready to go :) I hope It wasn't boring. Not bored ? Then read next chapter ;)

= Pointers =

== Some technical info ==

Ok, I'll try to explain how wxSmith affects our code, how to work with it, why you shouldn't be worried about losing your code.

=== Where wxSmith generates its code ? ===

wxSmith is not as intelligent as it may seem ;) When we say it generates code, it simply replaces whole code pieces without wondering if code is placed in the right position.
But the code works. How is it done ?!

When You look into files generated inside wxSmith, you may find some special comments like :

//(*Headers(HelloWorldPnl)
//*)

These comments are used by wxSmith to find the place where new code should be applied.
Each ''//(*'' comment starts automatically generated block of code and ''//*)'' closes it. Everything between these comments is regenerated, even if you add something there

The only exception is a block started with the ''//(*Handlers'' comment. wxSmith can only '''add''' to this block of code. If you want to write your event handler manually, you can put its declaration here.

Code outside the ''//(*'' - ''//*)'' comments won't be touched.

== Loading XRC resources ==

When using an XRC file, do not forget to initialize the wxXMLResouce Handlers & XRC File. For example in your App::OnInit:

// Loading XRC resource file (not in a zip file).
wxXmlResource::Get()->InitAllHandlers();
wxXmlResource::Get()->Load("<your XRC File name>.xrc");

Adding new widget to wxSmith

2006-11-11T19:32:04Z

Artojon: removed extra category

[[Category:wxSmith Documentation]]
'''Warning: Not finished yet'''

Hi. Because wxSmith is still under development it misses some standard widgets in it's palette. I hope this will change soon. But If you really need some kind of widget maybe you could help us a little bit with wxSmith development :).

At the very beginning I must point that technique described here will work with default widget set and I cannot grant that this will work with external ones. There may be a problem even with standard ones but hopefully we could work on that together ;)

== Quick guide ==

Here I will show how to add new widget realy fast. It will work only with widgets that have no children. Let's see an example (source files should be placed inside defwidgets directory since wxSmith uses such convention). Here's extra-commented source code for wxSpinButton widget:

wxsspinbutton.h:

#ifndef __WXSSPINBUTTON_H
#define __WXSSPINBUTTON_H

#include "../wxsdefwidget.h" // this file declares most of usefull macros
#include "wxsstdmanager.h" // declaration of default widget manager

WXS_ST_DECLARE(wxsSpinButtonStyles) // declaring styles for wxsSpinButton class
WXS_EV_DECLARE(wxsSpinButtonEvents) // declaring events for wxsSpinButtin class

wxsDWDeclareBegin(wxsSpinButton,wxsSpinButtonId) // Beginning of class declaration

// Here are additional properties (standard ones like position/size etc.
// are processeed automatically)
int value;
int min;
int max;
wxsDWDeclareEnd() // End of class declaration

#endif

wxsxspinbutton.cpp:

#include "../wxsheaders.h" // Standard include for precompiled headers
#include "wxsspinbutton.h"

#include <wx/spinbutt.h>

// Here's definition of spin button styles
WXS_ST_BEGIN(wxsSpinButtonStyles)

// Category definition - currently not used but maybe in future ;)
WXS_ST_CATEGORY("wxSpinButton")

// Example of masked style (available in one platform/not available in xrc etc.)
WXS_ST_MASK(wxSP_HORIZONTAL,wxsSFAll,wxsSFGTK,true)

// Example of standard style (available everywhere)
WXS_ST(wxSP_VERTICAL)

WXS_ST(wxSP_ARROW_KEYS)
WXS_ST(wxSP_WRAP)
WXS_ST_END(wxsSpinButtonStyles)

// Here's dedfinition of spin button events
WXS_EV_BEGIN(wxsSpinButtonEvents)
WXS_EVI(EVT_SPIN,wxSpinEvent,Change)
WXS_EVI(EVT_SPIN_UP,wxSpinEvent,ChangeUp)
WXS_EVI(EVT_SPIN_DOWN,wxSpinEvent,ChangeDown)
WXS_EV_DEFAULTS()
WXS_EV_END(wxsSpinButtonEvents)

// Declaration of spin button widget
wxsDWDefineBegin(wxsSpinButton,wxSpinButton,
WXS_THIS = new wxSpinButton(WXS_PARENT,WXS_ID,WXS_POS,WXS_SIZE,WXS_STYLE);
WXS_THIS->SetRange(min,max);
WXS_THIS->SetValue(value); // This is code producing this widget
)

// Bindings for additional properties
wxsDWDefInt(value,"Default:",0);
wxsDWDefInt(min,"Min:",0)
wxsDWDefInt(max,"Max:",100)

wxsDWDefineEnd()

Maybe it seems to be a little bit complicated but If You think so, just take a look at wxsWidget class ;) Without most of usefull macros presented here, adding new widget would be a nightmare :)

Ok, let's explain this code:

Each widget has set of styles it uses and events it throws. All is done in:

WXS_ST_DECLARE(wxsSpinButtonStyles) // declaring styles for wxsSpinButton class
WXS_EV_DECLARE(wxsSpinButtonEvents) // declaring events for wxsSpinButtin class

and

WXS_ST_BEGIN(wxsSpinButtonStyles)
...
WXS_ST_END(wxsSpinButtonStyles)

WXS_EV_BEGIN(wxsSpinButtonEvents)
...
WXS_EV_END(wxsSpinButtonEvents)

code.

First one declares events and styles (note that argument for WXS_ST_DECLARE and WXS_EV_DECLARE is name of class inside wxSmith - with wxs prefix). Second one will be described in more details.

Each entry between WXS_ST_BEGIN and WXS_ST_END can be:
* category definition - WXS_ST_CATEGORY(name) - this is currently not used but will probably be in future to dividee styles
* global style - WXS_ST(style_name)
* global extra style - WXS_EXST(style_name)
* masked style - WXS_ST_MASK(style_name,include_mask,exclude_mask,can_use_in_xrc)
* masked extra style - WXS_EXST_MASK(style_name,include_mask,exclude_mask,can_use_in_xrc)

Masked styles were added to notify that some styles work on some platforms, some other don't work on other platforms. Some styles are not used insided XRC. Platforms are defined in wxsstyle.h:

const unsigned int wxsSFWin = 0x00000002; ///< This style can be used in Windows (any)
const unsigned int wxsSFWin95 = 0x00000004; ///< This style can be used in Win95
const unsigned int wxsSFWinCE = 0x00000008; ///< This style can be used in WinCE
const unsigned int wxsSFGTK = 0x00000010; ///< This style can be used in GTK+ (any GTK)
const unsigned int wxsSFGTK12 = 0x00000020; ///< This style can be used in GTK (1.2 only)
const unsigned int wxsSFGTK20 = 0x00000040; ///< This style can be used in GTK (1.2 only)
const unsigned int wxsSFOSX = 0x00000080; ///< This style can be used in MAC (any OSX port Cocoa or Carbon)
const unsigned int wxsSFCOCOA = 0x00000100; ///< This style can be used in MAC (OSX port Cocoa API)
const unsigned int wxsSFCARBON = 0x00000200; ///< This style can be used in MAC (MacOS for Carbon CFM)
const unsigned int wxsSFMotif = 0x00000400; ///< This style can be used in Motif
const unsigned int wxsSFMGL = 0x00000800; ///< This style can be used in MGL
const unsigned int wxsSFOS2 = 0x00001000; ///< This style can be used in OS2
const unsigned int wxsSFX11 = 0x00002000; ///< This style can be used in X11
const unsigned int wxsSFPALMOS = 0x00004000; ///< This style can be used in PALMOS
const unsigned int wxsSFUNIV = 0x00008000; ///< This style can be used in wxUNIV

Meaning of macro arguments is as follows:
* include_mask - mask of platforms where style can be used. If this argument is specified, exclude_mask should be 0
* exclude_mask - mask of platforms where style does not work. If this argument is specified, include_mask should be wxsSFAll (all platforms)
* can_use_in_xrc - set to true when xrc uses this style or false if not (but it's listed in documentation)

Next thing are events. They are defined between WXS_EV_BEGIN and WXS_EV_END macros:
* Event using identifier: WXS_EVI(entry_name,argument_type,default_name) - where entry_name is name of this entry in event array, argumetn_name is name of wxEvent-derived class passed as argument in this handler, default_name - default suffix for new event handlers (without "")
* Event not using identifiers: WXS_EV(entry_name,argument_type,default_name) - these may be only used in top-level objects like wxDialog. Meaning of arguments is the same.
* At the end of events list is WXS_EV_DEFAULTS() - this macro currently does nothing but may be used in future to add common events like mouse processing etc.
* You can also use WXS_EV_CATEGORY() macro simillar to WXS_ST_CATEGORY() but it currently do nothing

Next thing is declaration. It can be easily done using wxsDWDeclareBegin() and wxsDWDeclareEnd() macros.
wxsDWDeckareBegin has two arguments - name of wxSmith class handling this widget (i usually use same names with wxWidgets classes but with wxs prefix instead of wx). The second argument is class ideentifier. Identifiers will be discussed later.
Between macros just presented there is list of additional properties. This list is standard c++ declaration. In fact You can put here anything You want to be inside class declaration.

Next thing is class definition. It's little bit harder. Class definition begins with following macro:
wxsDWDefineBegin(wxs_class_name,wx_class_name,producing_code)
where:
* wxs_class_name - name of class in wxSmith (with wxs prefix)
* wx_class_name - name of modeelled wxWidgets class (with wx prefix)
* producing_code - code used for building widget - both it's source code and visual representation in editor. I'll describe this in more details.

wxSmith must be able to build source code and show widget in editor. These two operations looks simillar. Standard widgets can do both operations automatically using producing code. It's standard c++ code creating and setting up widget but with some restrictions:
* widget which is currently built can be accessed through WXS_THIS variable
* WXS_PARENT variable is pointer to parent widget
* WXS_ID, WXS_POS, WXS_SIZE, WXS_STYLE contains values of standard properties
* operations on complex data structures (wxArrayString is currently only one supported) may be accessed through special functions only
* properties binded in class definition may be used in this code

Binding properties is done between wxsDWDefineBegin() and wxsDWDefineEnd() macros. It's done through wxsDWDef... macros:

* wxsDWDefBool(Name,PropName,Default)
* wxsDWDefBoolX(Name,XrcName,PropName,Default)
* wxsDWDefInt(Name,PropName,Default)
* wxsDWDefIntX(Name,XrcName,PropName,Default)
* wxsDWDef2Int(V1,V2,Name,PropName,Def1,Def2) - this can be used for two integers threated as one property (f.ex. some size, dimensions)
* wxsDWDef2IntX(V1,V2,Name,XrcName,PropName,Def1,Def2)
* wxsDWDefStr(Name,PropName,Default)
* wxsDWDefStrX(Name,XrcName,PropName,Default)
* wxsDWDefLongStr(Name,PropName,Default)
* wxsDWDefLongStrX(Name,XrcName,PropName,Default)
* wxsDWDefStrArray(Name,PropName,Default,SortFlag)
* wxsDWDefStrArrayX(Name,XrcParentName,XrcChildName,PropName,Default,SortFlag)

Arguments are as follows:
* Name - name of variable used for property
* PropName - name used in property editor for this property (with " characters but without unicode converting macros)
* Default - usually default value for this property (exception is StrArray where this should be name of variable which will kepp number of item selected by default)
* V1, V2 - used instead of one name of variable (something is messed up here, I'll have to clear this code, currently try not to use wxsDWDef2Int and wxsDWDef2IntX macros)
* SortFlag - flag in widget style used for sorting it's elements (used when meaning of selection property changes after adding this flag)
* XrcParentName, XrcChildName - names of parent/child xrc node names

Each property binding has two versions of binding macro - the one without X is used when name of property (variable declared in class declaration) is same as name of node inside xrc file. The one with X at the end could be useed when name of xrc node with this value is other than name of variable (f.ex. name of node is sometimes 'default' which can not be a name of variable in c++).

One additional note: when using StrArray (for binging wxArrayString properties) You can only use following functions for them in producing code:
* void wxsDWAddStrings(const wxArrayString& Array,wxControlWithItems* Ctrl) for adding strings for widget
* void wxsDWSelectString(const wxArrayString& Array,size_t Index,wxControlWithItems* Ctrl) for setting default selection

Research on doing a Plug-in for embedded help in CB

2006-11-11T19:30:55Z

Artojon: removed extra category

[[Category:Plugin development]]
> Question: ''What's so wrong about only HTB being opened inside C::B?''

It's almost ok, but there are two problems: there are little few books on this format. All of them can be getted from http://htmlhelp.berlios.de/books/htb.php
(I note the ones we could use: wxwidgets, libstdc++, gdb, gcc, make).

The other problem is that all the rendering through wxHtml is html in very basic form. That means for example, that the C::B SDK documentation is out ''(doxygen/doxys can't generate html so basic to work on wxHtml)''.

In any case, I have an implementation of wxHelpController that can be embedded in a window, so the help can be rendered in a C::B EditorBase instead of an outside window. However I think that an external window option should exist, some users couldn't like having the help embedded in C::B.

As you may know, wxHelpController can only open in it's own renderer HTB files, not CHM, nor any other.

My goals (wishes) for the plugin was/are:

==HTB support==
This should be the most easy to implement, and also the most likely to have first (if any).
It will requiere to use the reimplemented wxHelpController I have and adapting it so the embedded/external option can exist.

==CHM support==
This is one of the most important for me, because there's plenty of free CHM books everywhere. It's very comfortable to use it.

Now, the problem relies on that CHM is a MS format. But fortunately it's already reverse enginered, and it exists a program called [http://xchm.sourceforge.net xCHM] which uses that library. It was programmed for Linux only, but some months ago a Mac port appeared. There isn't in Windows (on MinGW).

But I took the source and after some (heavy?) modifications, I could compile it, and finally run it on MinGW, with very few glitches. :D

But then I discovered: [http://xchm.sourceforge.net xCHM] uses as render wxHtml, and kinda reimplements all the wxHelpController window interface.
Which is not good (using wxHtml as render), because most (almost all) CHM books out there uses CSS and HTML code that wxHtml can't cope with.

However, [http://xchm.sourceforge.net xCHM] have pieces of code that will help a lot.

==HTML support==
This is were I left frustrated. HTML is the most important format for obvious reasons. wxHtml can't render almost any page online well. And almost all API documentations have an HTML (downloadable or online) version.

And here the choices are very little:
*[http://wxmozilla.sourceforge.net wxMozilla] (Windows, Linux)
*wxIE (Windows)
*wxWebKitCtrl (Mac)

The choice I would made would be wxMozilla, but it seems that it doesn't work well on Mac yet.
Using different APIs, like using wxMozilla in linux, wxIE on windows and wxWebKitCtrl on mac could be done, but writting for 3 different APIs to do the same thing, I don't know if it's worth the effort.

But the single most important problem I have with wxMozilla (which uses an embedded Gecko) is the huge (relative) dependacy it will add. It will take a lot of resources regarding compile time and executable size, which I couldn't decide if it was the effort or not.

==DevHelp support==
http://developer.imendio.com/wiki/Devhelp

It's a CHM-like format but OpenSource, used mostly for Linux APIs. Not a priority, but something to have in mind.

==PDF support==
Probably a tough one, not easy to do, unless there is a wx PDF friendly library.
I think the best approach here would be the same as is now: calling Acrobat Reader or whatever, because there are almost always PDF readers installed on any platforms, so it ''shouldn't'' be a concern like the other formats (except HTML), that are available most of times in only one platform.
So not important for now.

==Man pages and Info pages support==
This is low on the priority list also. But given the simple these formats are, we could write a parser for them that displays them in the HTML window. Note that I've spent a lot of time searching for '''any''' Man or Info pages reader for windows, but there is nothing (yes I was surprised to know that, but no, there isn't a man nor info win32 port yet, neither any other program can open them).

=Conclusions=
My conclusions are that the single most important problem right now is wxHtml incompetence. And I've reading some wx-devel lists saying that everyone is aware of the poor render of wxHTML, and that they were looking for using already existant implementations at some future (even with more than one backend in the same platform).

If you ask me, the best thing wxWidgets developers can do with wxHtml, is reimplementing all the [[wikipedia:KHTML|KHTML API]], which is a '''lot''' lightweight than Mozilla. And it's the first and only (yet) OpenSource HTML layout engine to pass the CSS Acid2 test.

-- Takeshi Miya

Creating a Plug-in which modifies CB's Menus

2006-11-11T19:30:20Z

Artojon: removed extra category

[[Category:Plugin development]]
== Environment ==

NOTE : Also an update for wx 2.6.1 and creating a menu in the menu toolbar are in the pipeline.

The following has been carried out with/on :

* Windows XP SP2
* Code::Blocks RC1-1
* wxWindows 2.4.2

The entire project is available in [http://users.pandora.be/lieven.de.cock/CodeBlocks/Ldc2.zip this zip file]

== Create the plug-in project ==

First thing we need to do is create a plug-in project. For more info on how to setup everything see [https://wiki.codeblocks.org/index.php/Creating_a_simple_%22Hello_World%22_plugin this page] on the wiki. In our tutorial we create a plug-in of type General.
I gave it the name LDC2, and selected the settings :

* Needs to create menu items
* Needs to create menu items in pop-up menus
[[Image:Menu0.PNG]]

Afterwards the code get's generated (LDC2.h/cpp). Try to build the project. I encountered 1 problem : I had to change the line in the header file :
void BuildToolBar(wxToolBar* toolBar){ return; }
to :
bool BuildToolBar(wxToolBar* toolBar){ return false; }
After doing this it compiled fine for me.

== Logging during the plug-in ==

During the implementation I am going to write some feedback stuff on the screen. I chose to use the log facilities that allow you to write to the Code::Blocks tab in the output pane (which also contains a "Search Results", "Compiler", ... tabs).
To do this we need to do the following things :

* Get hold of the Manager interface which we can use to retrieve other interfaces
* Get hold of the MessageManager interface, which we will be using for the logging

Both can be done in 1 statement : Manager::Get()->GetMessageManager() .
To be able to call those functions we need to add the declarations of those functions, therefor we add the following include statements in the implemenation file :
#include <manager.h>
#include <messagemanager.h>
The method I use for logging is Log(), which has a similar syntax as nasty old printf.

== Menu adjusting ==

If your plug-in wants to adjust the menu, the correct place to do it is in the BuildMenu method.
When Code::Blocks is starting up it will call your plug-in by this method, allowing you to change the menu. Therefor it provides as an argument it's menuBar.
The normal menuBar consists out of 11 menus, starting with "File", "Edit", "View" and so on. These menus are ordered, or otherwise stated they have a position. Where the first position is position "0". So "File" is at position 0, "Edit " at position 1, ...
So let's get our feet wet and start by adjusting the "Edit" menu.

== Adjusting the "Edit" menu ==

The first thing we need to do is get hold of the "Edit" menu. The class wxMenuBar, the type of our menuBar parameter, provides the method "FindMenu" to search for certain menus. The menu to search for is the argument of the method, and is specified by it's textual id, and returns the position of the menu. So in our case we get :
int pos = menuBar->FindItem(_("Edit"));
If this menu would not be found the return value is wxNOT_FOUND.
In the example code, we write out the position of the menu to the Log. Check that this should be 1.
Now that we have the position of the menu, we can get hold of it's interface (or pointer to the menu object), this is done by calling the GetMenu() method of he wxMenuBar class. The argument is the position of the menu, from which we want the interface.
wxMenu* EditMenu = menuBar->GetMenu(pos);
Now that we have hold of the actual menu we want to adjust, we can start by adding new entries to the menu.
We have several locations where we can add our own entries :

* at the start/beginning/top => Prepend
* at the end/bottom => Append
* in the middle => Insert

It is good practice when you add new entries, that you seperate them visually from the already existing entries, or to group them logically. This can be done by use of a separator, this is a vertical line that goes from left to right in the menu. The menu class wxMenu provides for the 3 cases above, 3 different methods :

* AppendSeparator()
* PrependSeparator()
* InsertSeperator(int pos), where pos is the position of the entry at which it should be inserted.

For our entries we have the following methods at our disposal according to the 3 situations described above :

* Append()
* Prepend()
* Insert()

There is however one more thing we need to take care of, before we can proceed for adding our own entries. Every menu entry needs to have a unique id in the program. Since we are a plug-in, and those can be added dynamically, we have no idea of which id's are already taken and which are available. Luckily the underlying wxWindows mechanism takes care of that for us. We can ask the wxWindows mechanism to generate a new id for us, and then we use that one. This is done by calling the function "wxNewId". So for our first entry we do like this :
int idMenuEntry1 = wxNewId();
This id can be used to identiy our own menu entries.

Now let's add our first extra entry in the menu :
EditMenu->Append(idMenuEntry1, _("Menu Entry 1\tCtrl-Shift-1"));
So the id is specified as the first parameter to the Append method, and as a second argument we specify the Caption of the menu entry "Menu Entry 1", and in the mean time we specify the keyboard accelerator/shortcut. Both are specified in a string seperated by a tab character (\t).
The picture below show the result of adding our first extra menu entry together with a separator.

[[Image:Menu1.PNG]]

Next in our code example we add a menu entry at the top of the menu, and we use a third argument (works with all 3 methods to add entries) where we specify a help text to be displayed in the status bar of Code::Blocks.
EditMenu->Prepend(idMenuEntry2, _("Menu Entry 2\tCtrl-Shift-2"), _("Help text"));
The result looks like this :

[[Image:Menu2.PNG]]

Next we add a third entry somewhere in between, we add it after the Redo entry and the following separator. That Redo is the 4th entry, so counting from zero : pos 3. Menu entry 2 is at O, Seperator at 1, Undo at 2, Redo at 3. So our new entry is at position 4..
EditMenu->Insert(4, idMenuEntry3, _("Menu Entry 3\tCtrl-Shift-3"));
Wich gives the following result :

[[Image:Menu3.JPG]]

So by locating our menu, getting it's interface, and using some methods we were able to add new menu entries.

== Adding a submenu ==

Let's take our manipulation of the menu 1 step further. Let's create a submenu, which has its own entries.
Since a submenu is nothing more then a menu, we first need to create a new menu object; this new object has to live as long as the plug-in itself, so it can not be a local variable, it needs to be stored in the class itself. Therefor we added the member m_SubMenu1, initialized to NULL, and released during the destructor.
We will allocate it now :
m_SubMenu1 = new wxMenu();
And we append this new menu to our EditMenu :
EditMenu->Append(idSubMenu1, _("SubMenu1"), m_SubMenu1);
The result looks like :

[[Image:Menu4.JPG]]

The next task is adding an entry into this new menu.
We already have hold of the menu interface (we just created it), nevertheless let's see what we need to do in the case we would not have it's interface yet (for example if we want to add entries to an existing submenu).
As submenu together with the other entries in the menu are called menuItem's. So within the "Edit" menu we need to search for the item "SubMenu1" and we will get in return, in the case it is found, it's position.
int idSub = EditMenu->FindItem(_("SubMenu1"));
Once we have the position we can retrieve the interface of the item.
wxMenuItem* SubMenu1Item = EditMenu->FindItem(idSub, NULL);
Just fill in NULL as the second argument (I still need to find out what's its purpose).
From the item we can retrieve the actual submenu as follows :
wxMenu* SubMenu1 = SubMenu1Item->GetSubMenu();
And now we add like before a new entry.
The result looks like :

[[Image:Menu5.JPG]]

== Modifying the context menu of the editor ==

Another menu we can adjust is the pop-up menu you get by right-clicking in the editor pane of an open source file, sometimes also called the context menu.
As with the regular menu, the application will call a method of our plug-in to allow us to adjust the context menu. The method is "BuildModuleMenu", as arguments we get the type of the Module generating the context menu, and the interface of that menu. So things are very easy here, we get the menu interface directly.
We only need to make sure that :

* we are attached
* the menu does exist
* the module type is that of the editor manager

In code the test on the type looks like :
if(type == mtEditorManager)
And next we can add an entry like :
menu->Append(idContextMenuEntry1, _("Context Menu Entry 1"));

The result looks like :

[[Image:Menu6.JPG]]

So this was a piece of cake.

== Making all those menus do something ==

Now that we have added all those new menu entries, it would be nice that they actually do something. If you select them at this moment nothing happens. Nevertheless they already did something behind the scenes. When you click on a menu entry they generate a wxCommand event. It is our duty to listen to those events and provide a handler for them. A handler can be seen as a method that does the stuff we want to happen when the menu entry is selected.
Those handlers should have the following signature :
void ClassName::MethodName(wxCommandEvent& event);
So for our 4 menu entries we have now, we add the following declarations in the header, in the private section :
void OnMenuEntry1(wxCommandEvent& event);
void OnMenuEntry2(wxCommandEvent& event);
void OnMenuEntry3(wxCommandEvent& event);
void OnMenuEntry4(wxCommandEvent& event);
And we provide some dummy implementation, they just write to the Log, telling us they were selected, now how about that for usefull functionality.

All that's left to do is provide the missing link : connect the event to it's handler.
What we already know is that each menu entry has an unique id. The way wxWindows work is that we have to link that id with the event handler.
Those links are specified in the implementation file in the block :
BEGIN_EVENT_TABLE(Ldc2, cbPlugin)
// add events here...
END_EVENT_TABLE()
This was placed in the generated code by the Plug-In wizard. Also in the class declaration we find such a directive : DECLARE_EVENT_TABLE()
The BEGIN_EVENT_TABLE directive tells that our class Ldc2 listens to the same events as the cbPlugIn (our class was derived from cbPlugIn). Personal note : I hope this statement is correct.
Next we create mappings as follows :
EVT_MENU(idMenuEntry1, Ldc2::OnMenuEntry1)
By means of the directive EVT_MENU we map our id idMenuEntry1 to the handler Ldc2::OnMenuEntry1
Where in our example the end result is :
BEGIN_EVENT_TABLE(Ldc2, cbPlugin)
// add events here...
EVT_MENU(idMenuEntry1, Ldc2::OnMenuEntry1)
EVT_MENU(idMenuEntry2, Ldc2::OnMenuEntry2)
EVT_MENU(idMenuEntry3, Ldc2::OnMenuEntry3)
EVT_MENU(idMenuEntry4, Ldc2::OnMenuEntry4)
END_EVENT_TABLE()
Note : no semicolons at the end.
If you have compiled our example code, put the dll in the subdir .\share\CodeBlocks\plugins of Code::Blocks installation directory, you can try out the menus and see how it actually does work. ;-)
In the project zip file, the dll is also included.
The following screenshot shows the Log when we choose some of our menu entries.

[[Image:Menu7.JPG]]

That's all for now, more tutorials will follow. Enjoy.
I would like to thank Mandrav and the rest of the Code::Blocks team for this great IDE, and also Thomas who gave me my first pointers on where to find some information.

Creating a simple "Hello World" plugin

2006-11-11T19:29:42Z

Artojon: removed extra category

[[Category:Plugin development]]
'''NOTE''': This tutorial was written using the Code::Blocks final beta under windows.

==Prerequisites==

This tutorial assumes you have a working version of Code::Blocks installed and some knowledge of how to deal with projects, in particular how to compile them. In order to use the Code::Blocks SDK you must also have a working version of wxWidgets installed. For more information see
[[Compiling wxWidgets 2.6.2 to develop Code::Blocks (MSW)|Compiling wxWidgets 2.6.2 to develop Code::Blocks]]

To develop Code::Blocks plugins you will also need a copy of the Code::Blocks SDK, which can be found on the Code::Blocks [https://www.codeblocks.org/downloads.shtml download page]. Install this to somewhere sensible that you will remember later on. Personally I keep the SDK in a folder called CodeBlocks\sdk (which contains the include/ and lib/ from in the zip). This means that the header files refered to in the tutorial would be found under ''Codeblocks\sdk\include'', so ''cbPlugin.h'' is ''Codeblocks\sdk\include\cbPlugin.h'' for example.

==Overview==

This tutorial will guide you through the creation of a simple "Hello World" plugin, which when activated displays "Hello World!" in the Code::Blocks log tab below the editor. This could be done completely by hand, but Code::Blocks contains a very useful plugin project generator (which, incidentally, is a plugin itself), so we'll use that.

==Creating the Plugin Project==

Select the '''Plugins->Code::Blocks Plugin Wizard''' option from the main menu bar and choose a suitable project name and location. Save the project, and another dialog will be shown which allows you to select various options for your plugin.

===Plugin Type===

The Code::Blocks SDK contains interfaces for various different types of plugins in the ''cbPlugin.h'' file. The drop down ''Plugin type'' list in the wizard allows you to select which type of plugin you wish to build - essentially which class the main plugin interface class will inherit from. We want to build a Tool plugin, so select that from the list. Tool type plugins are added to the Plugins main menu submenu automatically, and their ''Execute'' method is called when they are selected by the user. We will use this later in order to display our message.

===Plugin Info===

The ''Plugin name'' field is the name of the plugin interface class which the wizard will create. Enter "HelloWorldPlugin" here. More information can be provided by clicking on the ''Enter Plugin Info'' button. The fields here are fairly self explanitory, but one which you should pay particular attention to is the ''Title'' field, since this is what Code::Blocks will use to refer to the plugin in the menus. In the generated code, the plugin info is kept in the plugin class' ''m_PluginInfo'' member, which is of the type ''PluginInfo'' and is set in the plugin interface class' constructor. ''PluginInfo'' is detailed in ''cbPlugin.h'', if you want to go take a look.

===Provides Configuration Dialog===

This indicates whether or not the plugin is to provide a configuration dialog which can be accessed through the '''Settings->Configure Plugins''' submenu. We don't need one, so leave this box unchecked.

===Filenames===

The filenames should have been filled in automatically by the dialog when you entered the Plugin name, if you used the name "HelloWorldPlugin", for example, these should be helloworldplugin.h and helloworldplugin.cpp respectively. If you want to change the names of the files generated, this is where to do it (this tutorial will assume you have left them as the default values).

The guard-block box is simply if you wish to place inclusion guards in the header file, and if you do what symbol to use. If you don't know what these are then just leave it as it is.

Click '''Create''' and take note of the next dialog box's message about the SDK include and library directories, that's what we'll be dealing with next.

==Letting the project know where to find the SDK==

Code::Blocks should have created a new project called "Custom Plugin". Before we can compile anything we need to make sure that the compiler knows where the sdk files are in order to include headers and link the libraries. If your compiler has not been setup to know where wxWidgets is yet then this must also be done (see the links in Prerequisites for more details).

Right click on the project and select '''Build Options''' then the '''Directories''' tab. Here, make sure the '''Compiler''' tab is selected then click on the '''Add''' button. Browse to where you unzipped the SDK and select the ''include'' directory (for example ''C:\CodeBlocks\sdk\include'' if you installed the SDK there), then click okay and select whether or not the path should remain relative. Go to the "Linker" tab and add the "lib" directory under where the SDK was installed in similar fashion (following my install, this would be in ''C:\CodeBlocks\sdk\lib'').

===Linker Options===

If you click on the '''Linker Options''' tab at the top level in the Build Options dialog, you will see that the plugin is being linked to the Code::Blocks core library (codeblocks) and the wxWidgets library (wxmsw242 under windows ''NOTE: The plugin generator uses 2.4.2, if you're using a different version of wxWidgets then change this'').

===Compiler Options===

The '''Compiler Options''' tab shows that several symbols have been defined when the plugin is compiled: ''__GNUWIN32__'', ''WXUSINGDLL'' and ''BUILDING_PLUGIN'' in this case (using windows). The first two are indicators to wxWidgets of the compiler and DLL options to use, and the last is an indicator to the Code::Blocks SDK headers that they are being used to build a plugin (which affects whether or not symbols are exported or imported for the DLL - see ''cbPlugin.h'' for example).

==Adding Functionality==

The plugin wizard should have generated us helloworldplugin.h and helloworldplugin.cpp. The header file contains the class definition and a C function declaration which is used to load the plugin when asked by the main Code::Blocks program (''GetPlugin''). What we're interested in, however, is the definition of the class methods in helloworldplugin.cpp. The plugin wizard has generated us a constructor in which the ''m_PluginInfo'' information is set, and three methods. ''OnAttatch'' and ''OnRelease'' are methods called to inform the plugin when it is attached (the user has selected it and Code::Blocks has loaded it) or released (Code::Blocks no longer has a use for it or is shutting down). Since our plugin does not need to perform any actions on loading or shutting down, we can leave these as they are.

The ''Execute'' method, as mentioned earlier, is what we are really interested in. We are going to use the MessageManager class to add a log message in the window beneath the editor. To do this we will need access to both the Manager class and the MessageManager class. Manager is and internal Code::Blocks class which is used to keep track of internal information and the various task specific managers (like the MessageManager and EditorManager - which is used to keep track of all the open files and their editors). MessageManager is responsible for both normal output and debugging output (see ''messagemanager.h'' for more details). Replace the generated Execute method with this new one:

int HelloWorldPlugin::Execute()
{
if( !IsAttached() )
return -1;
Manager::Get()->GetMessageManager()->Log( _("Hello World!") );
return 0;
}

This new method uses the Manager's static Get method to return the singleton Manager object, then uses that to access the MessageManager through the GetMessageManager method. MessageManager has a method called ''Log'' which appends a string to the bottom of the output log, so we use this to add the "Hello World!" message. The _() construct is part of wxWidgets' internationalisation utilities, and more information on it can be found in the wxWidgets [http://wiki.wxwidgets.org/wiki.pl?WxWidgets_Source_Oddities documentation].

The first two lines check to see if the plugin has been attatched (in other words selected by the user in the '''Plugins->Plugin Manager''' menu), and thus whether it should perform any action at all. As far as I can tell, the return value of Execute is not used anywhere, but all the default plugins use -1 for failure and 0 for success (much like the main function in a C program) so that is what is used here.

Add headfiles to helloworldplugin.cpp

#include <manager.h>
#include <messagemanager.h>

Now we have our code in place we are ready to...

==Compile! (And test)==

This should produce a file called HelloWorldPlugin.dll, which can be tested by copying to the ''CodeBlocks\share\CodeBlocks\plugins\'' directory and restarting Code::Blocks. There should now be an option in the '''Plugins''' menu for "Hello World" (or whatever the title field was set to when the plugin was generated - or in ''m_PluginInfo''). Click on this and "Hello World!" should appear in the Code::Blocks logging window. Congratulations, you've just created your first plugin!

==Further Information==

It is essential to learn how wxWidgets works if you seriously plan on working on plugins, since most of Code::Blocks depends on it, and you will find it easier to add and manipulate components if you have a firm grasp of its principles. More information on this can be found in the wxWidgets [http://www.wxwidgets.org/docs.htm documentation]. Another good place to learn from is the source code from the existing Code::Blocks plugins, which can be downloaded along with the rest of the Code::Blocks source code from the [https://www.codeblocks.org/downloads.shtml download page].

Hopefully this tutorial has helped you work through a few fundamentals in terms of creating plugins, happy coding!

Creating a plugin that actually does something

2006-11-11T19:29:02Z

Artojon: removed extra category

[[Category:Plugin development]]
''NOTE: this article is a work in progress.''

In this article we are going to create a "real" plugin. That is a plugin that actually does something more elaborate than just greeting the world ;).

== Interpreted languages support plugin ==

We are going to create a plugin that will add support for interpreted languages in Code::Blocks. "Interpreted" are considered the languages that do not generate native machine code but rather generate an intermediate code that an interpreter understands and converts to native machine code at runtime.

=== Planning stage ===

While we 're in the early development stage (a.k.a. planning), let's decide what this plugin will be able to do and what it won't.
This plugin should allow the user to:

* define as many interpreters as needed
* associate specific file extensions with each interpreter
* run any interpreter's shell
* run any interpreter with the appropriate arguments to operate on or accept as input a source file (more on that below)

As you see, while we 're not over-complicating things, we should hopefully end up with a really useful plugin :).

==== Data structures ====

Let's decide now what structures we will need (code-wise) to store the above requirements and their relationships.

'''Requirement: define as many interpreters as needed.'''

Since we don't want to impose any limits, we need a dynamic container of some sort. I guess std::vector will suite us just fine :).

'''Requirement: associate specific file extensions with each interpreter.'''

A simple semicolon-separated string will suffice. E.g. <tt>"*.py;*.pyc"</tt>.

'''Requirement: run any interpreter's shell.'''

A string is enough. E.g. "C:\Python\Python24\pythonw.exe".

'''Requirement: run any interpreter with the appropriate arguments to operate on or accept as input a source file.'''

So we need a dynamic array holding somekind of struct defining the available actions. Because nothing beats a good example, here is the most common (and important action): "Run". This action would cause the interpreter to be launched with the source file as argument and run it.

struct InterpreterAction
{
wxString name; // the action's name, e.g. "Run"
wxString command; // the command, e.g. "$interpreter --run $file"
};

The final struct that glues all of the above together is this:
struct Interpreter
{
wxString name; // a friendly name for the interpreter
wxString executable; // the full path to the interpreter's executable
wxString extensions; // a semicolon-separated list of extension wildcards (e.g. "*.py;*.pyc")
std::vector<InterpreterAction> actions; // an array of possible actions with this interpreter
};

=== Implementation stage ===

Let's roll our sleeves up and start working on this plugin :).

First thing we need is to create a new project for this plugin. Thankfully, the Code::Blocks Team has already provided us with a nice and easy wizard that will generate all the boilerplate code for us. Let's get going.

Click on "File->New->Project" and a dialog with the available project wizards will appear. Select the "Code::Blocks plugin" and click "Go".
[[Image:Intlng_1.png]]

This will start the Code::Blocks plugin wizard. The first page of this wizard displays some important info which you should read. When you 're done reading, click "Next".

Now enter the plugin's title, e.g. "Interpreted languages support". If you don't need to edit anything else in this page (like the destination directory), click "Next".

[[Image:Intlng_2.png]]

In this page, we must decide what type of plugin we want to make as well as its name. For the name enter "InterpretedLangs".
Also, set the plugin's type to "Generic". For more info on the various plugin types and their differences, see the Code::Blocks SDK documentation.
Finally, make sure you check the options as seen in the picture above. This will allow our plugin to add a configuration page in the Code::Blocks settings dialogs and generally integrate nicer.
Click "Next".

In the next page, fill in any info you deem appropriate for this plugin. Click "Next".

In the compiler page, select (if not already selected) the "GCC" compiler because that's what Code::Blocks is built with.

Finally click "Finish".

You should find yourself in Code::Blocks again with the new plugin project open and ready for editing :).
But first let's see if this compiles. If it doesn't, don't bother reading more. This article assumes a valid development setup from your side...

Note that the Code::Blocks plugin wizard was kind enough to add some post-build commands that will copy the plugin and its resources where Code::Blocks expects to find them. It even set Code::Blocks as a "host" application for our plugin (which is a dynamic library and can't run on its own). This means that after you build the plugin, you can "run" it too :).

Go on, build and run it. Does it work? OK, let's move on :)

To be continued...

[[User:Mandrav|Mandrav]] 06:51, 22 September 2006 (EDT)

Internationalization

2006-11-11T19:27:31Z

Artojon: removed extra category

[[Category:Developer Documentation]]

This article is about how to realize and use localized C:B. All the works have been done under Windows XP SP2.

== Get the English POT file ==

The english POT file url is:

https://developer.berlios.de/patch/?func=detailpatch&patch_id=822&group_id=5358

I will update this file periodically. Of course, you can use the tool which I have created (see belown) to generate the POT file.

The content of the tool which is named as '''intl.bat''' is below:

rem ======= Begin of intl.bat =======

@echo off
wxrc src\resources\*.xrc -g -o src\src-xrc.cpp
wxrc sdk\resources\*.xrc -g -o sdk\sdk-xrc.cpp
wxrc plugins\astyle\resources\*.xrc -g -o plugins\astyle\astyle-xrc.cpp
wxrc plugins\classwizard\resources\*.xrc -g -o plugins\classwizard\classwizard-xrc.cpp
wxrc plugins\codecompletion\resources\*.xrc -g -o plugins\codecompletion\codecompletion-xrc.cpp
wxrc plugins\compilergcc\resources\*.xrc -g -o plugins\compilergcc\compilergcc-xrc.cpp
wxrc plugins\debuggergdb\resources\*.xrc -g -o plugins\debuggergdb\debuggergdb-xrc.cpp
wxrc plugins\defaultmimehandler\resources\*.xrc -g -o plugins\defaultmimehandler\defaultmimehandler-xrc.cpp
wxrc plugins\todo\resources\*.xrc -g -o plugins\todo\todo-xrc.cpp
wxrc plugins\autosave\*.xrc -g -o plugins\autosave\autosave-xrc.cpp
wxrc plugins\scriptedwizard\resources\plugins\*.xrc -g -o plugins\scriptedwizard\resources\plugins\scriptedwizard-xrc.cpp
wxrc plugins\scriptedwizard\resources\wxwidgets\*.xrc -g -o plugins\scriptedwizard\resources\wxwidgets\wxwidgets-xrc.cpp

if not exist po md po

xgettext -C -n -k_ -o po\codeblocks.pot src\*.cpp src\*.h
xgettext -C -n -k_ -j -o po\codeblocks.pot src\wxAUI\*.cpp src\wxAUI\*.h
xgettext -C -n -k_ -j -o po\codeblocks.pot sdk\*.cpp sdk\*.h
xgettext -C -n -k_ -j -o po\codeblocks.pot sdk\propgrid\src\propgrid\*.cpp sdk\propgrid\include\wx\propgrid\*.h
xgettext -C -n -k_ -j -o po\codeblocks.pot sdk\wxFlatNotebook\*.cpp
xgettext -C -n -k_ -j -o po\codeblocks.pot sdk\scripting\bindings\*.cpp sdk\scripting\bindings\*.h
xgettext -C -n -k_ -j -o po\codeblocks.pot plugins\codecompletion\*.cpp plugins\codecompletion\*.h
xgettext -C -n -k_ -j -o po\codeblocks.pot plugins\codecompletion\parser\*.cpp plugins\codecompletion\parser\*.h
xgettext -C -n -k_ -j -o po\codeblocks.pot plugins\astyle\*.cpp plugins\astyle\*.h
xgettext -C -n -k_ -j -o po\codeblocks.pot plugins\astyle\astyle\*.cpp plugins\astyle\astyle\*.h
xgettext -C -n -k_ -j -o po\codeblocks.pot plugins\classwizard\*.cpp plugins\classwizard\*.h
xgettext -C -n -k_ -j -o po\codeblocks.pot plugins\codecompletion\*.cpp plugins\codecompletion\*.h
xgettext -C -n -k_ -j -o po\codeblocks.pot plugins\compilergcc\*.cpp plugins\compilergcc\*.h
xgettext -C -n -k_ -j -o po\codeblocks.pot plugins\debuggergdb\*.cpp plugins\debuggergdb\*.h
xgettext -C -n -k_ -j -o po\codeblocks.pot plugins\defaultmimehandler\*.cpp plugins\defaultmimehandler\*.h
xgettext -C -n -k_ -j -o po\codeblocks.pot plugins\todo\*.cpp plugins\todo\*.h
xgettext -C -n -k_ -j -o po\codeblocks.pot plugins\xpmanifest\*.cpp plugins\xpmanifest\*.h
xgettext -C -n -k_ -j -o po\codeblocks.pot plugins\autosave\*.cpp plugins\autosave\*.h
xgettext -C -n -k_ -j -o po\codeblocks.pot plugins\scriptedwizard\*.cpp plugins\scriptedwizard\*.h
xgettext -C -n -k_ -j -o po\codeblocks.pot plugins\scriptedwizard\resources\plugins\templates\*.cpp plugins\scriptedwizard\resources\plugins\templates\*.h
xgettext -C -n -k_ -j -o po\codeblocks.pot plugins\scriptedwizard\resources\wxwidgets\common\*.cpp plugins\scriptedwizard\resources\wxwidgets\common\*.h
pause

rem ======= End of intl.bat =======

== The translation tool ==

Usually, we use the poEdit tool which can be downloaded [http://www.poedit.org/download.php here].

== Translating in poEdit ==

Rename codeblocks.pot into codeblocks.po. Use poEdit to open the file codeblocks.po. Change a few settings like:

[File]->[Preferences]->[Personalize]

[Catalog]->[Settings]->[Project info]->[Team/email/Language/Charset]

If Code::Blocks is compiled with Unicode, the charset should be set to utf-8; If Code::Blocks is compiled with ANSI, the charset should be set to your own language charset like gb2312, koi8-r etc.

After these settings are done, you can start translating. Don't be fooled, it's a hard work! During the process, of course, you can use your translation at any time.

== Create and use the .mo file ==

Pressing Ctrl+S in poEdit, you can get a *.mo file like codeblocks.mo which is what we need. To use codeblocks.mo, we just place it into C:\Program Files\CodeBlocks or C:\Program Files\CodeBlocks\share\CodeBlocks\locale\<lang>\LC_MESSAGES or C:\Program Files\CodeBlocks\share\CodeBlocks\locale\<lang>. My language is Chinese and I have installed C::B into E:\, so I place codeblocks.mo into E:\Program Files\CodeBlocks\share\CodeBlocks\locale\zh_CN.

If you want to use codeblocks.mo under Linux or Unix, you just place it into /usr/X11R6/share/locale/<lang>/LC_MESSAGES/. For example, I put it into /usr/X11R6/share/locale/zh_CN/LC_MESSAGES/ under FreeBSD.

Details about internationalization using wxWidgets can be found in the wxWidgets docs.

== Let Code::Blocks support your language ==

If you want Code::Blocks to support your language, you must modify the file '''\codeblocks\src\src\appglobals.cpp'''. In it, you can search for the word 'Chinese' to see the example. There are two vars about it:

const wxString langs[LANGUAGES_SIZE]
const int locales[LANGUAGES_SIZE]

== Troubleshooting ==

If you have any questions, you can send me a mail: zxpmyth at yahoo.com.cn.

Tips'n'Tricks

2006-11-11T18:52:53Z

Artojon: moved to deletion requests; all information found in this article has been merged to other articles (User Documentation)

[[Category:Deletion Requests]]
====[[Personalities]]====
====[[Running under colinux]]====

Developer documentation

2006-11-11T18:51:11Z

Artojon: move Scripting here

[[Category:Code::Blocks Documentation]]
[[Category:Developer Documentation]]
Articles for Code::Blocks developers.

* '''[http://launchpad.net/products/codeblocks/ Translation]'''
:Code::Blocks uses Launchpad to coordinate translation efforts.

* '''[[Coding style]]'''
:The source code formatting style used in the Code::Blocks' source.

* '''[[Creating a custom lexer for Code::Blocks editor]]'''
:How to add support for new syntax lighting schemes.

* '''[[Creating a patch to submit to BerliOS (Patch Tracker)]]'''
:Creating a diff file and then submitting it to the patch tracker.

* '''[[Unicode Standards]]'''
:Information about unicode standards and how unicode is handled in Code::Blocks' source code.

* '''[[Various development tips]]'''
:List of various development tips for Code::Blocks.

* '''[[Scripting Code::Blocks]]'''
:Information about scripting Code::Blocks with [http://www.squirrel-lang.org/ Squirrel].

== Plugin development ==

* [[Creating a simple "Hello World" plugin]]
* [[Creating a Plug-in which modifies CB's Menus]]
* [[Creating a plugin that actually does something]]

* [[Research on doing a Plug-in for embedded help in CB]]

== Scripting ==

Using scripting to extend Code::Blocks' functionality

* [[Wizard scripts|Creating a new project wizard]]

User documentation

2006-11-11T18:50:08Z

Artojon: move Scripting to Developer Documentation

[[Category:Code::Blocks Documentation]]
[[Category:User Documentation]]
__TOC__
Articles for Code::Blocks users.

'''[[Installing Code::Blocks]]'''

:How to install Code::Blocks (from binary or source)

'''[[Keyboard Shortcuts]]'''

:List of keyboard shortcuts that can be used in Code::Blocks

'''[[Command line arguments]]'''

:List of command-line arguments that can be used with Code::Blocks.

'''[[Personalities]]'''

:Customize the Code::Blocks user interface for different workflows.

'''[[Code::Blocks Plugins]]'''

:List of plugins that come with Code::Blocks.

'''[[The build process of Code::Blocks]]'''

:Information about how Code::Blocks actually builds your source code.

== Application development ==

* [[Builtin variables]]
* [[Recommended global variables]]
* [[Debugging with Code::Blocks]]

== Compilers ==

* [[Global compiler variables]]
* [[Precompiled headers]]
* [[Installing a supported compiler]]
* [[Installing Cygwin Compiler]]
* [[Installing Fortran Compiler]]
* [[Code::Blocks_and_Cross_Compilers|Using cross compilers]]
* [[Integrating Microsoft Visual Toolkit 2003 with Code::Blocks IDE]]
* [[Integrating Microsoft Visual C 6 with Code::Blocks IDE]]

== Third-party libraries ==

* [[Using SDL with Code::Blocks]]
* [[Using GLFW with Code::Blocks]]

== User interface development ==

* [[WxSmith Tutorial & Pointers|Creating a dialog for wxWidgets with wxSmith]]

The build process of Code::Blocks

2006-11-11T18:49:26Z

Artojon: removed extra category

[[Category:User Documentation]]

In this page, the build process is explained in detail. What goes on behind the scenes and "when" is covered. I hope it makes an interesting read :).

= Build order =
As you have probably guessed, Code::Blocks does not launch build commands at random but rather as a well thought out and prepared sequence. But first let's see what components are the subject of the build:

* '''Workspace''': contains one or more projects
* '''Project''': contains one or more build targets. It also contains the project's files.
* '''Build target''': project files are assigned to it, which are built as a group and generate one binary output. This output can either be an executable, a dynamic library or a static library. ''NOTE: there is one kind of build target that does not produce a binary output directly but rather just runs its pre/post build steps (which may generate a binary output externally).''

Let's break these subjects in sections and explain them in more detail.

== Workspace ==
The workspace is the top-level container item for organizing your projects. Since there can be only one workspace open at a time, there really is no build order issue for them. It's only one, so it's just built ;).

Use the menu "Build->Build workspace" to build a workspace (i.e. all the projects contained in it).

== Projects ==
Here, things start getting interesting :).

Projects build order is different depending if the user has set project dependencies or not. Please read on.

=== Without project dependencies ===
In this case, projects are built in the order of appearence, from top to bottom.
Most projects though (at least not the "hello world" ones), would want to setup project dependencies.

=== Using project dependencies ===
Project dependencies are a simple way to tell Code::Blocks that a given project "depends" on another (in the same workspace, always).

Thus imagine in your workspace you have a library project and an executable project which depends on the library. Then you could (and should) tell Code::Blocks about this dependency. To do this, you select "Project->Properties" and click the "Project's dependencies.." button.

''Please notice that the dependency information is saved within the workspace file, not the project file as it is a dependency between two projects within a workspace.''

[[Image:Project_deps.png|frame|Setting up project dependencies]]

It is very easy to use this dialog. Select the project you want to add a dependency and then put a checkmark on all projects that this project depends on. This will ensure that all the projects you checked will be built before the project that depends on them, ensuring a synchronized build.

'''Tip:''' You don't have to close this dialog and launch the other project's properties again to set their dependencies. You can set all projects dependencies from this same dialog. Just select a different project in the drop-down box :).

Some things to note:
* Dependencies are set directly or indirectly. If project A depends directly on project B and project B depends on project C, then project A indirectly depends on project C too.
* Code::Blocks is smart enough to watch out for circular dependencies and prohibit them. A circular dependency is caused when project A depends directly or indirectly on project B and project B depends directly or indirectly on project A.
* Dependencies take effect either if building the whole workspace or a single project. In this case, only the dependencies needed for the project you 're building will be built too.

== Build targets ==
Build targets build order depend on a couple of things.
# If the user has selected a specific build target in the compiler toolbar's drop-down box, then only this build target is built. If project dependencies are setup for the project containing this target, all projects it depends on will also build their target with the same name. If no such target exists, that project is skipped.
# If the virtual "All" target is selected, then all targets in the project (and all the projects it depends on) are built in order, top to bottom. There are a couple of exceptions to this:
#* A target is not built with "All" if the target option (in project properties "Targets" page) "Build this target with All" is not selected.
#* If no targets in the project have the above option selected, then no virtual "All" target appears in the list.

= Preprocessing phase =
Before the actual build process starts (i.e. the compiler/linker commands start executing), a preprocessing step runs which generates all required command-lines for the entire build process.
This step caches much of the information it generates, making subsequent builds faster in effect.

This step also runs any attached [[build scripts]].

= Actual commands execution =
This is the stage that the build process actually starts, from the user's point of view. The files start getting compiled and finally linked to generate the various binary outputs the build targets define.

In this step, the pre-build and post-build steps are also executed.

== Pre-build and post-build steps ==
These are commands that can be setup on project and/or target level. They are shell commands that e.g. copy files around or any other operation you can do with a usual OS system shell.

Here's a breakdown of the pre/post build steps execution order for an imaginary project with two targets (Debug/Release):

# Project pre-build steps
## Target "Debug" pre-build steps
## Target "Debug" compile files
## Target "Debug" link files and generate binary output
## Target "Debug" post-build steps (see notes below)
## Target "Release" pre-build steps
## Target "Release" compile files
## Target "Release" link files and generate binary output
## Target "Release" post-build steps (see notes below)
# Project post-build steps

I hope this is self-explaining :)

''NOTE: Pre-build steps are always ran. Post-build steps will run only if the project/target they 're attached to is not up-to-date (i.e. is going to be built). You can change this by selecting "Always execute, even if target is up to date" in the build options.''

Original article by MortenMacFly

[[User:Mandrav|Mandrav]] 04:42, 14 July 2006 (EDT)

Languages supported by Code::Blocks lexers

2006-11-11T18:43:49Z

Artojon: moved to "Developer Documentation"

[[Category:Developer Documentation]]
{| border="1" cellpadding="1" cellspacing="0" style="font-size: 85%; border: gray solid 1px; border-collapse: collapse; text-align: center; width: 50%; table-layout: fixed;"

|- style="background: #ececec;"
! style="width: 12em" | Language
! [https://www.codeblocks.org/ Code::Blocks]
! [http://www.scintilla.org/SciTE.html SciTE]
|-

|-
! style="text-align: left; background: #ececec;" | Ada
| {{no}}
| {{yes}}
|-

|-
! style="text-align: left; background: #ececec;" | AngelScript (using the C++ lexer)
| {{yes}}{{refun|CodeFolding}}
| {{no}}
|-

|-
! style="text-align: left; background: #ececec;" | ANS.1 MIB definition files
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | APDL
| {{no}}
| {{yes}}
|-

|-
! style="text-align: left; background: #ececec;" | Assembler (NASM, MASM)
| {{yes}}
| {{yes}}
|-

|-
! style="text-align: left; background: #ececec;" | Assembler (Hitachi, using the C++ lexer)
| {{yes}} (Why it uses the C++ lexer????)
| {{no}}
|-

|-
! style="text-align: left; background: #ececec;" | AutoIt
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Avenue
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Batch (MS-DOS)
| {{yes}}
| {{yes}}
|-

|-
! style="text-align: left; background: #ececec;" | Baan
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Bash
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | BlitzBasic
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Bullant
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | C/C++
| {{yes}}{{refun|CodeFolding}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | C# (using the C++ lexer)
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Clarion
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | conf (Apache)
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | CSound
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | CSS
| {{yes}}{{refun|CodeFolding}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | diff files
| {{yes}}{{refun|CodeFolding}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | E-Script
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Eiffel
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Erlang
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Flagship (Clipper / XBase)
| {{yes}}{{refun|CodeFolding}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Flash (ActionScript)
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Fortran
| {{yes}}{{refun|CodeFolding}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Forth
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Haskell
| {{no}}
| {{yes}}
|-

|-
! style="text-align: left; background: #ececec;" | HTML
| {{yes}}{{refun|CodeFolding}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | HTML with embedded JavaScript, VBScript, PHP and ASP
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | GameMonkey Script (using the C++ lexer)
| {{yes}}{{refun|CodeFolding}}
| {{no}}
|-

|-
! style="text-align: left; background: #ececec;" | Gui4Cli
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | IDL (both MSIDL and XPIDL)
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Java
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | JavaScript
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | LISP
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | LOT
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Lout
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Lua
| {{yes}}{{refun|CodeFolding}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Make
| {{yes}}
| {{yes}}
|-

|-
! style="text-align: left; background: #ececec;" | Matlab
| {{yes}}{{refun|CodeFolding}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Metapost
| {{no}}
| {{yes}}
|-

|-
! style="text-align: left; background: #ececec;" | MMIXAL
| {{no}}
| {{yes}}
|-

|-
! style="text-align: left; background: #ececec;" | MSSQL
| {{no}}
| {{yes}}
|-

|-
! style="text-align: left; background: #ececec;" | nnCron
| {{no}}
| {{yes}}
|-

|-
! style="text-align: left; background: #ececec;" | NSIS
| {{yes}}{{refun|CodeFolding}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | nVidia cg (using the C++ lexer)
| {{yes}}{{refun|CodeFolding}}
| {{no}}
|-

|-
! style="text-align: left; background: #ececec;" | Objective Caml
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Ogre Material script (using the C++ lexer)
| {{yes}}{{refun|CodeFolding}}
| {{no}}
|-

|-
! style="text-align: left; background: #ececec;" | OpenGL Shading Language (using the C++ lexer)
| {{yes}}{{refun|CodeFolding}}
| {{no}}
|-

|-
! style="text-align: left; background: #ececec;" | Octave
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Pascal/Delphi
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Perl
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | PostScript
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | POV-Ray
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | PowerBasic
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Properties
| {{yes}}{{refun|CodeFolding}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | PureBasic
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Python
| {{yes}}{{refun|CodeFolding}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Rebol
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Ruby
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Scheme
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | scriptol
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Specman E
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Spice
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Smalltalk
| {{no}}
| {{yes}}
|-

|-
! style="text-align: left; background: #ececec;" | SQL and PLSQL
| {{no}}
| {{yes}}
|-

|-
! style="text-align: left; background: #ececec;" | TADS3
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | TeX and LaTeX
| {{no}}
| {{yes}}
|-

|-
! style="text-align: left; background: #ececec;" | Tcl/Tk
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | VB and VBScript
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Verilog
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | VHDL
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | Windows resource (using the C++ lexer)
| {{yes}}
| {{no}}
|-
! style="text-align: left; background: #ececec;" | XML
| {{yes}}{{refun|CodeFolding}}
| {{yes}}{{refun|CodeFolding}}
|-

|-
! style="text-align: left; background: #ececec;" | YAML
| {{no}}
| {{yes}}{{refun|CodeFolding}}
|-

|}

*{{note|CodeFolding}} Supports code-folding.

Personalities

2006-11-11T18:41:57Z

Artojon: move to "User Documentation"

[[Category:User Documentation]]
In Code::Blocks context, '''personalities''' are different sets of settings each tailored for a different workflow.

== Creating a new personality ==

Let's assume that you want a more lightweight Code::Blocks to quickly work on testing single-source files. Most plugins are not needed for this kind of job so it would be wise to remove them from the loading process. You would also like the manager panes to be hidden by default.

To accomplish the above task, a new Code::Blocks personality should be created. Here is how:

# Find the shortcut to Code::Blocks on your desktop. If there isn't any, create one.
# Make a copy of this shortcut and rename it to "Code::Blocks Lite" (for example). You should now have two shortcuts to Code::Blocks on your desktop.
# Right-click on the "Code::Blocks Lite" shortcut and choose "Properties". In the "Target" box, append the following magic words: <code>--personality="Lite"</code>

:'''''Tip''''': ''if you want to see a list of all defined personalities and select which one to use, replace the above with the following'': <code>--personality=ask</code>

This will cause Code::Blocks to use the "Lite" personality when it starts-up. But because we haven't defined the "Lite" personality, Code::Blocks will create a new personality for us.

After you've done the above changes to the "Lite" shortcut and saved it, launch Code::Blocks.
Although you may see no changes, Code::Blocks will be operating under the personality "Lite". This means, that any personalities-aware configuration changes you make will be done on the "Lite" personality.

Next we make a light version of Code::Blocks by disabling plugins and hiding the manager panes:

# Go to "Plugins->Manage plugins" and disable (uncheck) all plugins except the Compiler.
# Now hide the "Manager" (Shift-F2) and "Messages" (F2) panes (in the "View" menu).
# Exit Code::Blocks.
# Launch Code::Blocks again, by clicking on the "Lite" shortcut. Everything should be as configured: no manager panes showing and just one plugin loaded.

To use Code::Blocks at full capacity again, use the shortcut that doesn't have the <code>--personality="Lite"</code> switch:

# Close Code::Blocks.
# Launch Code::Blocks by clicking on the standard shortcut (no "--personality" command-line option).

Roadmap

2006-11-11T17:44:59Z

Artojon: make it Developer Documentation instead

[[Category:Developer Documentation]]
[[Category:Roadmaps]]
====[[Roadmap for version 1.0]]====

====[[Roadmap for version 1.5]]====

Scripting commands

2006-11-11T17:44:23Z

Artojon: removed extra category

[[Category:Scripting Code::Blocks]]
Scripting is no good if all you can do is use the scripting language's builtin commands only. The host application (Code::Blocks) needs to expose parts of its internals to scripts, so scripts can use and control the host.

Code::Blocks has exposed a very large chunk of its SDK to scripts. This makes scripting in Code::Blocks nearly as powerful as native code (C++).

In this page all the exported constants, functions and classes are documented as a quick reference. For detailed documentation on each function/class, refer to the Code::Blocks SDK documentation.

''NOTE: please remember that [http://www.squirrel-lang.org Squirrel] is typeless. Data types mentioned below are only used for documentation purposes.''

== Global functions ==

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 0px solid gray"
!Return value
!Name
!Arguments
!Remarks
|-

|-
| void || Log || wxString || logs to debug log
|-

|-
| int || Message || wxString,wxString,int ||
|-

|-
| void || ShowMessage || wxString ||
|-

|-
| void || ShowWarning || wxString ||
|-

|-
| void || ShowError || wxString ||
|-

|-
| void || ShowInfo || wxString ||
|-

|-
| wxString || ReplaceMacros || wxString,bool ||
|-

|-
| ProjectManager* || GetProjectManager || ||
|-

|-
| EditorManager* || GetEditorManager || ||
|-

|-
| ConfigManager* || GetConfigManager || ||
|-

|-
| UserVariableManager* || GetUserVariableManager || ||
|-

|-
| CompilerFactory* || GetCompilerFactory || ||
|-

|-
| bool || IsNull || void* ||
|-

|-
| wxString || _T || const char* || basically this is the wxString constructor
|-

|}

== ConfigManager ==

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 0px solid gray"
!Return value
!Name
!Arguments
!Remarks
|-

|-
| int || Read || int,int ||
|-

|-
| bool || Read || bool,bool ||
|-

|-
| float || Read || float,float ||
|-

|-
| wxString || Read || wxString,wxString ||
|-

|-
| void || Write || int,int ||
|-

|-
| void || Write || bool,bool ||
|-

|-
| void || Write || float,float ||
|-

|-
| void || Write || wxString,wxString[,bool] ||
|-

|}

== ProjectManager ==

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 0px solid gray"
!Return value
!Name
!Arguments
!Remarks
|-

|-
| wxString || GetDefaultPath || ||
|-

|-
| void || SetDefaultPath || wxString ||
|-

|-
| cbProject* || GetActiveProject || ||
|-

|-
| void || SetProject || cbProject* ||
|-

|-
| bool || LoadWorkspace || wxString ||
|-

|-
| bool || SaveWorkspace || ||
|-

|-
| bool || SaveWorkspaceAs || wxString ||
|-

|-
| bool || CloseWorkspace || ||
|-

|-
| cbProject* || IsOpen || wxString ||
|-

|-
| cbProject* || LoadProject || wxString,bool ||
|-

|-
| bool || SaveProject || cbProject* ||
|-

|-
| bool || SaveProjectAs || cbProject* ||
|-

|-
| bool || SaveActiveProject || ||
|-

|-
| bool || SaveActiveProjectAs || ||
|-

|-
| bool || SaveAllProjects || ||
|-

|-
| bool || CloseProject || cbProject*,bool,bool ||
|-

|-
| bool || CloseActiveProject || bool ||
|-

|-
| bool || CloseAllProjects || bool ||
|-

|-
| cbProject* || NewProject || wxString ||
|-

|-
| int || AddFileToProject || wxString,cbProject*,int ||
|-

|-
| int || AskForBuildTargetIndex || cbProject* ||
|-

|-
| void || RebuildTree || ||
|-

|}

== EditorManager ==

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 0px solid gray"
!Return value
!Name
!Arguments
!Remarks
|-

|-
| void || Configure || ||
|-

|-
| cbEditor* || New || wxString ||
|-

|-
| cbEditor* || Open || wxString ||
|-

|-
| cbEditor* || IsBuiltinOpen || wxString ||
|-

|-
| cbEditor* || GetBuiltinEditor || wxString|int ||
|-

|-
| cbEditor* || GetBuiltinActiveEditor || ||
|-

|-
| EditorBase* || GetActiveEditor || ||
|-

|-
| void || ActivateNext || ||
|-

|-
| void || ActivatePrevious || ||
|-

|-
| bool || SwapActiveHeaderSource || ||
|-

|-
| bool || CloseActive || bool ||
|-

|-
| bool || Close || wxString|int,bool ||
|-

|-
| bool || CloseAll || bool ||
|-

|-
| bool || Save || wxString|int ||
|-

|-
| bool || SaveActive || ||
|-

|-
| bool || SaveAs || int ||
|-

|-
| bool || SaveActiveAs || ||
|-

|-
| bool || SaveAll || ||
|-

|-
| int || ShowFindDialog || bool,bool ||
|-

|}

== UserVariableManager ==

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 0px solid gray"
!Return value
!Name
!Arguments
!Remarks
|-

|-
| bool || Exists || wxString ||
|-

|}

== IO namespace ==

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 0px solid gray"
!Return value
!Name
!Arguments
!Remarks
|-

|-
| bool || DirectoryExists || wxString ||
|-

|-
| wxString || SelectDirectory || wxString,wxString,bool ||
|-

|-
| bool || FileExists || wxString ||
|-

|-
| wxString || SelectFile || wxString,wxString,wxString ||
|-

|}

== CompilerFactory ==

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 0px solid gray"
!Return value
!Name
!Arguments
!Remarks
|-

|-
| bool || IsValidCompilerID || wxString ||
|-

|-
| int || GetCompilerIndex || wxString ||
|-

|-
| wxString || GetDefaultCompilerID || ||
|-

|-
| bool || CompilerInheritsFrom || ||
|-

|}

== wxString ==

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 0px solid gray"
!Return value
!Name
!Arguments
!Remarks
|-

|-
| bool || operator+ || ||
|-

|-
| bool || operator< || ||
|-

|-
| bool || operator<= || ||
|-

|-
| bool || operator>= || ||
|-

|-
| bool || operator> || ||
|-

|-
| int || Find || wxString ||
|-

|-
| bool || Matches || wxString ||
|-

|-
| void || AddChar || char ||
|-

|-
| char || GetChar || int ||
|-

|-
| bool || IsEmpty || ||
|-

|-
| int || Length || ||
|-

|-
| int || length || || same as Length()
|-

|-
| int || len || || same as Length()
|-

|-
| int || size || || same as Length()
|-

|-
| wxString || Lower || ||
|-

|-
| wxString || LowerCase || || same as Lower()
|-

|-
| void || MakeLower || ||
|-

|-
| wxString || Upper || ||
|-

|-
| wxString || UpperCase || || same as Upper()
|-

|-
| void || MakeUpper || ||
|-

|-
| wxString || Mid || int,int ||
|-

|-
| void || Remove || int,int ||
|-

|-
| void || RemoveLast || ||
|-

|-
| int || Replace || wxString,wxString[,bool] ||
|-

|-
| wxString || Right || int ||
|-

|-
| wxString || AfterFirst || char ||
|-

|-
| wxString || AfterLast || char ||
|-

|-
| wxString || BeforeFirst || char ||
|-

|-
| wxString || BeforeLast || char ||
|-
|}

== wxArrayString ==

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 0px solid gray"
!Return value
!Name
!Arguments
!Remarks
|-

|-
| void || Add || wxString ||
|-

|-
| void || Clear || ||
|-

|-
| int || GetCount || ||
|-

|-
| wxString || Item || int ||
|-

|}

== ProjectFile ==

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 0px solid gray"
!Return value
!Name
!Arguments
!Remarks
|-

|-
| void || AddBuildTarget || wxString ||
|-

|-
| void || RenameBuildTarget || wxString,wxString ||
|-

|-
| void || RemoveBuildTarget || wxString ||
|-

|-
| wxString || GetBaseName || ||
|-

|-
| wxString || GetObjName || ||
|-

|-
| void || SetObjName || wxString ||
|-

|-
| cbProject* || GetParentProject || ||
|-

|-
| wxString || relativeFilename || || (variable)
|-

|-
| wxString || relativeToCommonTopLevelPath || || (variable)
|-

|-
| bool || compile || || (variable)
|-

|-
| bool || link || || (variable)
|-

|-
| int || weight || || (variable)
|-

|-
| wxString || compilerVar || || (variable)
|-

|}

== CompileOptionsBase ==

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 0px solid gray"
!Return value
!Name
!Arguments
!Remarks
|-

|-
| void || SetLinkerOptions || wxArrayString ||
|-

|-
| void || SetLinkLibs || wxArrayString ||
|-

|-
| void || SetCompilerOptions || wxArrayString ||
|-

|-
| void || SetIncludeDirs || wxArrayString ||
|-

|-
| void || SetResourceIncludeDirs || wxArrayString ||
|-

|-
| void || SetLibDirs || wxArrayString ||
|-

|-
| void || SetCommandsBeforeBuild || wxArrayString ||
|-

|-
| void || SetCommandsAfterBuild || wxArrayString ||
|-

|-
| wxArrayString || GetLinkerOptions || ||
|-

|-
| wxArrayString || GetLinkLibs || ||
|-

|-
| wxArrayString || GetCompilerOptions || ||
|-

|-
| wxArrayString || GetIncludeDirs || ||
|-

|-
| wxArrayString || GetResourceIncludeDirs || ||
|-

|-
| wxArrayString || GetLibDirs || ||
|-

|-
| wxArrayString || GetCommandsBeforeBuild || ||
|-

|-
| wxArrayString || GetCommandsAfterBuild || ||
|-

|-
| bool || GetModified || ||
|-

|-
| void || SetModified || bool ||
|-

|-
| void || AddLinkerOption || wxString ||
|-

|-
| void || AddLinkLib || wxString ||
|-

|-
| void || AddCompilerOption || wxString ||
|-

|-
| void || AddIncludeDir || wxString ||
|-

|-
| void || AddResourceIncludeDir || wxString ||
|-

|-
| void || AddLibDir || wxString ||
|-

|-
| void || AddCommandsBeforeBuild || wxString ||
|-

|-
| void || AddCommandsAfterBuild || wxString ||
|-

|-
| void || RemoveLinkerOption || wxString ||
|-

|-
| void || RemoveLinkLib || wxString ||
|-

|-
| void || RemoveCompilerOption || wxString ||
|-

|-
| void || RemoveIncludeDir || wxString ||
|-

|-
| void || RemoveResourceIncludeDir || wxString ||
|-

|-
| void || RemoveLibDir || wxString ||
|-

|-
| void || RemoveCommandsBeforeBuild || wxString ||
|-

|-
| void || RemoveCommandsAfterBuild || wxString ||
|-

|-
| bool || GetAlwaysRunPostBuildSteps || ||
|-

|-
| void || SetAlwaysRunPostBuildSteps || bool ||
|-

|-
| bool || SetVar || wxString,wxString,bool ||
|-

|-
| wxString || GetVar || wxString ||
|-

|-
| bool || UnsetVar || wxString ||
|-

|-
| void || UnsetAllVars || ||
|-

|}

== CompileTargetBase ==
Extends CompileOptionsBase.

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 0px solid gray"
!Return value
!Name
!Arguments
!Remarks
|-

|-
| wxString || GetFilename || ||
|-

|-
| wxString || GetTitle || ||
|-

|-
| void || SetTitle || wxString ||
|-

|-
| void || SetOutputFilename || wxString ||
|-

|-
| void || SetWorkingDir || wxString ||
|-

|-
| void || SetObjectOutput || wxString ||
|-

|-
| void || SetDepsOutput || wxString ||
|-

|-
| OptionsRelation || GetOptionRelation || OptionsRelationType ||
|-

|-
| void || SetOptionRelation || OptionsRelationType,OptionsRelation ||
|-

|-
| wxString || GetWorkingDir || ||
|-

|-
| wxString || GetObjectOutput || ||
|-

|-
| wxString || GetDepsOutput || ||
|-

|-
| wxString || GetOutputFilename || ||
|-

|-
| wxString || SuggestOutputFilename || ||
|-

|-
| wxString || GetExecutableFilename || ||
|-

|-
| wxString || GetDynamicLibFilename || ||
|-

|-
| wxString || GetDynamicLibDefFilename || ||
|-

|-
| wxString || GetStaticLibFilename || ||
|-

|-
| wxString || GetBasePath || ||
|-

|-
| void || SetTargetType || TargetType ||
|-

|-
| TargetType || GetTargetType || ||
|-

|-
| wxString || GetExecutionParameters || ||
|-

|-
| void || SetExecutionParameters || wxString ||
|-

|-
| wxString || GetHostApplication || ||
|-

|-
| void || SetHostApplication || wxString ||
|-

|-
| void || SetCompilerID || wxString ||
|-

|-
| wxString || GetCompilerID || ||
|-

|}

== ProjectBuildTarget ==
Extends CompileTargetBase.

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 0px solid gray"
!Return value
!Name
!Arguments
!Remarks
|-

|-
| cbProject* || GetParentProject || ||
|-

|-
| wxString || GetFullTitle || ||
|-

|-
| wxString || GetExternalDeps || ||
|-

|-
| void || SetExternalDeps || wxString ||
|-

|-
| void || SetAdditionalOutputFiles || wxString ||
|-

|-
| wxString || GetAdditionalOutputFiles || ||
|-

|-
| bool || GetIncludeInTargetAll || ||
|-

|-
| void || SetIncludeInTargetAll || bool ||
|-

|-
| bool || GetCreateDefFile || ||
|-

|-
| void || SetCreateDefFile || bool ||
|-

|-
| bool || GetCreateStaticLib || ||
|-

|-
| void || SetCreateStaticLib || bool ||
|-

|-
| bool || GetUseConsoleRunner || ||
|-

|-
| void || SetUseConsoleRunner || bool ||
|-

|}

== cbProject ==
Extends CompileTargetBase.

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 0px solid gray"
!Return value
!Name
!Arguments
!Remarks
|-

|-
| bool || GetModified || ||
|-

|-
| void || SetModified || bool ||
|-

|-
| wxString || GetMakefile || ||
|-

|-
| void || SetMakefile || wxString ||
|-

|-
| bool || IsMakefileCustom || ||
|-

|-
| void || SetMakefileCustom || bool ||
|-

|-
| bool || CloseAllFiles || bool ||
|-

|-
| bool || SaveAllFiles || ||
|-

|-
| bool || Save || ||
|-

|-
| bool || SaveLayout || ||
|-

|-
| bool || LoadLayout || ||
|-

|-
| bool || ShowOptions || ||
|-

|-
| wxString || GetCommonTopLevelPath || ||
|-

|-
| int || GetFilesCount || ||
|-

|-
| ProjectFile* || GetFile || int ||
|-

|-
| ProjectFile* || GetFileByFilename || wxString,bool,bool ||
|-

|-
| bool || RemoveFile || int ||
|-

|-
| ProjectFile* || AddFile || wxString|int,wxString,bool,bool,int ||
|-

|-
| int || GetBuildTargetsCount || ||
|-

|-
| ProjectBuildTarget* || GetBuildTarget || wxString|int ||
|-

|-
| ProjectBuildTarget* || AddBuildTarget || wxString ||
|-

|-
| bool || RenameBuildTarget || wxString|int,wxString ||
|-

|-
| ProjectBuildTarget* || DuplicateBuildTarget || wxString|int,wxString ||
|-

|-
| bool || RemoveBuildTarget || wxString|int ||
|-

|-
| bool || ExportTargetAsProject || wxString|int ||
|-

|-
| void || SetActiveBuildTarget || int ||
|-

|-
| int || GetActiveBuildTarget || ||
|-

|-
| int || SelectTarget || int,bool ||
|-

|-
| ProjectBuildTarget* || GetCurrentlyCompilingTarget || ||
|-

|-
| void || SetCurrentlyCompilingTarget || ProjectBuildTarget* ||
|-

|-
| PCHMode || GetModeForPCH || ||
|-

|-
| void || SetModeForPCH || PCHMode ||
|-

|}

== EditorBase ==

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 0px solid gray"
!Return value
!Name
!Arguments
!Remarks
|-

|-
| wxString || GetFilename || ||
|-

|-
| void || SetFilename || wxString ||
|-

|-
| wxString || GetShortName || ||
|-

|-
| bool || GetModified || ||
|-

|-
| void || SetModified || bool ||
|-

|-
| wxString || GetTitle || ||
|-

|-
| void || SetTitle || wxString ||
|-

|-
| void || Activate || ||
|-

|-
| bool || Close || ||
|-

|-
| bool || Save || ||
|-

|-
| bool || IsBuiltinEditor || ||
|-

|-
| bool || ThereAreOthers || ||
|-

|-
| void || GotoLine || int,bool ||
|-

|-
| void || ToggleBreakpoint || int,bool ||
|-

|-
| bool || HasBreakpoint || int ||
|-

|-
| void || GotoNextBreakpoint || ||
|-

|-
| void || GotoPreviousBreakpoint || ||
|-

|-
| void || ToggleBookmark || int,bool ||
|-

|-
| bool || HasBookmark || int ||
|-

|-
| void || GotoNextBookmark || ||
|-

|-
| void || GotoPreviousBookmark || ||
|-

|-
| void || Undo || ||
|-

|-
| void || Redo || ||
|-

|-
| void || Cut || ||
|-

|-
| void || Copy || ||
|-

|-
| void || Paste || ||
|-

|-
| bool || CanUndo || ||
|-

|-
| bool || CanRedo || ||
|-

|-
| bool || CanPaste || ||
|-

|-
| bool || HasSelection || ||
|-

|}

== cbEditor ==
Extends EditorBase.

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 0px solid gray"
!Return value
!Name
!Arguments
!Remarks
|-

|-
| void || SetEditorTitle || wxString ||
|-

|-
| ProjectFile* || GetProjectFile || ||
|-

|-
| bool || SaveAs || ||
|-

|-
| void || FoldAll || ||
|-

|-
| void || UnfoldAll || ||
|-

|-
| void || ToggleAllFolds || ||
|-

|-
| void || FoldBlockFromLine || int ||
|-

|-
| void || UnfoldBlockFromLine || int ||
|-

|-
| void || ToggleFoldBlockFromLine || int ||
|-

|-
| int || GetLineIndentInSpaces || int ||
|-

|-
| wxString || GetLineIndentString || int ||
|-

|-
| void || Touch || ||
|-

|-
| bool || Reload || bool ||
|-

|-
| void || Print || bool,PrintColourMode,bool ||
|-

|-
| void || AutoComplete || ||
|-

|-
| bool || AddBreakpoint || int,bool ||
|-

|-
| bool || RemoveBreakpoint || int,bool ||
|-

|-
| void || SetText || wxString || this is not present in cbEditor; included to help scripts edit text
|-

|-
| wxString || GetText || || this is not present in cbEditor; included to help scripts edit text
|-

|}

== Constants ==

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"

|- style="background: #ececec; border: 0px solid gray"
!Constant
!Type
!Remarks
|-

|-
| PLATFORM || int || this defines the platform Code::Blocks is currently running on. It is equal to only one of the following PLATFORM_* constants
|-

|-
| PLATFORM_MSW || int || All Windows platforms
|-

|-
| PLATFORM_GTK || int || All GTK platforms (Linux, BSD, Solaris, Darwin, etc.)
|-

|-
| PLATFORM_MAC || int || All Mac platforms
|-

|-
| PLATFORM_OS2 || int || OS/2 platform
|-

|-
| PLATFORM_X11 || int || All X11 platforms
|-

|-
| PLATFORM_UNKNOWN || int || Unknown platform. Please inform us if PLATFORM == PLATFORM_UNKNOWN so we can make this platform known too ;)
|-

|-
| colspan="3" align="center" style="background: #f8f8f8;" | '''Message dialog flags'''
|-

|-
| wxOK || int || Flag for Message() 's third argument (flags).
|-

|-
| wxYES_NO || int || -"-
|-

|-
| wxCANCEL || int || -"-
|-

|-
| wxICON_QUESTION || int || -"-
|-

|-
| wxICON_INFORMATION || int || -"-
|-

|-
| wxICON_WARNING || int || -"-
|-

|-
| wxICON_ERROR || int || -"-
|-

|-
| colspan="3" align="center" style="background: #f8f8f8;" | '''Message dialog return values'''
|-

|-
| wxID_OK || int ||
|-

|-
| wxID_YES || int ||
|-

|-
| wxID_NO || int ||
|-

|-
| wxID_CANCEL || int ||
|-

|-
| colspan="3" align="center" style="background: #f8f8f8;" | '''enum OptionsRelationType'''
|-

|-
| ortCompilerOptions || enum ||
|-

|-
| ortLinkerOptions || enum ||
|-

|-
| ortIncludeDirs || enum ||
|-

|-
| ortLibDirs || enum ||
|-

|-
| ortResDirs || enum ||
|-

|-
| colspan="3" align="center" style="background: #f8f8f8;" | '''enum OptionsRelation'''
|-

|-
| orUseParentOptionsOnly || enum ||
|-

|-
| orUseTargetOptionsOnly || enum ||
|-

|-
| orPrependToParentOptions || enum ||
|-

|-
| orAppendToParentOptions || enum ||
|-

|-
| colspan="3" align="center" style="background: #f8f8f8;" | '''enum TargetType'''
|-

|-
| ttExecutable || enum ||
|-

|-
| ttConsoleOnly || enum ||
|-

|-
| ttStaticLib || enum ||
|-

|-
| ttDynamicLib || enum ||
|-

|-
| ttCommandsOnly || enum ||
|-

|-
| colspan="3" align="center" style="background: #f8f8f8;" | '''enum MakeCommand'''
|-

|-
| mcClean || enum ||
|-

|-
| mcDistClean || enum ||
|-

|-
| mcBuild || enum ||
|-

|-
| mcCompileFile || enum ||
|-

|-
| colspan="3" align="center" style="background: #f8f8f8;" | '''enum PCHMode'''
|-

|-
| pchSourceDir || enum ||
|-

|-
| pchObjectDir || enum ||
|-

|-
| pchSourceFile || enum ||
|-

|-
| colspan="3" align="center" style="background: #f8f8f8;" | '''enum PrintScope'''
|-

|-
| psSelection || enum ||
|-

|-
| psActiveEditor || enum ||
|-

|-
| psAllOpenEditors || enum ||
|-

|-
| colspan="3" align="center" style="background: #f8f8f8;" | '''enum PrintColourMode'''
|-

|-
| pcmBlackAndWhite || enum ||
|-

|-
| pcmColourOnWhite || enum ||
|-

|-
| pcmInvertColours || enum ||
|-

|-
| pcmAsIs || enum ||
|-

|-
| colspan="3" align="center" style="background: #f8f8f8;" | '''enum TemplateOutputType'''
|-

|-
| wizProject || enum || TemplateOutputType::totProject
|-

|-
| wizTarget || enum || TemplateOutputType::totTarget
|-

|-
| wizFiles || enum || TemplateOutputType::totFiles
|-

|-
| wizCustom || enum || TemplateOutputType::totCustom
|-

|-
| colspan="3" align="center" style="background: #f8f8f8;" | '''Other constants'''
|-

|-
| wxFILE_SEP_PATH || wxString || Path separator. "\" for windows, "/" for all other platforms
|-

|-
| colspan="3" align="center" style="background: #f8f8f8;" | '''File extensions (e.g. "cbp")'''
|-

|-
| EXT_WORKSPACE || wxString ||
|-

|-
| EXT_CODEBLOCKS || wxString ||
|-

|-
| EXT_DEVCPP || wxString ||
|-

|-
| EXT_MSVC6 || wxString ||
|-

|-
| EXT_MSVC6_WORKSPACE || wxString ||
|-

|-
| EXT_MSVC7 || wxString ||
|-

|-
| EXT_MSVC7_WORKSPACE || wxString ||
|-

|-
| EXT_D || wxString ||
|-

|-
| EXT_F || wxString ||
|-

|-
| EXT_F77 || wxString ||
|-

|-
| EXT_F95 || wxString ||
|-

|-
| EXT_CPP || wxString ||
|-

|-
| EXT_C || wxString ||
|-

|-
| EXT_CC || wxString ||
|-

|-
| EXT_CXX || wxString ||
|-

|-
| EXT_HPP || wxString ||
|-

|-
| EXT_H || wxString ||
|-

|-
| EXT_HH || wxString ||
|-

|-
| EXT_HXX || wxString ||
|-

|-
| EXT_OBJECT || wxString ||
|-

|-
| EXT_XRCRESOURCE || wxString ||
|-

|-
| EXT_STATICLIB || wxString ||
|-

|-
| EXT_DYNAMICLIB || wxString ||
|-

|-
| EXT_EXECUTABLE || wxString ||
|-

|-
| EXT_RESOURCE || wxString ||
|-

|-
| EXT_RESOURCEBIN || wxString ||
|-

|-
| colspan="3" align="center" style="background: #f8f8f8;" | '''File extensions with leading dot (e.g. ".cbp")'''
|-

|-
| DOT_EXT_WORKSPACE || wxString ||
|-

|-
| DOT_EXT_CODEBLOCKS || wxString ||
|-

|-
| DOT_EXT_DEVCPP || wxString ||
|-

|-
| DOT_EXT_MSVC6 || wxString ||
|-

|-
| DOT_EXT_MSVC6_WORKSPACE || wxString ||
|-

|-
| DOT_EXT_MSVC7 || wxString ||
|-

|-
| DOT_EXT_MSVC7_WORKSPACE || wxString ||
|-

|-
| DOT_EXT_D || wxString ||
|-

|-
| DOT_EXT_F || wxString ||
|-

|-
| DOT_EXT_F77 || wxString ||
|-

|-
| DOT_EXT_F95 || wxString ||
|-

|-
| DOT_EXT_CPP || wxString ||
|-

|-
| DOT_EXT_C || wxString ||
|-

|-
| DOT_EXT_CC || wxString ||
|-

|-
| DOT_EXT_CXX || wxString ||
|-

|-
| DOT_EXT_HPP || wxString ||
|-

|-
| DOT_EXT_H || wxString ||
|-

|-
| DOT_EXT_HH || wxString ||
|-

|-
| DOT_EXT_HXX || wxString ||
|-

|-
| DOT_EXT_OBJECT || wxString ||
|-

|-
| DOT_EXT_XRCRESOURCE || wxString ||
|-

|-
| DOT_EXT_STATICLIB || wxString ||
|-

|-
| DOT_EXT_DYNAMICLIB || wxString ||
|-

|-
| DOT_EXT_EXECUTABLE || wxString ||
|-

|-
| DOT_EXT_RESOURCE || wxString ||
|-

|-
| DOT_EXT_RESOURCEBIN || wxString ||
|-

|}

== See also ==

* [[Scripting Code::Blocks|Scripting index]]

Wizard scripts

2006-11-11T17:42:57Z

Artojon: removed extra category

[[Category:Scripting Code::Blocks]]
When you click "File->New", you 're presented with wizards to create various new things. These are:

* New project
* New build target inside the active project
* New file(s)
* New anything (custom)
* User template

[[Image:New_wiz.png|"New..." dialog]]

All the above functionality (except user templates) is provided by wizard scripts. In this section, I 'm gonna try to explain everything about wizard scripts.

Before starting out creating your own wizard scripts or editing existing ones, these are "must read":

* [[Wizard Scripting Commands]]
* [[Wizard Page Events]]

== Where are they located? ==
Wizard scripts are located under the Code::Blocks' data folder.
The base wizards folder is <tt>[Code::Blocks install dir]/share/codeblocks/templates/wizards</tt>.

Scripts are arranged in subfolders (one for each wizard) inside the above folder.
To make this clear, the structure of this folder is displayed below with the "console" wizard expanded to see all its files:

Base folder
console
c
main.c
cpp
main.cpp
logo.png
wizard.png
wizard.script
fltk
...
...
empty
...
...
common_functions.script
config.script

== What files do I need to create a valid wizard? ==
There are three files that are absolutely needed for your wizard to be registered correctly:
* '''logo.png''' - The wizard's icon. This will be displayed in the "New..." dialog.
* '''wizard.png''' - The wizard's bitmap. This bitmap is displayed on the left side in the wizard dialog.
* '''wizard.script''' - The wizard's script. You didn't think you could have a scripted wizard without a script, did you? ;)

== How do I edit an existing wizard? ==
That's easy: edit its script :). This can be done easily from within Code::Blocks. Just right-click on the wizard's icon in the "New..." dialog. The same context menu contains an option to edit the global configuration script (''config.script'').

[[Image:Edit_wiz_script.png|Wizard scripts context menu]]

Note that no restart is needed if you edit a script. Just save it and launch the wizard again :).

Code::Blocks needs to be restarted only when editing the global configuration script. An informational message is displayed in this case so you don't wonder why your changes are not taking any effect ;).

== How do I create a new wizard? ==
First thing you should do is read about [[Wizard Scripting Commands]] and use it as a reference on what commands are accepted and what their syntax is.

== How do I register my new wizard? ==
Wizard scripts are registered with Code::Blocks by adding a registration line in the global wizards configuration script (config.script).

Let's look at the registration of an existing wizard:

// config.script
function RegisterWizards()
{

RegisterWizard(wizProject, _T("empty"), _T("Empty project"), _T("Console"));

// more wizards following
...
...
}

The arguments to the RegisterWizard() function are as follows:

# The type of output for this wizard. Can be one of the following, self-explaining types:
#* wizProject
#* wizTarget
#* wizFiles
#* wizCustom
# The subfolder where this wizard's files are located
# The wizard's title, as will appear in the "New..." dialog
# The wizard's category. Free-form text. If your wizard fits one of the existing categories, please use it.

After you add the new wizard in ''config.script'', you must restart Code::Blocks to re-initialize all the registered wizards.

[[User:Mandrav|Mandrav]] 07:51, 9 July 2006 (EDT)

Wizard Scripting Commands

2006-11-11T17:42:26Z

Artojon: removed extra category

[[Category:Scripting Code::Blocks]]
In this page, all the wizards-related script commands are listed and explained.

Before we start, remember that in every wizard script there is a global variable defined named ''Wizard''. This is the object that all the following commands are known under.

= Adding wizard pages =
The script writer creates a wizard by adding various pre-defined and/or custom pages to the wizard object. The order the pages are added define the order in which they will appear (almost).

The script has the chance to interfere with the wizards operation any time the user presses "Next" or "Back" on the wizard dialog. For more on this, please read [[Wizard Page Events]].

''NOTE: The following commands only make sense inside the BeginWizard() script function.''

{{Function_Description_2args|1=
== AddInfoPage(pageId,intro_msg) ==

Add an informational page. It contains an informational text. It also contains a checkbox labelled "Skip".

Usually used for the first page to be displayed by the wizard and it explains in a few words what this wizard will do.

[[Image:Intro_panel.png]]
|3=pageId
|4=wxString
|5=The page's ID.
|6=info_msg
|7=wxString
|8=The info text
}}

{{Function_Description_1args|1=
== AddFilePathPage(showHeaderGuard) ==

Add a page that allows for the selection of a file. This file might not exist. Usually used by wizards of type ''wizFiles'' for the selection of the output files.

It also contains a ''header guard'' text box which can be visible or not. Usually used when the file in question is a C/C++ header, in which case you might want to allow the user to customize the ''header guard'' word. Note that if this is visible it is also auto-updated to match the selected filename. The auto-update takes the filename part (no path), capitalizes it and replaces any non-character or non-digit to an underscore.

[[Image:File_path_panel.png]]
|3=showHeaderGuard
|4=bool
|5=If true, a ''header guard'' text box will be visible
}}

{{Function_Description_1args|1=
== AddProjectPathPage() ==

Add a page that allows the user to customize the new project. Usually used by wizards of type ''wizProject''.

This page contains text boxes to set the project title, filename and base directory.

[[Image:Project_path_panel.png]]
}}

{{Function_Description_4args|1=
== AddCompilerPage(compilerID, validCompilerIDs, allowCompilerChange, allowConfigChange) ==

Perhaps the most used pre-defined wizard page. It contains a compiler selection list and a couple of well-known pre-defined build targets: Debug and Release.

The compilers' list can contain all supported compilers or a script-defined list. It can also be selected whether compiler selection will be enabled or not.

Finally, the build targets related settings can be either visible or not. If they 're visible, they allow the user to customize per-target the target's name, working directory and objects output (intermediate) directory.

[[Image:Compiler_panel.png]]
| 3=compilerID | 4=wxString | 5=The preselected compiler ID for the list. If this string is empty, the globally default compiler will be selected.
| 6=validCompilerIDs | 7=wxString | 8=A semicolon separated list of valid compiler IDs to include in the list. If you want all available compilers to be listed, use <code>_T("*")</code>. If you want only GCC-based or MSVC-based compilers to appear in the list, use <code>_T("gcc*;msv*")</code>.
| 9=allowCompilerChange | 10=bool | 11=If true, the user will be able to change the compiler selection. If false, the selection will be read-only.
| 12=allowConfigChange | 13=bool | 14=If true, the settings for the two pre-defined build targets (Debug/Release) will be shown and available for the user to customize. If false, they will not be visible.
}}

{{Function_Description_6args|1=
== AddBuildTargetPage(targetName, isDebug, showCompiler, compilerID, validCompilerIDs, allowCompilerChange) ==

Adds a page for creating a new build target. This page allows the user to enter a name for the new build target, set its working directory, set its objects output (intermediate) directory and, optionally, a compiler selection list.

It also contains a checkbox to denote whether this target should have debugging symbols enabled or not.

The compilers' list can contain all supported compilers or a script-defined list. It can also be selected whether compiler selection will be enabled or not.

[[Image:Build_target_panel.png]]
| 3=targetName | 4=wxString | 5=The new target's name.
| 6=isDebug | 7=bool | 8=If true, the "Enable debugging symbols" check box will be checked.
| 9=showCompiler | 10=bool | 11=If true, the compiler selection list will be visible.
| 12=compilerID | 13=wxString | 14=The preselected compiler ID for the list. If this string is empty, the globally default compiler will be selected.
| 15=validCompilerIDs | 16=wxString | 17=A semicolon separated list of valid compiler IDs to include in the list. If you want all available compilers to be listed, use <code>_T("*")</code>. If you want only GCC-based or MSVC-based compilers to appear in the list, use <code>_T("gcc*;msv*")</code>.
| 18=allowCompilerChange | 19=bool | 20=If true, the user will be able to change the compiler selection. If false, the selection will be read-only.
}}

{{Function_Description_4args|1=
== AddGenericSingleChoiceListPage(pageId, descr, choices, defChoice) ==
Adds a page that contains a script-defined list and the user can select one single value from it.

[[Image:Generic_single_choice_list.png]]
| 3=pageId | 4=wxString | 5=The page's ID.
| 6=descr | 7=wxString | 8=The description displayed at the top of the page.
| 9=choices | 10=wxString | 11=Semicolon separated list of the available selections.
| 12=defChoice | 13=int | 14=The pre-selected choice. This is used only the first time this page is displayed. The user's selection is stored in the Code::Blocks configuration file and remembered for subsequent uses of this page.
}}

{{Function_Description_4args|1=
== AddGenericSelectPathPage(pageId, descr, label, defValue) ==
Adds a page that allows the user to select a folder from the filesystem.

[[Image:Generic_select_path.png]]
| 3=pageId | 4=wxString | 5=The page's ID.
| 6=descr | 7=wxString | 8=The description displayed at the top of the page.
| 9=label | 10=wxString | 11=The label above the text box (e.g. "Location of Foo:").
| 12=defValue | 13=wxString | 14=The pre-selected path. This is used only the first time this page is displayed. The user's selection is stored in the Code::Blocks configuration file and remembered for subsequent uses of this page.
}}

{{Function_Description_1args|1=
== AddPage(pageId) ==

Adds a custom page from XRC resource.

The wizard allows the script to add custom pages from XRC. Each such page must actually be a wxPanel inside the XRC. This wxPanel's name is then used as the ''pageID'' parameter.
|3=pageId
|4=wxString
|5=The page's ID. This must match the wxPanel's name in the XRC resource.
}}

= Operating on GUI controls =
The wizard allows scripts to operate on the controls currently visible (i.e. on the current page the user is viewing).
By "operate on" I mean get and set their values.
This is especially useful for custom XRC pages (else what would they be good for?) and a couple of the pre-defined pages.

In this section, the script commands that allows the script to operate on page controls are explained by control type.

== Text controls (wxTextCtrl) ==

{{Function_Description_2args|1=
=== SetTextControlValue(control_name, value) ===
Sets the value of the text control identified by <code>control_name</code>.
|3=control_name
|4=wxString
|5=The control's name
|6=value
|7=wxString
|8=The new value
}}

{{Function_Description_1args|1=
=== GetTextControlValue(control_name) ===
Gets the value of the text control identified by <code>control_name</code>.
|2=The control's current value (wxString).
|3=control_name
|4=wxString
|5=The control's name
}}

== Checkbox controls (wxCheckBox) ==

{{Function_Description_2args|1=
=== CheckCheckbox(control_name, value) ===
Checks or unchecks the checkbox identified by <code>control_name</code>.
|3=control_name
|4=wxString
|5=The control's name
|6=value
|7=bool
|8=Check if true, uncheck if false
}}

{{Function_Description_1args|1=
=== IsCheckboxChecked(control_name) ===
Gets the check-state of the checkbox identified by <code>control_name</code>.
|2=The control's current check-state (bool).
|3=control_name
|4=wxString
|5=The control's name
}}

== Combobox controls (wxComboBox) ==

{{Function_Description_2args|1=
=== SetComboboxSelection(control_name, value) ===
Sets the selected item in the combobox identified by <code>control_name</code>.
|3=control_name
|4=wxString
|5=The control's name
|6=value
|7=int
|8=The item's index. Use -1 for no selection
}}

{{Function_Description_1args|1=
=== GetComboboxSelection(control_name) ===
Gets the selected item in the combobox identified by <code>control_name</code>.
|2=The control's currently selected index (int).
|3=control_name
|4=wxString
|5=The control's name
}}

{{Function_Description_1args|1=
=== GetComboboxStringSelection(control_name) ===
Gets the selected item's string in the combobox identified by <code>control_name</code>.
|2=The control's currently selected item's string (wxString).
|3=control_name
|4=wxString
|5=The control's name
}}

{{Function_Description_1args|1=
=== GetCompilerFromCombobox(control_name) ===
Assuming you have used FillComboboxWithCompilers() (below) to fill the combobox, this returns the selected compiler's ID.
|2=The control's currently selected item's string (wxString).
|3=control_name
|4=wxString
|5=The control's name
}}

{{Function_Description_1args|1=
=== FillComboboxWithCompilers(control_name) ===
Fills the combobox with a list of compilers.
|3=control_name
|4=wxString
|5=The control's name
}}

== Radiobox controls (wxRadioBox) ==

{{Function_Description_2args|1=
=== SetRadioboxSelection(control_name, value) ===
Sets the selected item in the radiobox identified by <code>control_name</code>.
|3=control_name
|4=wxString
|5=The control's name
|6=value
|7=int
|8=The item's index. Use -1 for no selection
}}

{{Function_Description_1args|1=
=== GetRadioboxSelection(control_name) ===
Gets the selected item in the radiobox identified by <code>control_name</code>.
|2=The control's currently selected index (int).
|3=control_name
|4=wxString
|5=The control's name
}}

== Listbox controls (wxListBox) ==

{{Function_Description_2args|1=
=== SetListboxSelection(control_name, value) ===
Sets the selected item in the listbox identified by <code>control_name</code>.
|3=control_name
|4=wxString
|5=The control's name
|6=value
|7=int
|8=The item's index. Use -1 for no selection
}}

{{Function_Description_1args|1=
=== GetListboxSelection(control_name) ===
Gets the selected item in the listbox identified by <code>control_name</code>.
|2=The control's currently selected index (int).
|3=control_name
|4=wxString
|5=The control's name
}}

== All controls (common functions) ==

{{Function_Description_2args|1=
=== EnableWindow(control_name, value) ===
Enables/disables the window (control) identified by <code>control_name</code>.
|3=control_name
|4=wxString
|5=The window's (control) name
|6=value
|7=bool
|8=Enable if true, disable if false
}}

(to be continued)

[[User:Mandrav|Mandrav]] 11:28, 9 July 2006 (EDT)

Wizard Page Events

2006-11-11T17:41:52Z

Artojon: removed extra category

[[Category:Scripting Code::Blocks]]
A script can handle various wizard events while the wizard is running. This page explains these events (and their uses) in detail.

== Page IDs ==
Every wizard page (pre-defined or custom) has a unique page ID. This ID is a wxString that identifies the page in scripts.

These are the valid pre-defined page IDs:

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 0px solid gray"
!Page || ID
|-
|Intro || "IntroPage"
|-
|File selection|| "FilePathPage"
|-
|Project settings|| "ProjectPathPage"
|-
|Compiler || "CompilerPage"
|-
|Build target || "BuildTargetPage"
|-
|Generic path ||
|-
|Generic single choice list ||
|}

You 'll notice that the two last pre-defined pages don't have an ID. This is because you can have more than one of them inside the same wizard and so the IDs wouldn't be unique anymore.

For these two pages, the ID is the first argument passed to their creation calls.
See [[Wizard Scripting Commands#AddGenericSelectPathPage(pageId, descr, label, defValue)|AddGenericSelectPathPage]] and [[Wizard Scripting Commands#AddGenericSingleChoiceListPage(pageId, descr, choices, defChoice)|AddGenericSingleChoiceListPage]] syntax.

You can give these two pages any ID you want but make sure it's unique. Besides the obvious reasons why it should be unique, the page ID is also used by various wizard pages to store per-page user selections inside the Code::Blocks configuration. So a duplicate ID will save under the same configuration key...

== Events ==
Now that we 've seen what page IDs are, we can talk about wizard script events.

To make a script handle a wizard event, you must create a script function with a special name to handle this event. All event functions must follow the same naming conventions:

* First is the event name
* An underscore follows
* And finally the page ID

Look in the events documentation below. Each event contains sample code.

=== OnEnter(forward) ===
Fired just before a page is displayed by the wizard. The script can initialize the page contents in this event.

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 0px solid gray"
!Return type || Value
|-
|void || -
|}

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 0px solid gray"
!Parameter || Type || Description
|-
|forward || bool || If true, the page entered after the user clicked "Next". If false, the user had clicked "Back".
|}

'''Sample:'''
function OnEnter_CompilerPage(forward)
{
// we only care to initialize if going forward
if (forward)
{
// do something?
}
}

=== OnLeave(forward) ===
Fired just before a page is changed to another. This is a very useful event because the script can assign the page contents to variables.

Inside this event, the script has the ability to abort the page change. So, for example, the script can check the values the user entered and abort the page from changing if it detects incorrect values.

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 0px solid gray"
!Return type || Value
|-
|bool || If this function returns true, the page is allowed to change. If it returns false, the change is aborted (the wizard stays in the same page).
|}

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 0px solid gray"
!Parameter || Type || Description
|-
|forward || bool || If true, the page entered after the user clicked "Next". If false, the user had clicked "Back".
|}

'''Sample:'''
function OnLeave_MyXRCPanel(forward)
{
// we only care to check validity if going forward
if (forward)
{
local userName = Wizard.GetTextControlValue("txtUserName");
if (userName.IsEmpty())
{
ShowWarning(_T("You must enter a username!"));
return false; // abort the page change
}
}
return true; // all is well
}

=== OnGetPrevPage() ===
In various times through the wizard's lifetime, it fires this event so that the wizard knows which page is "chained" before the current page.

Using this event, a script can dynamically alter the pages order (possibly based on user selections).

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 0px solid gray"
!Return type || Value
|-
|wxString || The previous page's ID
|}

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 0px solid gray"
!Parameter || Type || Description
|-
| - || - || -
|}

''NOTE: if the script returns an empty (or non-existent) page ID, the wizard assumes this is the first page (i.e. no previous page).''

'''Sample:'''
// assume we have the following pages in the wizard:
// Intro
// Project settings
// Single choice list (1)
// Select path for libfoo (2)
// Compiler selection (3)
//
// and we want to skip the libfoo path selection (2) based on user
// selection in the single choice list (1)
//
// for this to work, we need to create two event functions:
// OnGetNextPage for the choice list (1) and
// OnGetPrevPage for the compiler selection (3) and
// so that we can "jump over" the libfoo path selection page (2)

// we need a global var to keep the user's selection
ChoiceSelection <- 0;

function OnGetNextPage_MyChoiceList()
{
ChoiceSelection = Wizard.GetListboxSelection(_T("lstSelection"));
if (ChoiceSelection == 2)
{
// based on user's selection, we must skip the libfoo path selection page
return _T("CompilerPage"));
}
// normally, libfoo path selection follows
return _T("LibFooPath");
}

function OnGetPrevPage_CompilerPage()
{
if (ChoiceSelection == 2)
{
// based on user's selection, we must skip the libfoo path selection page
return _T("MyChoiceList"));
}
// normally, libfoo path selection is before this page
return _T("LibFooPath");
}

=== OnGetNextPage() ===
In various times through the wizard's lifetime, it fires this event so that the wizard knows which page is "chained" after the current page.

Using this event, a script can dynamically alter the pages order (possibly based on user selections).

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 0px solid gray"
!Return type || Value
|-
|wxString || The next page's ID
|}

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 0px solid gray"
!Parameter || Type || Description
|-
| - || - || -
|}

''NOTE: if the script returns an empty (or non-existent) page ID, the wizard assumes this is the last page (i.e. no next page).''

See the sample in [[Wizard Page Events#OnGetPrevPage()|OnGetPrevPage]].

[[User:Mandrav|Mandrav]] 06:17, 10 July 2006 (EDT)

Startup script

2006-11-11T17:40:57Z

Artojon: removed extra category

[[Category:Scripting Code::Blocks]]

When Code::Blocks finishes loading, it tries to load a script named ''startup.script''. If it is found it then tries to execute the ''"function main()"'' inside it (if there). The user can edit this script to run arbitrary customization commands on application startup.
The shipped ''startup.script'' just logs its presence in the application's debug log.

function main()
{
Log(_T("Running startup script"));
}

== See also ==

* [[Scripting commands]]

Build scripts

2006-11-11T17:40:29Z

Artojon: removed extra category

[[Category:Scripting Code::Blocks]]

Build scripts can help configuring build options and reusing these configurations.

What you need to do is create as many build scripts are needed and attach them to projects or build targets.

Let's see an example build script for the GNU GCC compiler:

// file: build_debug_symbols.script

function SetBuildOptions(base)
{
// enable debugging symbols
base.AddCompilerOption(_T("-g"));
// disable all optimizations
base.AddCompilerOption(_T("-O0"));
}

function UnsetBuildOptions(base)
{
// remove the settings we added in SetBuildOptions()
base.RemoveCompilerOption(_T("-g"));
base.RemoveCompilerOption(_T("-O0"));
}

The "base" parameter in both functions is a CompileOptionsBase instance. SetBuildOptions() is called before the project/target is built and UnsetBuildOptions() is called after it has built. Each build script ''must define both of these functions'', even if they 're not needed (in which case you can leave them with an empty body).

This specific script enables the generation of debugging symbols for the build target it is attached to. You could similarly have other build scripts for different configuration sets like optimizations, architecture, C++ options, C++ standards, etc.

Great. Now you have created your own set of build scripts. How do you attach them to project/targets? Simple: "Project->Properties->Scripts". Select the project or target to attach a script to and click "Add". If you want to detach a script, click "Remove".
You can also change the order scripts are ran with the two little arrows on the right side.
Finally, you can press "Validate all scripts" to make sure that the attached build scripts are valid.

If you choose to go the build scripts way for your project, please don't use the project build options dialog (unless maybe for global project settings). If you do, things may not work as expected and you will unrightfully blame Code::Blocks for this ;).

Well, that's all there is to it!

''NOTE: I 've been told that this is like MS Visual Studio's "properties". I wouldn't know since I don't use it myself. But maybe this similarity (if it really exists) helps you grasp the concept better.''

== See also ==

* [[Scripting commands]]

Debugger scripts

2006-11-11T17:40:01Z

Artojon: removed extra category

[[Category:Scripting Code::Blocks]]

Debugger scripts are similar to [http://www.codeproject.com/csharp/ImageVisualizer.asp Visual Studio Debugger Visualizer]. It allows you to write a small piece of code that gets executed by the debugger whenever you try to view a specific type of variables and can be used to show custom text with the important information you need in it.

Quote from Game_Ender - March 23, 2006

''I don't think its possible to open up another window to visualize something.''

Let's see how this works. Everything is inside a single file in the scripts/ folder, named gdb_types.script :). Support for more (user-defined) scripts is planned for the future.

This script is called by Code::Blocks at two places:

# when GDB is launched. It calls the script function RegisterTypes() to register all user-defined types with Code::Blocks' debugger.
# whenever GDB encounters your variable type, it calls the script functions specific to this datatype (registered in RegisterTypes() - more on that below).

That's the overview. Let's dissect the shipped gdb_types.script and see how it adds std::string support to GDB.

// Registers new types with driver
function RegisterTypes(driver)
{
// signature:
// driver.RegisterType(type_name, regex, eval_func, parse_func);

// STL String
driver.RegisterType(
_T("STL String"),
_T("[^[:alnum:]_]+string[^[:alnum:]_]*"),
_T("Evaluate_StlString"),
_T("Parse_StlString")
);
}

The "driver" parameter is the debugger driver but you don't need to care about it :) (currently this only works with GDB). This class contains a single method: RegisterType. Here's its C++ declaration:

void GDB_driver::RegisterType(const wxString& name, const wxString& regex, const wxString& eval_func, const wxString& parse_func)

So, in the above script code, the "STL String" (just a name - doesn't matter what) type is registered, providing a regular expression string for the debugger plugin to match against and, finally, it provides the names of the two mandatory functions needed for each registered type:

# evaluation function: this must return a command understood by the actual debugger (GDB in this case) and it issues it.
# parser function: once the debugger runs the command returned by the evaluation function, it passes its result to this function for further processing. What this function returns, is what is actually returned to the user (usually in the watches window or in a tooltip).

Let's see the evaluation function for std::string:

function Evaluate_StlString(type, a_str, start, count)
{
local oper = _T(".");

if (type.Find(_T("*")) > 0)
oper = _T("->");

local result = _T("output ") + a_str + oper + _T("c_str()[") + start + _T("]@");
if (count != 0)
result = result + count;
else
result = result + a_str + oper + _T("size()");
return result;
}

I 'm not going to explain what this function returns. I 'll just tell you that it returns a GDB command that will make GDB print the actual std::string's contents. ''Yes, you need to know your debugger and its commands before you try to extend it.''

What I will tell you though, is what those function arguments are.

* type: the datatype, e.g. "char*", "const string", etc.
* a_str: the name of the variable GDB is trying to evaluate.
* start: the start offset (used for arrays).
* count: the count starting from the start offset (used for arrays).

Let's see the relevant parser function now:

function Parse_StlString(a_str, start)
{
// nothing needs to be done
return a_str;
}

* a_str: the returned string when GDB ran the command returned by the evaluation function. In the case of std::string, it's the contents of the string.
* start: the start offset (used for arrays).

Well, in this example, nothing needs to be done. "a_str" already contains the std:string's contents so we just return it :)

I suggest you study how wxString is registered in that same file, as a more complex example.

== See also ==

* [[Scripting commands]]

Scripting Code::Blocks

2006-11-11T17:39:25Z

Artojon: moved under "Developer Documentation"

[[Category:Developer Documentation]]
[[Category:Scripting Code::Blocks]]
Code::Blocks supports '''scripting''' to extend various parts of its functionality during runtime. The scripting language used is [http://www.squirrel-lang.org Squirrel].

Currently, Code::Blocks uses scripts for:

'''[[Startup script|Startup]]'''
: Run arbitrary commands on application startup.

'''[[Wizard scripts|Wizards]]'''
: Register new wizards for generating projects, build targets, files or anything else. All wizards shipped with Code::Blocks are scripted.

'''[[Debugger scripts|Debugger]]'''
: Extend the GNU Debugger (and others) to support arbitrary data types. Code::Blocks ships with scripts that add wxString, std::string and std::vector "knowledge" to the GNU Debugger.

'''[[Build scripts|Build]]'''
: Extend the build system. Scripts can be attached to projects and/or build targets and are executed before and/or after each of these is built.

More Code::Blocks parts may be exposed to scripting in the future.

== See also ==
* [[Scripting commands]]

== External links ==
* [http://www.squirrel-lang.org/#doc Squirrel documentation]

Category:Scripting Code::Blocks

2006-11-11T17:38:34Z

Artojon: moved under "Develper Documentation"

[[Category:Developer Documentation]]
: ''Main article: [[Scripting Code::Blocks]]''

Category:Developer Documentation

2006-11-11T17:21:37Z

Artojon: add category "Code::Blocks Documentation"

[[Category:Code::Blocks Documentation]]
: ''Main article: [[Developer documentation]]

Category:User Documentation

2006-11-11T17:20:29Z

Artojon: add category "Code::Blocks Documentation"

[[Category: Code::Blocks Documentation]]
: ''Main article: [[User documentation]]

Keyboard Shortcuts

2006-11-11T17:16:19Z

Artojon: change category to "User documentation"

[[Category:User Documentation]]

::''Note: You can define your own keyboard shortcuts with the [[Keyboard Shortcuts plugin]]''

== Editor ==

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"

|- style="background: #ececec; border: 1px solid gray"
!Function
!Shortcut Key
|-

|-
| Undo last action || Ctrl + Z
|-

|-
| Redo last action || Ctrl + Shift + Z
|-

|-
| Cut selected text || Ctrl + X
|-

|-
| Copy selected text || Ctrl + C
|-

|-
| Paste text from clipboard || Ctrl + V
|-

|-
| Select all text || Ctrl + A
|-

|-
| Swap header / source || F11
|-

|-
| Comment highlighted code || Ctrl + Shift + C
|-

|-
| Uncomment highlighted code || Ctrl + Shift + X
|-

|-
| Duplicate line caret is on || Ctrl + D
|-

|-
| Auto-complete / Abbreviations || Ctrl + Space / Ctrl + J
|-

|-
| Show call tip || Ctrl + Shift + Space
|-

|-
| Swap line caret is on with line above it || Ctrl + T
|-

|-
| Toggle bookmark || Ctrl + B
|-

|-
| Goto previous bookmark || Alt + PgUp
|-

|-
| Goto next bookmark || Alt + PgDown
|-

|-
| Toggle current block folding || F12
|-

|-
| Toggle all folds || Shift + F12
|-

|}

This is a list of shortcuts provided by the Code::Blocks' editor component. These shortcuts cannot be rebound.

{| border="1" cellpadding="3" cellspacing="0" style="1px solid gray; border-collapse: collapse;"

|- style="background: #ececec; border: 1px solid gray"
!Function
!Shortcut Key
|-

|-
| Magnify text size. || Ctrl + Keypad "+"
|-

|-
| Reduce text size. || Ctrl + Keypad "-"
|-

|-
| Restore text size to normal. || Ctrl + Keypad "/"
|-

|-
| Cycle through recent files. || Ctrl + Tab
|-

|-
| Indent block. || Tab
|-

|-
| Dedent block. || Shift + Tab
|-

|-
| Delete to start of word. || Ctrl + BackSpace
|-

|-
| Delete to end of word. || Ctrl + Delete
|-

|-
| Delete to start of line. || Ctrl + Shift + BackSpace
|-

|-
| Delete to end of line. || Ctrl + Shift + Delete
|-

|-
| Go to start of document. || Ctrl + Home
|-

|-
| Extend selection to start of document. || Ctrl + Shift + Home
|-

|-
| Go to start of display line. || Alt + Home
|-

|-
| Extend selection to start of display line. || Alt + Shift + Home
|-

|-
| Go to end of document. || Ctrl + End
|-

|-
| Extend selection to end of document. || Ctrl + Shift + End
|-

|-
| Go to end of display line. || Alt + End
|-

|-
| Extend selection to end of display line. || Alt + Shift + End
|-

|-
| Expand or contract a fold point. || Ctrl + Keypad "*"
|-

|-
| Create or delete a bookmark. || Ctrl + F2
|-

|-
| Go to next bookmark. || F2
|-

|-
| Select to next bookmark. || Alt + F2
|-

|-
| Find selection. || Ctrl + F3
|-

|-
| Find selection backwards. || Ctrl + Shift + F3
|-

|-
| Scroll up. || Ctrl + Up
|-

|-
| Scroll down. || Ctrl + Down
|-

|-
| Line cut. || Ctrl + L
|-

|-
| Line copy. || Ctrl + Shift + T
|-

|-
| Line delete. || Ctrl + Shift + L
|-

|-
| Line transpose with previous. || Ctrl + T
|-

|-
| Line duplicate. || Ctrl + D
|-

|-
| Find matching preprocessor conditional, skipping nested ones. || Ctrl + K
|-

|-
| Select to matching preprocessor conditional. || Ctrl + Shift + K
|-

|-
| Find matching preprocessor conditional backwards, skipping nested ones. || Ctrl + J
|-

|-
| Select to matching preprocessor conditional backwards. || Ctrl + Shift + J
|-

|-
| Previous paragraph. Shift extends selection. || Ctrl + [
|-

|-
| Next paragraph. Shift extends selection. || Ctrl + ]
|-

|-
| Previous word. Shift extends selection. || Ctrl + Left
|-

|-
| Next word. Shift extends selection. || Ctrl + Right
|-

|-
| Previous word part. Shift extends selection. || Ctrl + /
|-

|-
| Next word part. Shift extends selection. || Ctrl + \
|-

|}

== Files ==

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"

|- style="background: #ececec; border: 1px solid gray"
!Function
!Shortcut Key
|-

|-
| New file or project || Ctrl + N
|-

|-
| Open existing file or project || Ctrl + O
|-

|-
| Save current file || Ctrl + S
|-

|-
| Save all files || Ctrl + Shift + S
|-

|-
| Close current file || Ctrl + F4 / Ctrl + W
|-

|-
| Close all files || Ctrl + Shift + F4 / Ctrl + Shift + W
|-

|}

This is a list of shortcuts provided by the Code::Blocks' tab component. These shortcuts cannot be rebound.

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"

|- style="background: #ececec; border: 1px solid gray"
!Function
!Shortcut Key
|-

|-
| Activate next open file || Ctrl + Tab
|-

|-
| Activate previous open file || Ctrl + Shift + Tab
|-

|}

== View ==

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"

|- style="background: #ececec; border: 1px solid gray"
!Function
!Shortcut Key
|-

|-
| Show / hide Messages pane || F2
|-

|-
| Show / hide Management pane || Shift + F2
|-

|-
| Move project up (in Project tree) || Ctrl + Shift + Up
|-

|-
| Move project down (in Project tree) || Ctrl + Shift + Down
|-

|-
| Activate prior (in Project tree) || Alt + F5
|-

|-
| Activate next (in Project tree) || Alt + F6
|-

|-
| Zoom in / out || Ctrl + Roll Mouse Wheel
|-

|-
| Focus editor || CTRL + Alt + E
|-

|}

== Search ==

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"

|- style="background: #ececec; border: 1px solid gray"
!Function
!Shortcut Key
|-

|-
| Find || Ctrl + F
|-

|-
| Find next || F3
|-

|-
| Find previous || Shift + F3
|-

|-
| Find in files || Crtl + Shift + F
|-

|-
| Replace || Ctrl + R
|-

|-
| Replace in files || Ctrl + Shift + R
|-

|-
| Goto line || Ctrl + G
|-

|-
| Goto file || Alt + G
|-

|-
| Goto function || Ctrl + Alt + G
|-

|}

== Build ==

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"

|- style="background: #ececec; border: 1px solid gray"
!Function
!Shortcut Key
|-

|-
| Build || Ctrl + F9
|-

|-
| Compile current file || Ctrl + Shift + F9
|-

|-
| Run || Ctrl + F10
|-

|-
| Build and Run || F9
|-

|-
| Rebuild || Ctrl + F11
|-

|}

== Debug ==

{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"

|- style="background: #ececec; border: 1px solid gray"
!Function
!Shortcut Key
|-

|-
| Debug || F8
|-

|-
| Continue debugging || Ctrl + F7
|-

|-
| Step over a code block || F7
|-

|-
| Step into a code block || Shift + F7
|-

|-
| Step out of a code block || Ctrl + Shift + F7
|-

|-
| Toggle breakpoint || F5
|-

|-
| Run to cursor || F4
|-

|-
| Previous error || Alt + F1
|-

|-
| Next error || Alt + F2
|-

|}

Category:Roadmaps

2006-11-11T17:15:10Z

Artojon:

: ''Main article: [[Roadmap]]''

The articles in this category deal with roadmaps to future versions of Code::Blocks.

Roadmap for version 1.5

2006-11-11T17:12:45Z

Artojon: change category to "Roadmaps"

[[Category:Roadmaps]]
''January 2007''
*Action-based user interface
*Fully automatic detection of document encoding
*Clean rewrite of code parser
*Code Refactoring functionality
*Mac OS X support
*Eclipse / KDevelop / Anjuta import

Roadmap for version 1.0

2006-11-11T17:12:15Z

Artojon: change category to "Roadmaps"

[[Category:Roadmaps]]
==Version 1.0 (Pheidippides)==
''August 2006''

==Version 1.0 RC final (Athenades)==
''Mid-July 2006''
*No feature additions.
*Regression and bug handling only.

==Version 1.0 RC 3 (Ephialtes)==
''Around end of June 2006''
*[[Image:Chk.png]]Unicode support
**[[Image:Chk.png]]User interface
**[[Image:Chk.png]]Configuration system
**[[Image:Chk.png]]Editor component
**[[Image:Nop.png]]Fully automatic detection of document encoding
*[[Image:Blk.png]]<s>Scripting support (Angelscript)</s> <i>(abandoned due to lack of 64bit support)</i>
*[[Image:Chk.png]]Scripting support (Squirrel/Sq plus)
**[[Image:Chk.png]]Watch scripts (see [[Debugger scripts]])
**[[Image:Chk.png]]Build target scripts
*[[Image:Chk.png]]Virtual folder support
*[[Image:Chk.png]]Global user variables
**[[Image:Chk.png]]Profile-dependent GUVs
**[[Image:Chk.png]]Multiple variable sets
**[[Image:Chk.png]]Custom variable definition
*[[Image:Chk.png]]wxFlatNoteBook editors
*[[Image:Chk.png]]wxAUI docking library
*[[Image:Chk.png]]Context-sensitive layout switching
*[[Image:Chk.png]]XML-based configuration system
*[[Image:Blk.png]]XML-based compiler framework
*[[Image:Blk.png]]Property-based build system
*[[Image:Chk.png]]Improved configuration user interface
*[[Image:Blk.png]]Automatic updates
*[[Image:Blk.png]]Usability and stability fixes for code completion plugin
*[[Image:Blk.png]]Regression and bug handling.

==Version 1.0 RC 2 (Leonidas)==
''25 October 2005''
*Precompiled headers (PCH) support! (currently works only with GCC)
*The source is now fully UNICODE-compatible!
*The source is also fully 64-bit compatible!
*Autoconf/automake build system is now used for non-windows platforms
* New editor functionality
**Find declaration
**Open #include
*Project wizard plugins
*Support for SDCC
*Better handling of modified files outside the IDE
*Single file compilation
*Find-in-Files for arbitrary paths/filemasks
*All internal file formats are well-formed, valid XML
*New plugins:
**Code statistics: counts nr. of source lines, nr. of comment lines, etc.
**CBProfiler: parses and displays the output of GProf, the GNU Profiler
**SourceExporter: exports the active file to HTML/RTF/ODT
*New lexers:
**Fortran77
**NVidia CG
**X-Base languages (Clipper, Foxpro)
*New and improved project templates:
**SDCC program
**Irrlicht 3D Graphics Engine
**Ogre 3D Graphics Engine
**GLFW project (OpenGL FrameWork)
**wxWidgets: static/dynamic unicode/ansi versions.

==Version 1.0 RC 1-1 (Oedipus)==
''2 August 2005''
*Several critical bug fixes

==Version 1.0 RC 1 (Laius)==
''25 July 2005''
*Compiler support for OpenWatcom
*Per-target environment variables
*Convenient "Start here" page
*Improved gcc error parsing
*Find in files functionality
*Ability to add files to project recursively.
*External dependency handling
*Better import of foreign project files
*Many GDB debugger updates
*Numerous user interface improvements
*New project templates
**QT4.
**Ogre3D.
* Modular Syntax highlighting
* Syntax highlighting support for:
**C/C++
**Windows resources
**HTML/XML/XSL
**Lua scripts
**GameMonkey scripts
**Hitach H8 ASM

Roadmap

2006-11-11T17:11:53Z

Artojon: added category

[[Category:Code::Blocks Documentation]]
[[Category:Roadmaps]]
====[[Roadmap for version 1.0]]====

====[[Roadmap for version 1.5]]====

Off-site documentation

2006-11-11T17:07:45Z

Artojon: added category

[[Category: Code::Blocks Documentation]]
This page is for links to '''off-site documentation''' i.e. information that has not yet been (or cannot be) added to the Wiki but exists in the Web.

== General ==

* French programming site, [http://loulou.developpez.com Developpez.com], has a [http://loulou.developpez.com/tutoriels/cpp/codeblocks/ tutorial about using Code::Blocks] (French only, [http://translate.google.com/translate?u=http%3A%2F%2Floulou.developpez.com%2Ftutoriels%2Fcpp%2Fcodeblocks%2F&langpair=fr%7Cen&hl=en&ie=UTF-8&oe=UTF-8&prev=%2Flanguage_tools English translation] by Google Translate).

* [http://www.sci.brooklyn.cuny.edu/~goetz/codeblocks/ Instruction manual for Code::Blocks] by the Dept. of Computer and Information Science of Brooklyn College of CUNY.

Off-site documentation

2006-11-11T17:06:56Z

Artojon:

This page is for links to '''off-site documentation''' i.e. information that has not yet been (or cannot be) added to the Wiki but exists in the Web.

== General ==

* French programming site, [http://loulou.developpez.com Developpez.com], has a [http://loulou.developpez.com/tutoriels/cpp/codeblocks/ tutorial about using Code::Blocks] (French only, [http://translate.google.com/translate?u=http%3A%2F%2Floulou.developpez.com%2Ftutoriels%2Fcpp%2Fcodeblocks%2F&langpair=fr%7Cen&hl=en&ie=UTF-8&oe=UTF-8&prev=%2Flanguage_tools English translation] by Google Translate).

* [http://www.sci.brooklyn.cuny.edu/~goetz/codeblocks/ Instruction manual for Code::Blocks] by the Dept. of Computer and Information Science of Brooklyn College of CUNY.

Off-site documentation

2006-11-11T17:06:24Z

Artojon:

This page is for links to '''off-site documentation''' i.e. information that has not yet been added to the Wiki but exists in the Web.

== General ==

* French programming site, [http://loulou.developpez.com Developpez.com], has a [http://loulou.developpez.com/tutoriels/cpp/codeblocks/ tutorial about using Code::Blocks] (French only, [http://translate.google.com/translate?u=http%3A%2F%2Floulou.developpez.com%2Ftutoriels%2Fcpp%2Fcodeblocks%2F&langpair=fr%7Cen&hl=en&ie=UTF-8&oe=UTF-8&prev=%2Flanguage_tools English translation] by Google Translate).

* [http://www.sci.brooklyn.cuny.edu/~goetz/codeblocks/ Instruction manual for Code::Blocks] by the Dept. of Computer and Information Science of Brooklyn College of CUNY.

Code::Blocks Documentation

2006-11-11T16:56:22Z

Artojon: off-site documentation is now a link

__NOTOC__
[[Category:Code::Blocks Documentation]]
==== [[User documentation]] ====
:Articles for Code::Blocks' users.

==== [[Developer documentation]] ====
:Articles for Code::Blocks' developers.

==== [[FAQ]]====
:Frequently Asked Questions

==== [[Off-site documentation]] ====
:Links to external documentation

Template:Infobox Plugin

2006-11-11T15:10:10Z

Artojon:

<div style="float: right; margin: 0px 10px 10px 10px;"><div style="font-size: medium; padding: 0; margin: 0;" align="center">''' {{{name}}} '''</div>
<div style="background-color: #f7f7f7; border: 1px solid #eaeaea; padding: 5px 10px 5px 10px; font-size: 90%"><div align="center">{{{logo}}}</div>
{| cellpadding="3" cellspacing="0" style="background-color: #f7f7f7;"

|-
| '''Developer(s):''' || {{{developer}}}
|-

|-
| '''Maintainer(s):''' || {{{maintainer}}}
|-

|-
| '''Version:''' || {{{version}}}
|-

|}
</div>
</div>

WxSmith plugin

2006-11-11T15:05:44Z

Artojon: use the new infobox, screenshot removed for now (too large)

[[Category:Code::Blocks Contrib Plugins]]
{{Infobox_Plugin|
name = wxSmith |
logo = [[Image:Wxsmith.png]] |
developer = byo, cyberkoa |
maintainer = byo, cyberkoa |
version = 1.0
}}

'''wxSmith''' is a Code::Blocks plugin for RAD editing of wxWidgets applications.

File:Wxsmith.png

2006-11-11T15:01:51Z

Artojon: Add wxSmith logo

Add wxSmith logo

Code Snippets plugin

2006-11-11T14:52:04Z

Artojon: use generic plugin image

[[Category: Code::Blocks Contrib Plugins]]
{{Infobox_Plugin|
name = Code snippets |
logo = [[Image:Generic-plugin.png]] |
developer = [[User:Artojon|Arto Jonsson]] |
maintainer = Arto Jonsson |
version = 0.1
}}

'''Code snippets''' plugin is a simple snippets management plugin for Code::Blocks. It integrates with the interface by creating a floating docking window which shows all the snippets. Snippets can be assigned to categories or they can be in the global category called ''All snippets''.

== Snippet management ==

=== Creating a new snippet ===

To create a snippet you must first write the code. The plugin does not use any dialogs (currently no message boxes either) so you have to write the code in the editor. Select your code and and drag it to a category, either in the ''All snippets'' or in other category you may have created.

You might noticed that the code you wrote is gone, this is how the drag and drop works; you move by default. If you want to copy the code and then create a new snippet, hold '''Ctrl''' and then drag it.

To assign a piece of code to a existing snippet you simply drag and drop the code to that snippet.

=== Applying a snippet ===

To apply a snippet, double click it and it will be applied to the currently active editor. You can alternatively right click on the snippet and select ''Apply''.

=== Creating a new category ===

Snippets can be added to categories. Each snippet can be at one category at a time. The number of categories and sub-categories is not limited however.

Each user created category has a parent category, the categories created in root have the ''All snippets'' category as parent. So if you want to create a category to the root, right click ''All snippets'' and select ''Add subcategory''.

== Searching ==

Snippets can be searched by typing words to the text edit control at the top of the docking window. Searching is performed by find-as-you-type method so you don't have to press any search buttons or Enter key. Searching by default includes categories.

Searching at the current state can be considered unoptimized. I haven't tested it yet with hundreds of items but I'm pretty sure it's slow. The search could by optimized by saving the search state when the firs item is found and then later use it as the starting point if the user wants to specify more specific search terms.

Searching is case-sensitive so "C++" and "c++" are seen as different search terms.

== File format ==

Code snippets plugin uses XML (UTF-8 encoded) file to save all code snippets.

The XML file starts with root item, snippets, which holds all the categories and code snippets. Code snippets and categories use the same element called item. The item's attributes tell what type of item it is, category or code snippet.

=== Elements ===

'''snippets'''
* Attributes: None
* Sub-elements: All snippets and categories

'''item'''
* Attributes:
** name -- Name of the element
** type -- Type of the element, either ''snippet'' or ''category''
* Sub-elements:
** snippet -- The actual code snippet (only if the item's type is ''snippet'')
** Sub-items and categories (only if the item's type is ''category'')

=== Example file ===

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<snippets>
<item name="Test category" type="category" />
<item name="Test item 1" type="snippet" />
<snippet>// Test 1</snippets>
</item>
</item>
<item name="Test item 2" type="snippet" />
<snippet>// Test 2</snippets>
<item>
</snippets>

The file would create the following structure:

All snippets
|
|- Test category
| |
| |- Test item 1
|
|- Test item 2

Environment Variables plugin

2006-11-11T14:51:21Z

Artojon: use the new infobox

[[Category:Code::Blocks Contrib Plugins]]
{{Infobox_Plugin|
name = Environment Variables Editor |
logo = [[Image:Generic-plugin.png]] |
developer = [[User:MortenMacFly|MortenMacFly]] |
maintainer = MortenMacFly |
version = 0.92
}}

'''Environment variables editor''' plugin allows setting environment variables in the focus of Code::Blocks.

File:Generic-plugin.png

2006-11-11T14:50:27Z

Artojon: Add generic plugin logo

Add generic plugin logo

DragScroll plugin

2006-11-11T14:34:19Z

Artojon:

[[Category:Code::Blocks Contrib Plugins]]
{{Infobox_Plugin|
name = Mouse Drag Scrolling |
logo = [[Image:Dragscroll.png]] |
developer = [[User:Pecan|Pecan]] |
maintainer = Pecan |
version = 0.28
}}

'''DragScroll''' (or '''Mouse Drag Scrolling''') plugin enables scrolling of text areas such as the editor and the application / debug log with mouse.

File:Dragscroll.png

2006-11-11T14:33:04Z

Artojon: Add DragScroll logo

Add DragScroll logo

Code Snippets plugin

2006-11-11T14:22:30Z

Artojon:

[[Category: Code::Blocks Contrib Plugins]]
{{Infobox_Plugin|
name = Code snippets |
logo = |
developer = [[User:Artojon|Arto Jonsson]] |
maintainer = Arto Jonsson |
version = 0.1
}}

'''Code snippets''' plugin is a simple snippets management plugin for Code::Blocks. It integrates with the interface by creating a floating docking window which shows all the snippets. Snippets can be assigned to categories or they can be in the global category called ''All snippets''.

== Snippet management ==

=== Creating a new snippet ===

To create a snippet you must first write the code. The plugin does not use any dialogs (currently no message boxes either) so you have to write the code in the editor. Select your code and and drag it to a category, either in the ''All snippets'' or in other category you may have created.

You might noticed that the code you wrote is gone, this is how the drag and drop works; you move by default. If you want to copy the code and then create a new snippet, hold '''Ctrl''' and then drag it.

To assign a piece of code to a existing snippet you simply drag and drop the code to that snippet.

=== Applying a snippet ===

To apply a snippet, double click it and it will be applied to the currently active editor. You can alternatively right click on the snippet and select ''Apply''.

=== Creating a new category ===

Snippets can be added to categories. Each snippet can be at one category at a time. The number of categories and sub-categories is not limited however.

Each user created category has a parent category, the categories created in root have the ''All snippets'' category as parent. So if you want to create a category to the root, right click ''All snippets'' and select ''Add subcategory''.

== Searching ==

Snippets can be searched by typing words to the text edit control at the top of the docking window. Searching is performed by find-as-you-type method so you don't have to press any search buttons or Enter key. Searching by default includes categories.

Searching at the current state can be considered unoptimized. I haven't tested it yet with hundreds of items but I'm pretty sure it's slow. The search could by optimized by saving the search state when the firs item is found and then later use it as the starting point if the user wants to specify more specific search terms.

Searching is case-sensitive so "C++" and "c++" are seen as different search terms.

== File format ==

Code snippets plugin uses XML (UTF-8 encoded) file to save all code snippets.

The XML file starts with root item, snippets, which holds all the categories and code snippets. Code snippets and categories use the same element called item. The item's attributes tell what type of item it is, category or code snippet.

=== Elements ===

'''snippets'''
* Attributes: None
* Sub-elements: All snippets and categories

'''item'''
* Attributes:
** name -- Name of the element
** type -- Type of the element, either ''snippet'' or ''category''
* Sub-elements:
** snippet -- The actual code snippet (only if the item's type is ''snippet'')
** Sub-items and categories (only if the item's type is ''category'')

=== Example file ===

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<snippets>
<item name="Test category" type="category" />
<item name="Test item 1" type="snippet" />
<snippet>// Test 1</snippets>
</item>
</item>
<item name="Test item 2" type="snippet" />
<snippet>// Test 2</snippets>
<item>
</snippets>

The file would create the following structure:

All snippets
|
|- Test category
| |
| |- Test item 1
|
|- Test item 2