https://wiki.codeblocks.org/api.php?action=feedcontributions&user=XayC&feedformat=atomCode::Blocks - User contributions [en]2024-03-28T19:19:37ZUser contributionsMediaWiki 1.35.0https://wiki.codeblocks.org/index.php?title=Roadmap&diff=5697Roadmap2008-09-28T16:31:34Z<p>XayC: </p>
<hr />
<div>[[Category:Developer Documentation]]<br />
[[Category:Roadmaps]]<br />
Since the 18 February 2008 Code::Blocks uses a new version numbering scheme. The goals listed in the roadmap though, may still be valid.<br />
<br />
''Taken from main page'':<br />
<blockquote><br />
After a discussion recently held between the core team members, it was decided to change the version numbering scheme used for Code::Blocks. The new scheme will follow the "Year.Month" style, also known as the "Ubuntu version scheme".<br />
This means that our next release will be named as 8.02 (February 2008).<br />
</blockquote><br />
----<br />
<br />
====[[Roadmap for version 1.0]]====<br />
<br />
====[[Roadmap for version 1.5]]====</div>XayChttps://wiki.codeblocks.org/index.php?title=Roadmap&diff=5696Roadmap2008-09-28T16:21:41Z<p>XayC: Update: new version numbering scheme</p>
<hr />
<div>[[Category:Developer Documentation]]<br />
[[Category:Roadmaps]]<br />
Since the 18 February 2008 Code::Blocks uses a new version numbering scheme. The goals listed in the roadmap though, may still be valid.<br />
<br />
''Taken from main page'':<br />
After a discussion recently held between the core team members, it was decided to change the version numbering scheme used for Code::Blocks.<br />
The new scheme will follow the "Year.Month" style, also known as the "Ubuntu version scheme".<br />
This means that our next release will be named as 8.02 (February 2008).<br />
<br />
----<br />
<br />
<br />
====[[Roadmap for version 1.0]]====<br />
<br />
====[[Roadmap for version 1.5]]====</div>XayChttps://wiki.codeblocks.org/index.php?title=Creating_a_patch_to_submit_(Patch_Tracker)&diff=5695Creating a patch to submit (Patch Tracker)2008-09-28T16:06:11Z<p>XayC: Updated links, added some instructions</p>
<hr />
<div>[[Category:Developer Documentation]]<br />
== Introduction ==<br />
You want to contribute to Code::Blocks? - Thank you! That is really appreciated. Hence you can help us even more if you read the following paragraphs carefully.<br />
<br />
First of all please make sure the feature you are implementing is not already implemented in the "nightly builds" of Code::Blocks ([/index.php/board,20.0.html /index.php/board,20.0.html]). Furthermore browse through the list of available patches at the Code::Blocks project page at BerliOS (see section "Patch submission" below on how to gain access). If you are unsure, don't hesitate to ask in the forum ([ ]) for advise.<br />
<br />
You can make it easier for the developers to integrate your patches if you follow the advices of this page. Patches can be created in different formats. The format that is used by Code::Blocks is called a "unified diff". Hence 3rd party tools may still create a different patch format although it may be labelled as "unified diff". To avoid unnecessary incompatibilities the best way to provide a patch is to '''use the Subversion (SVN) diff''' (using the command line tool or a SVN GUI application).<br />
<br />
== What is required? ==<br />
Not too much, you might already have the required tools installed.<br />
You'll need a subversion client software. You can download a current version for your OS at the Subversion project webpage here: [http://subversion.tigris.org http://subversion.tigris.org]. If you want to apply or test your patches you'll also need the '''patch''' program; you can download it and find more information at the [http://www.gnu.org/software/patch/ GNU patch website]. <br />
<br />
It is a good idea to apply your code to the most up-to-date sources of Code::Blocks as they are available at the SVN repository. You'll find the instructions how to obtain the sources here: [https://www.codeblocks.org/downloads/7 https://www.codeblocks.org/downloads/7]. Once you've created your local sandbox you can start integrating your changes into it. Thus you may modify existing files or add new ones. When you have finished please make sure you've verified your implementation (feature(s)) work properly. Now it's time to create the patch.<br />
<br />
== Patch creation ==<br />
If you have added new files you first have to register them with your sandbox. Thus go into the directory you've added new files and type at the command line:<br />
: <tt>svn add filename(s)</tt><br />
...whereas "filename(s)" needs to be replaced with the files you've added. Of course if you are not using the command line version of SVN you can easily use the "Add" feature of your prefered SVN GUI. If you've completed adding all your new files to your sandbox your are ready to create the patch.<br />
<br />
First of all go to the top-level directory of your sandbox (the first directory that has a hidden ".svn" folder with content). This is done because the patch file generated by the following command is relative to the directory where it's performed. This is the command to create the patch file:<br />
: <tt>svn diff > my.patch</tt><br />
<br />
You can change the name of the patch (''my.patch'' in the example) with a more descriptive name but make sure you leave the file extension ".patch" as this avoids conflicts while submitting the patch. The creation of the ''difference file'' (the patch file) may take some time, please be patient.<br />
<br />
Once the patch file is created please make sure it contains content! Otherwise make sure you followed the steps above or ask in the forum ([ ]) for support.<br />
=== Patch application and testing ===<br />
In order to apply a patch you need the patch program. Make sure you are in the same directory the patch was created and then type the following command:<br />
: <tt>patch --unified --strip=0 --forward --input=my.patch</tt><br />
<br />
This will perform some checks and then will patch your files using the difference information saved in the patch file (''my.patch'' in the example).<br />
<br />
'''Important note:''' If you are working under Windows you may have to convert the patch file to dos line-ending format. You can do that using "unix2dos my.patch".<br />
<br />
== Patch submission ==<br />
By now you are ready to submit your work to the Patch Tracker at BerliOS ([http://developer.berlios.de/projects/codeblocks http://developer.berlios.de/projects/codeblocks/]) - the developer platform for Code::Blocks. If you haven't done already you need to register with BerliOS to gain the right to submit patches to projects. The membership is free and appreciated. Select the "Patches" section ([http://developer.berlios.de/patch/?group_id=5358 http://developer.berlios.de/patch/?group_id=5358]) of the Code::Blocks project page. Click on "Submit A Patch" and fill out the form that appears. For now you only need to select a category for your patch, a '''descriptive''' summary and the patch itself. Make sure you enable the checkbox "Upload Patch" and provide the patch file you've just created. Then you are ready for submission - click on the "Submit patch" button on the bottom of the page.<br />
<br />
By now you should see the current list of patches with your patch at the top. Please note you can add additional comments or updates to your patch by simply clicking on the patch in the list and fill out the form that appears.<br />
<br />
'''Thank you very much for your submission!'''</div>XayChttps://wiki.codeblocks.org/index.php?title=Creating_a_patch_to_submit_(Patch_Tracker)&diff=5694Creating a patch to submit (Patch Tracker)2008-09-27T16:42:17Z<p>XayC: /* Patch application and testing */</p>
<hr />
<div>[[Category:Developer Documentation]]<br />
== Introduction ==<br />
You want to contribute to Code::Blocks? - Thank you! That is really appreciated. Hence you can help us even more if you read the following paragraphs carefully.<br />
<br />
First of all please make sure the feature you are implementing is not already implemented in the "nigthly builds" of Code::Blocks ([https://www.codeblocks.org/nightly https://www.codeblocks.org/nightly]). Furthermore browse through the list of available patches at the Code::Blocks project page at BerliOS (see section "Patch submission" below on how to gain access). If you are unsure, don't hesitate to ask in the forum ([ ]) for advise.<br />
<br />
You can make it easier for the developers to integrate your patches if you follow the advices of this page. Patches can be created in different formats. The format that is used by Code::Blocks is called a "unified diff". Hence 3rd party tools may still create a different patch format allthough it may be labelled as "unified diff". To avoid unnecessary incompatibilities the best way to provide a patch is to '''use the Subversion (SVN) diff''' (using the command line tool or a SVN GUI application).<br />
<br />
== What is required? ==<br />
Not too much, you might already have the required tools installed.<br />
You'll need a subversion client software. You can download a current version for your OS at the Subversion project webpage here: [http://subversion.tigris.org http://subversion.tigris.org]. It is a good idea to apply your code to the most up-to-date sources of Code::Blocks as they are available at the SVN repository. You'll find the instructions how to obtain the sources here: [https://www.codeblocks.org/source_code.shtml https://www.codeblocks.org/source_code.shtml]. Once you've created your local sandbox you can start integrating your changes into it. Thus you may modify existing files or add new ones. When you have finished please make sure you've verified your implementation (feature(s)) work properly. Now it's time to create the patch.<br />
<br />
== Patch creation ==<br />
If you have added new files you first have to register them with your sandbox. Thus go into the directory you've added new files and type at the command line:<br />
: <tt>svn add filename(s)</tt><br />
...whereas "filename(s)" needs to be replaced with the files you've added. Of course if you are not using the command line version of SVN you can easily use the "Add" feature of your prefered SVN GUI. If you've completed adding all your new files to your sandbox your are ready to create the patch. First of all go to the top-level directory of your sandbox (the first directory that has a hidden ".svn" folder with content). Then type at the command line:<br />
: <tt>svn.exe diff > my.patch</tt><br />
...replacing "my" with a descriptive name. Please make sure you leave the file extension ".patch" as this avoids conflicts while submitting the patch. ''This operation may take a while.'' The patch data are computed. Please be patient!<br />
Once the patch file is created please make sure it contains content! Otherwise make sure you followed the steps above or ask in the forum ([ ]) for support.<br />
=== Patch application and testing ===<br />
<tt>patch --unified --strip=0 --forward --input=my.patch</tt><br />
<br />
''Note:'' You may have to convert my.patch to dos line ending using "unix2dos my.patch"<br />
<br />
== Patch submission ==<br />
By now you are ready to submit your work to the Patch Tracker at BerliOS ([http://developer.berlios.de/projects/codeblocks http://developer.berlios.de/projects/codeblocks/]) - the developer platform for Code::Blocks. If you haven't done already you need to register with BerliOS to gain the right to submit patches to projects. The membership is free and appreciated. Select the "Patches" section ([http://developer.berlios.de/patch/?group_id=5358 http://developer.berlios.de/patch/?group_id=5358]) of the Code::Blocks project page. Click on "Submit A Patch" and fill out the form that appears. For now you only need to select a category for your patch, a '''descriptive''' summary and the patch itself. Make sure you enable the checkbox "Upload Patch" and provide the patch file you've just created. Then you are ready for submission - click on the "Submit patch" button on the bottom of the page.<br />
<br />
By now you should see the current list of patches with your patch at the top. Please note you can add additional comments or updates to your patch by simply clicking on the patch in the list and fill out the form that appears.<br />
<br />
'''Thank you very much for your submission!'''</div>XayChttps://wiki.codeblocks.org/index.php?title=WxSmith_tutorial:_Accessing_items_in_resource&diff=5314WxSmith tutorial: Accessing items in resource2008-01-21T08:27:19Z<p>XayC: Added Category</p>
<hr />
<div>[[Category:wxSmith Documentation]]<br />
<br />
<br />
= Accessing items in resource =<br />
<br />
Wecome in next tutorial. This time I'll show you how to access items in resource. I'll show you some basics - for example how to read data from text boxes, change labels, and some more advanced things like changing colours and fonts while application is running. As usual we will start with empty application. You shouldn't have any problems with it - all instructions are in first tutorial.<br />
<br />
<br />
= Adding few items we will work on =<br />
<br />
In this tutorial we will work on items so let's add some:<br />
<br />
[[Image:wxs_tut06_001.png]]<br />
<br />
In this resource wxFlexGridSizer with 2 columns is used as background. In first three rows we have wxStaticText, wxTextCtrl and wxGauge - we will operate on them using buttons on the right column. Below there is wxSlider which will be used to change size of font - I've changed it's '''Max''' property to 30 to limit size range. Below there's button which will be used to change colours of some items.<br />
<br />
= Accessing items through members of resource class =<br />
<br />
If you add item in editor, in most cases wxSmith will add new member variable into resource's c++ class. All those members are listed inside <code>//(*Declarations ... //*)</code> code blocks. In case of window we crated it should look like this:<br />
<br />
...<br />
class Tutorial_6Frame: public wxFrame<br />
{<br />
...<br />
<br />
//(*Declarations(Tutorial_6Frame)<br />
wxSlider* Slider1;<br />
wxButton* Button4;<br />
wxStaticText* StaticText2;<br />
wxButton* Button1;<br />
wxGauge* Gauge1;<br />
wxStaticText* StaticText1;<br />
wxStaticText* StaticText3;<br />
wxButton* Button2;<br />
wxButton* Button3;<br />
wxStatusBar* StatusBar1;<br />
wxTextCtrl* TextCtrl1;<br />
//*)<br />
...<br />
};<br />
...<br />
<br />
Each item which has such member variable will also have following properties:<br />
* '''Var name''' - name of used variable<br />
* '''Is member''' - switch whether this item should be accessible through class member variable<br />
<br />
So if you want to change name used to access item, '''Var name''' is right property to change.<br />
<br />
wxSmith forces few restrictions on variable names. Most obvious is that each variable name must be valid c++ identifier so you can not provide special characters or even spaces. Another limitations is that variable names must be unique.<br />
If name is invalid, wxSmith will automatically replace it with name that matches criteria.<br />
<br />
= Changing label in wxStaticText =<br />
<br />
Ok, let's do some basic excercise by changing label of first wxStaticText. To do this double click on button next to it to generate event handler and change the code to following thing:<br />
<br />
<br />
void Tutorial_6Frame::OnButton1Click(wxCommandEvent& event)<br />
{<br />
StaticText1->SetLabel(_("Label changed"));<br />
Layout();<br />
}<br />
<br />
In first line of function body we used '''SetLabel()''' function to change text of label. Because length of the text changes, we must recalculate positions which is done by calling '''Layout()''' function.<br />
<br />
In case of static items (those which can't be changed by user) usually have two functions: GetLabel and SetLabel which read and write content presented by this item.<br />
<br />
<br />
You may wonder why we used some weird notation for string:<br />
_("Label changed")<br />
instead of simple<br />
"Label changed"<br />
<br />
There are two advantages of such approach:<br />
* By adding _(...) around our string we prepare our application for translation process. wxWidgets can help developing multilanguage applications and when some some different language will be used, it will automatically search for translaction of "Label changed" text in strings database.<br />
* wxWidgets may be provided in two versions: with unicode support and without it (ansi build). In case of unicode version, we would have to use unicode strings: '''L"Label changed"''' and in case of ansi version we would have to use standard string notation: '''"Label changed"'''. Using '''_(...)''' macro grants that no matter what wxWidgets version is used, it will always produce proper code.<br />
<br />
There's alternative version of string macro which works simillarily to _(...) which is written in form _T(...) or wxT(...). It works like _() one but the string is never translated.<br />
<br />
= Reading value from wxTextCtrl =<br />
<br />
Now let's read something that's written by user. We will use wxTextCtrl (with variable TextCtrl1) for this and show the text using standard message box. Let's double click the '''Read text''' button and change the code to following:<br />
<br />
void Tutorial_6Frame::OnButton2Click(wxCommandEvent& event)<br />
{<br />
wxString Text = TextCtrl1->GetValue();<br />
wxMessageBox(_("User entered text:\n") + Text);<br />
}<br />
<br />
In the first line we read value from TextCtrl and store it inside variable of type wxString. wxString is wxWidgets implementation of string object and this library uses it as base for string representation.<br />
<br />
In the second line we call '''wxMessageBox''' function which shows standard message box just like it was modal dialog.<br />
<br />
Usually items which provide content entered by user have two member functions: GetValue and SetValue. You can use them to read and write content of such item.<br />
<br />
= Changing value of wxGauge =<br />
<br />
Now let's mix reading and writing of item's value on one function. We will use wxGauge for this. We will use it's two member functions: GetValue and SetValue. I've written ealier that those functions usually exist in items where user can enter some value. Well it's not a gold rule and there are exceptions from it like in case of this item :).<br />
<br />
Ok, let's add handler for third button:<br />
<br />
void Tutorial_6Frame::OnButton3Click(wxCommandEvent& event)<br />
{<br />
int NewValue = Gauge1->GetValue()+10;<br />
if ( NewValue > 100 ) NewValue = 0;<br />
Gauge1->SetValue(NewValue);<br />
}<br />
<br />
In first line we generate new value of progress by reading current one and adding 10 to it. In second line we prevent the value from getting out of range (by default wxGauge has range set to 0..100 - this can be changed in properties). In third line we write new value into gauge.<br />
<br />
= Using value from wxSlider to change font size =<br />
<br />
Now let's do something more advanced. In our resource there's wxSlider and text saying that it changes font size. We will change font of this label. But we will have to update font size in two steps:<br />
<br />
* As long as user draggs the slider we should change font size only<br />
* When user finishes dragging we should layout window because size of text changes<br />
<br />
wxSlider provides two events that can be used right for this purpose. First is '''EVT_COMMAND_SCROLL_THUMB_TRACK''' which is fired while dragging the slider. Second is '''EVT_COMMAND_SCROLL_THUMB_RELEASE''' which is fired when user finishes dragging.<br />
<br />
Because we use events which are not default we would have to add them through properties browser. You can switch between editing standard properties and events by clicking on buttons at the top of browser:<br />
<br />
[[Image:wxs_tut06_002.png]].<br />
<br />
If you switch to events, search for required events and choose '''Add new handler''' from drop-down list.<br />
Here's the code for '''EVT_COMMAND_SCROLL_THUMB_TRACK''' handler:<br />
<br />
void Tutorial_6Frame::OnSlider1CmdScrollThumbTrack(wxScrollEvent& event)<br />
{<br />
wxFont Font = StaticText2->GetFont();<br />
Font.SetPointSize( Slider1->GetValue() );<br />
StaticText2->SetFont(Font);<br />
}<br />
<br />
Here we get font used by StaticText control by using '''GetFont()''' function, change font's size by using '''GetPointSize()''' and write font back by using '''SetFont()''' function. '''GetFont()''' and '''SetFont()''' are available in most items.<br />
<br />
Now let's code '''EVT_COMMAND_SCROLL_THUMB_RELEASE''':<br />
<br />
<br />
void Tutorial_6Frame::OnSlider1CmdScrollThumbRelease(wxScrollEvent& event)<br />
{<br />
Layout();<br />
GetSizer()->SetSizeHints(this);<br />
}<br />
<br />
In the first line we adopt positions of items to new environment just like in case of changing label in wxStaticText. In the second line we recalculate minimal size of the window making sure that all items will have enough space.<br />
<br />
= Changing item's colour =<br />
<br />
Last thing we will do in this tutorial is to change colour of some item. As in case of fonts we will change label on the left side of '''Change''' button. Since we will use standard event of this button, we can add event handler by double-clicking on it. And here's the code:<br />
<br />
void Tutorial_6Frame::OnButton4Click(wxCommandEvent& event)<br />
{<br />
wxColour OldColour = StaticText3->GetForegroundColour();<br />
wxColour NewColour = wxGetColourFromUser(this,OldColour);<br />
<br />
if ( NewColour.IsOk() )<br />
{<br />
StaticText3->SetForegroundColour(NewColour);<br />
}<br />
}<br />
<br />
At the beginning we read current colour to variable '''OldColour'''. In next lie we call '''wxGetColourFromUser''' function which opens dialog where we can choose colour. <br />
<br />
The '''NewColour.IsOk()''' call is required because if user cancels colour selection it will return false.<br />
<br />
At the end we set new colour by using '''SetForegroundColour''' function.<br />
<br />
<br />
= More informations =<br />
<br />
We reached end of this tutorial. I showed only few operations on items and there's much more you can do. For more details you can check wxWidgets' documentation available [http://www.wxwidgets.org/manuals/stable/wx_contents.html here].</div>XayChttps://wiki.codeblocks.org/index.php?title=WxSmith_tutorial:_Working_with_multiple_resources&diff=5313WxSmith tutorial: Working with multiple resources2008-01-21T08:26:36Z<p>XayC: Added Category</p>
<hr />
<div>[[Category:wxSmith Documentation]]<br />
<br />
<br />
= Working with multiple resources =<br />
<br />
Hello. In this tutorial I'll show you how to create application with more than one window. I'll also show how to invoke one window from another. At the end we will learn how to change man window in project settings.<br />
<br />
So let's start.<br />
<br />
= Creating empty project =<br />
<br />
As usual we will start with empty project. You can find informations on how to do this in the first tutorial. Remember to crate frame-based application and select wxSmith as main RAD designer. Also let's name the project "Tutorial 4".<br />
<br />
If empty application compiles and runs fine we can advance to next step.<br />
<br />
= Adding few dialogs =<br />
<br />
New resources can be added from '''wxSmith''' menu. You can find following options there:<br />
<br />
* '''Add wxPanel''' - this will add new panel into resource<br />
* '''Add wxDialog''' - this adds new dialog window<br />
* '''Add wxFrame''' - this adds new frame window.<br />
<br />
Ok, let's add new wxDialog. If you choose this option it will show following window:<br />
<br />
[[Image:wxs_tut04_005.png]]<br />
<br />
Here we can configure following parameters:<br />
<br />
* Class name - it's name of class which will be generated for the resource. It will also be a name of resource<br />
* Header file - name of header file with class declaration<br />
* Source file - name of source file with class definition<br />
* Xrc file - if you check this option you can enter name of XRC file which will contain XRC's structure (XRC files will be covered in other tutorial)<br />
* Add XRC file to autoload list - this option is aailable only with XRC file and notifies wxSmith that it should automatically load XRC file when the application starts.<br />
<br />
Now let's change name of resource to something better like "FirstDialog". Note that if you change class name, names of files are also updated (they are updated as long as you don't change them manually). After clicking OK you will be prompted for list of build target into which new resource will be added. Select both debug and release and we can nontinue.<br />
<br />
New dialog is automatically opened in editor. Let's add some simple content:<br />
<br />
[[Image:wxs_tut04_002.png]]<br />
<br />
Now let's add some wxFrame resource (FirstFrame) and add some content into it:<br />
<br />
[[Image:wxs_tut04_003.png]]<br />
<br />
<br />
= Using dialog window in modal mode =<br />
<br />
Dialogs can be shown in so-called modal mode. This means that when such dialog is shown, all other windows in the application are frozen as long as the dialog finishes it's job. Such dialogs are usefull when user should quickly provide some informations - for example the window used to configure new resource was modal.<br />
<br />
Now let's try to invoke our dialog. Generally such dialog will pop-up as reaction for user action like choosing menu option or clicking on button. We will use he button since this approach is really easy.<br />
<br />
Ok, let's switch into main frame - the one that was opened right after creating new project, and add sizer and button:<br />
<br />
[[Image:wxs_tut04_004.png]]<br />
<br />
Now we have to create action for button-click event. The easiest way is to double-click the button in editor. wxSmith will automatically add new event handler function:<br />
<br />
void Tutorial_4Frame::OnButton1Click(wxCommandEvent& event)<br />
{<br />
}<br />
<br />
If you can't find this code, scroll down to the end of cpp file.<br />
<br />
Now let's Invoke our dialog:<br />
<br />
void Tutorial_4Frame::OnButton1Click(wxCommandEvent& event)<br />
{<br />
FirstDialog dialog(this);<br />
dialog.ShowModal();<br />
}<br />
<br />
In the first added line we created dialog's object notifying that ''this'' window (main frame) is parent of dialog. In the second line we show the dialog. Note that call to ShowModal() blocks untill dialog is closed.<br />
<br />
There's one more thing we need to add before our application compiles. Jump to the beginning of the file and add following code next to other includes:<br />
<br />
#include "FirstDialog.h"<br />
<br />
Note that you shouldn't add it inside code which looks like this:<br />
<br />
//(*InternalHeaders(Tutorial_4Frame)<br />
#include <wx/intl.h><br />
#include <wx/string.h><br />
//*)<br />
<br />
This is block of code that is automatically generated by wxSmith. Every block starts with ''//(*BlockName'' comment and ends with ''//*)''. You may find other blocks in both header and source files. If you change their content, all changes will be lost net time you change something in editor.<br />
<br />
To sum things up, headers section should look like this:<br />
<br />
#include "wx_pch.h"<br />
#include "Tutorial_4Main.h"<br />
#include <wx/msgdlg.h><br />
#include "FirstDialog.h"<br />
<br />
//(*InternalHeaders(Tutorial_4Frame)<br />
#include <wx/intl.h><br />
#include <wx/string.h><br />
//*)<br />
<br />
Now we can compile and run our application- if you click button on main window, dialog will pop-up:<br />
<br />
[[Image:wxs_tut04_005.png]]<br />
<br />
= Using dialog and frame window in non-modal mode =<br />
<br />
Another mode used to show windows is modal-less mode. In such case new window does not block other windows in application and two (or more) windows can cooperate in one application.<br />
<br />
Before we add new code into our application there's one more thing you should know. Each window may exist only as long as it's object (instance of resource's c++ class). So we can not use same approach as in case of modal dialog. In modal mode object was created as local variable of event handler. We could do this only because ShowModal method was blocked as long as diaog was shown. <br />
Now we will have to create objets using new opertor because objects must exist after leaving handler functin and also because windows not using modal mode will delete such objects automatically when window is closed.<br />
<br />
<br />
To allow creating FirstFrame class we should add '''#include "FirstFrame.h"''' into list of includes just like in case of FirstDialog:<br />
<br />
#include "wx_pch.h"<br />
#include "Tutorial_4Main.h"<br />
#include <wx/msgdlg.h><br />
#include "FirstDialog.h"<br />
#include "FirstFrame.h"<br />
<br />
//(*InternalHeaders(Tutorial_4Frame)<br />
#include <wx/intl.h><br />
#include <wx/string.h><br />
//*)<br />
<br />
<br />
Now let's add two more buttons to main frame:<br />
* Add new dialog<br />
* Add new frame<br />
<br />
We can also name the first button to show what it does:<br />
<br />
[[Image:wxs_tut04_006.png]]<br />
<br />
Now let's add handler to ''Add new dialog'' button:<br />
<br />
void Tutorial_4Frame::OnButton2Click(wxCommandEvent& event)<br />
{<br />
FirstDialog* dlg = new FirstDialog(this);<br />
dlg->Show();<br />
}<br />
<br />
Analogically we can write the code for firstFrame:<br />
<br />
void Tutorial_4Frame::OnButton3Click(wxCommandEvent& event)<br />
{<br />
FirstFrame* frm = new FirstFrame(this);<br />
frm->Show();<br />
}<br />
<br />
Now each time we click ''Add new dialog'' or ''Add new frame'' buton, new window shows up.<br />
<br />
<br />
<br />
This is the end of this tutorial. I hope that you learned some new useful things. In the next tutorial I'll show how to use the last type of resources, wxPanel, inside other resources. <br />
<br />
See you.</div>XayChttps://wiki.codeblocks.org/index.php?title=Code::Blocks_SDK_events&diff=5084Code::Blocks SDK events2007-12-13T09:20:12Z<p>XayC: /* Available events */</p>
<hr />
<div>[[Category:Code::Blocks Documentation]]<br />
[[Category:Developer Documentation]]<br />
During a Code::Blocks session, many things are happening: projects/files loading, closing, activating, saving, etc. These are interesting things that happen and various parts of Code::Blocks and its plugins are interested in them.<br />
The Code::Blocks SDK provides functions that allow a part of the code to be "subscribed" to these events (i.e. be notified when they happen). This is what we 'll look at in this article.<br />
<br />
''Note: since mid-November 2007, loggers registration is handled with events too.''<br />
<br />
<br />
=== Available events ===<br />
There are many event constants defined for the interesting events that happens inside Code::Blocks. These constants are defined in <tt>include/sdk_events.h</tt> and listed at the bottom of this page.<br />
<br />
Also note that there 4 different event categories:<br />
* Logging system related (CodeBlocksLogEvent)<br />
* View layout related (CodeBlocksLayoutEvent)<br />
* Docking system related (CodeBlocksDockEvent)<br />
* and everything else (CodeBlocksEvent)<br />
<br />
=== Subscribing to events ===<br />
Up until July 6th (2007), Code::Blocks events were handled like other wxWidgets events: by declaring an event table in your class that should handle them and adding relevant event table entries.<br />
<br />
But the event system changed radically on July 6th (2007), in order to battle some shortcomings of the wxWidgets event system (at least for our usage). While designing the new system, great attention has been paid so that plugin writers have to do minimum changes to convert their code.<br />
<br />
The class that handles all event registrations is the central class in Code::Blocks which you use if you want to do anything with the Code::Blocks SDK: <tt>Manager</tt>. Let's see by example how would a class (e.g. <tt>SomePlugin</tt>) subscribe for the cbEVT_EDITOR_SAVE event (fired when an editor's contents are saved):<br />
<br />
// assuming an existing member function:<br />
// void SomePlugin::OnEditorSaved(CodeBlocksEvent& event);<br />
<br />
Manager::Get()->RegisterEventSink(cbEVT_EDITOR_SAVE, new cbFunctorBase<SomePlugin, CodeBlocksEvent>(this, &SomePlugin::OnEditorSaved));<br />
<br />
Seems difficult? It isn't, if you realize what the second argument to <tt>Manager::RegisterEventSink</tt> does.<br />
<br />
<tt>cbEventFunctor</tt> is a class that encapsulates a this-pointer call. It is like a C function pointer except that it works with class instances (i.e. a member-function pointer).<br />
For obvious reasons it is a template class, taking two template arguments: the first is the class' name and the second is the type of the event the member function handles.<br />
<br />
The constructor of <tt>cbEventFunctor</tt> takes two arguments: first is the class instance (we use the <tt>this</tt> pointer) and the second is the address of the member function.<br />
<br />
And that's it. After using the above code, the defined function will be called-back on each editor saving :).<br />
<br />
<br />
<br />
'''Important note:''' For various reasons, cbEVT_PIPEDPROCESS* and cbEVT_THREADEDTASK* events should still be bound using the old way (i.e. by adding event table entries). If this is changed in the future, this article will be updated accordingly.<br />
<br />
<br />
<br />
=== Unsubscribing from events ===<br />
Usually there is no need to unsubscribe from event notifications. A plugin, for example, is automatically removed from all event notifications when it is detached (deactivated, unloaded, uninstalled).<br />
<br />
But if you really think you need to unsubscribe from events, there is a function to do that: <tt>Manager::Get()->RemoveAllEventSinksFor(void* owner)</tt>. As the sole argument, pass the instance that you registered the events in the first place.<br />
<br />
Notice that this function will remove ''all event notifications'' for the specified instance. There is no way to remove event notifications selectively. It's an all-or-nothing deal...<br />
<br />
<br />
=== When to register/unregister for event notifications? ===<br />
In plugins, event notifications should be registered in <tt>OnAttach()</tt>. As mentioned above, there is no need to unregister anything in <tt>OnDetach()</tt> because it is automatically done by Code::Blocks.<br />
<br />
For code other than plugins, register whenever you think is better (depends on the actual code).<br />
<br />
Also notice that Code::Blocks removes all registrations on shut down, so don't even think that we have memory leaks in that part ;).<br />
<br />
<br />
=== Any examples? ===<br />
If the example provided above is not enough, browse through the sources of the core/contrib Code::Blocks plugins. A few of them register for events: just search the code for <tt>RegisterEventSink</tt>.<br />
But it really is nothing difficult: just remove the event handlers from the class's event table and register with this new way.<br />
<br />
=== List of Available Code::Blocks Events ===<br />
<br />
==== Events that must be registered with RegisterEventSink ====<br />
''app events''<br />
* cbEVT_APP_STARTUP_DONE<br />
* cbEVT_APP_START_SHUTDOWN<br />
* <strike>cbEVT_APP_UPDATE_TITLE</strike> (removed)<br />
<br />
''plugin events'' (CodeBlocksEvent)<br />
* cbEVT_PLUGIN_ATTACHED<br />
* cbEVT_PLUGIN_RELEASED<br />
* cbEVT_PLUGIN_INSTALLED<br />
* cbEVT_PLUGIN_UNINSTALLED<br />
<br />
''editor events'' (CodeBlocksEvent)<br />
* cbEVT_EDITOR_CLOSE<br />
* cbEVT_EDITOR_OPEN<br />
* cbEVT_EDITOR_ACTIVATED<br />
* cbEVT_EDITOR_DEACTIVATED<br />
* cbEVT_EDITOR_SAVE<br />
* cbEVT_EDITOR_MODIFIED<br />
* cbEVT_EDITOR_TOOLTIP<br />
* cbEVT_EDITOR_TOOLTIP_CANCEL<br />
* cbEVT_EDITOR_BREAKPOINT_ADD<br />
* cbEVT_EDITOR_BREAKPOINT_EDIT<br />
* cbEVT_EDITOR_BREAKPOINT_DELETE<br />
* cbEVT_EDITOR_UPDATE_UI<br />
<br />
''project events'' (CodeBlocksEvent)<br />
* cbEVT_PROJECT_CLOSE<br />
* cbEVT_PROJECT_OPEN<br />
* cbEVT_PROJECT_SAVE<br />
* cbEVT_PROJECT_ACTIVATE<br />
* cbEVT_PROJECT_BEGIN_ADD_FILES<br />
* cbEVT_PROJECT_END_ADD_FILES<br />
* cbEVT_PROJECT_BEGIN_REMOVE_FILES<br />
* cbEVT_PROJECT_END_REMOVE_FILES<br />
* cbEVT_PROJECT_FILE_ADDED<br />
* cbEVT_PROJECT_FILE_REMOVED<br />
* cbEVT_PROJECT_POPUP_MENU<br />
* cbEVT_PROJECT_TARGETS_MODIFIED<br />
* cbEVT_PROJECT_RENAMED<br />
* cbEVT_WORKSPACE_CHANGED<br />
<br />
''main menubar creation'' (CodeBlocksEvent)<br />
* cbEVT_MENUBAR_CREATE_BEGIN: app notifies that the menubar is started being (re)created<br />
* cbEVT_MENUBAR_CREATE_END: app notifies that the menubar (re)creation ended<br />
<br />
''compiler-related events'' (CodeBlocksEvent)<br />
* cbEVT_COMPILER_STARTED<br />
* cbEVT_COMPILER_FINISHED<br />
<br />
''debugger-related events'' (CodeBlocksEvent)<br />
* cbEVT_DEBUGGER_STARTED<br />
* cbEVT_DEBUGGER_PAUSED<br />
* cbEVT_DEBUGGER_FINISHED<br />
<br />
''logging-system related events'' (CodeBlocksLogEvent)<br />
* cbEVT_ADD_LOG_WINDOW: add a log window<br />
* cbEVT_REMOVE_LOG_WINDOW: remove a log window<br />
* cbEVT_SWITCH_TO_LOG_WINDOW: switch to a log window (make it visible)<br />
* cbEVT_SHOW_LOG_MANAGER: show log manager<br />
* cbEVT_HIDE_LOG_MANAGER: hide log manager<br />
* cbEVT_LOCK_LOG_MANAGER: "lock" it (used with auto-hiding functionality)<br />
* cbEVT_UNLOCK_LOG_MANAGER: "unlock" it (used with auto-hiding functionality)<br />
<br />
<br />
''dockable windows'' (CodeBlocksDockEvent)<br />
* cbEVT_ADD_DOCK_WINDOW: request app to add and manage a docked window<br />
* cbEVT_REMOVE_DOCK_WINDOW: request app to stop managing a docked window<br />
* cbEVT_SHOW_DOCK_WINDOW: request app to show a docked window<br />
* cbEVT_HIDE_DOCK_WINDOW: request app to hide a docked window<br />
* cbEVT_DOCK_WINDOW_VISIBILITY: app notifies that a docked window has been hidden/shown to actually find out its state use IsWindowReallyShown(event.pWindow);<br />
<br />
''layout related events'' (CodeBlocksLayoutEvent)<br />
* cbEVT_SWITCH_VIEW_LAYOUT: request app to switch view layout<br />
* cbEVT_SWITCHED_VIEW_LAYOUT: app notifies that a new layout has been applied<br />
<br />
==== Events processed on wxWidgets event tables and '''not''' registered using RegisterEventSink ====<br />
''pipedprocess events'' (CodeBlocksEvent)<br />
* cbEVT_PIPEDPROCESS_STDOUT<br />
* cbEVT_PIPEDPROCESS_STDERR<br />
* cbEVT_PIPEDPROCESS_TERMINATED<br />
<br />
''thread-pool events'' (CodeBlocksEvent)<br />
* cbEVT_THREADTASK_STARTED<br />
* cbEVT_THREADTASK_ENDED<br />
* cbEVT_THREADTASK_ALLDONE<br />
<br />
<br />
[[User:Mandrav|Mandrav]] 10:31, 23 November 2007 (UTC)</div>XayChttps://wiki.codeblocks.org/index.php?title=Creating_a_simple_%22Hello_World%22_plugin&diff=5070Creating a simple "Hello World" plugin2007-12-03T15:27:45Z<p>XayC: /* Adding Functionality */</p>
<hr />
<div>[[Category:Plugin development]]<br />
[[Category:Outdated]]<br />
{{outdated}}<br />
'''NOTE''': This tutorial was written using the Code::Blocks final beta under windows.<br />
<br />
==Prerequisites==<br />
<br />
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 <br />
[[Compiling wxWidgets 2.6.2 to develop Code::Blocks (MSW)|Compiling wxWidgets 2.6.2 to develop Code::Blocks]]<br />
<br />
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.<br />
<br />
==Overview==<br />
<br />
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.<br />
<br />
==Creating the Plugin Project==<br />
<br />
Select the '''File->New->Project''' option from the main menu bar and choose the Code::Blocks Plugin Wizard. You will see a dialog box with some information but you can skip that after reading it. Now you will see the following dialog box:<br />
<br />
[[Image:Plugindevelop_2.jpg]]<br />
<br />
In the first edit field write the title of your project. You can see that we denoted the project title as '''HelloWordPlugin'''. The other field are self-explanatory. If you click the Next button you will see the next plugin property dialog:<br />
<br />
[[Image:Plugindevelop_3.jpg]]<br />
<br />
Let's denote the plugin name with '''HelloWorld'''. After clicking the next button a new dialog apears and you can edit a bunch of information about your plugin. In the next step you can choose which compiler you want to use for your plugin project.<br />
<br />
===Plugin Type===<br />
<br />
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.<br />
<br />
===Plugin Info===<br />
<br />
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.<br />
<br />
===Provides Configuration Dialog===<br />
<br />
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.<br />
<br />
===Filenames===<br />
<br />
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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Letting the project know where to find the SDK==<br />
<br />
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).<br />
<br />
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'').<br />
<br />
===Linker Options===<br />
<br />
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'').<br />
<br />
===Compiler Options===<br />
<br />
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).<br />
<br />
==Adding Functionality==<br />
<br />
The plugin wizard should have generated us helloworldplugin.h and helloworldplugin.cpp. The header file contains the class definition; what we're interested in, however, is the definition of the class methods in helloworldplugin.cpp. The plugin wizard has generated a constructor, a destructor 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.<br />
<br />
The ''Execute'' method, as mentioned earlier, is what we are really interested in. We are going to use the ''LogManager'' 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 LogManager 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 LogManager and EditorManager - which is used to keep track of all the open files and their editors). LogManager is responsible for both normal output and debugging output (see ''logmanager.h'' for more details). Replace the generated Execute method with this new one:<br />
<br />
int HelloWorldPlugin::Execute()<br />
{<br />
if( !IsAttached() )<br />
return -1;<br />
Manager::Get()->GetLogManager()->Log( _("Hello World!") );<br />
return 0;<br />
}<br />
<br />
This new method uses the Manager's static Get method to return the singleton Manager object, then uses that to access the LogManager through the GetLogManager method. LogManager 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].<br />
<br />
The first two lines check to see if the plugin has been attatched (in other words selected by the user in the '''Plugins->Manage plugins''' menu), and thus whether it should perform any action at all. Currently the return value of Execute is not used anywhere, but all the default plugins use -1 for failure and 0 for success.<br />
<br />
==Compile! (And test)==<br />
<br />
(New)<br />
The time is right and we should compile the project. The next step is to install the plugin. Go to the '''Plugins->Manage plugins''' option. Hit the '''Install new''' button. The manager ask you where the plugin lies. Go to that folder and select the *.cbplugin file. Code::Blocks imports your plugin automatically. If this procedure was successful you can see your plugin in the ''Installed plugins'' list. To execute your plugin go to the '''Plugins''' menu and choose your plugin. That's all.<br />
<br />
(Old)<br />
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!<br />
<br />
==Further Information==<br />
<br />
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]. <br />
<br />
Hopefully this tutorial has helped you work through a few fundamentals in terms of creating plugins, happy coding!</div>XayChttps://wiki.codeblocks.org/index.php?title=Creating_a_simple_%22Hello_World%22_plugin&diff=5069Creating a simple "Hello World" plugin2007-12-03T15:22:14Z<p>XayC: Updated section 'Adding Functionality' removing references to the old MessageManager.</p>
<hr />
<div>[[Category:Plugin development]]<br />
[[Category:Outdated]]<br />
{{outdated}}<br />
'''NOTE''': This tutorial was written using the Code::Blocks final beta under windows.<br />
<br />
==Prerequisites==<br />
<br />
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 <br />
[[Compiling wxWidgets 2.6.2 to develop Code::Blocks (MSW)|Compiling wxWidgets 2.6.2 to develop Code::Blocks]]<br />
<br />
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.<br />
<br />
==Overview==<br />
<br />
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.<br />
<br />
==Creating the Plugin Project==<br />
<br />
Select the '''File->New->Project''' option from the main menu bar and choose the Code::Blocks Plugin Wizard. You will see a dialog box with some information but you can skip that after reading it. Now you will see the following dialog box:<br />
<br />
[[Image:Plugindevelop_2.jpg]]<br />
<br />
In the first edit field write the title of your project. You can see that we denoted the project title as '''HelloWordPlugin'''. The other field are self-explanatory. If you click the Next button you will see the next plugin property dialog:<br />
<br />
[[Image:Plugindevelop_3.jpg]]<br />
<br />
Let's denote the plugin name with '''HelloWorld'''. After clicking the next button a new dialog apears and you can edit a bunch of information about your plugin. In the next step you can choose which compiler you want to use for your plugin project.<br />
<br />
===Plugin Type===<br />
<br />
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.<br />
<br />
===Plugin Info===<br />
<br />
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.<br />
<br />
===Provides Configuration Dialog===<br />
<br />
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.<br />
<br />
===Filenames===<br />
<br />
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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Letting the project know where to find the SDK==<br />
<br />
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).<br />
<br />
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'').<br />
<br />
===Linker Options===<br />
<br />
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'').<br />
<br />
===Compiler Options===<br />
<br />
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).<br />
<br />
==Adding Functionality==<br />
<br />
The plugin wizard should have generated us helloworldplugin.h and helloworldplugin.cpp. The header file contains the class definition; what we're interested in, however, is the definition of the class methods in helloworldplugin.cpp. The plugin wizard has genarated a constructor, a destructor 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.<br />
<br />
The ''Execute'' method, as mentioned earlier, is what we are really interested in. We are going to use the ''LogManager'' 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 LogManager 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 LogManager and EditorManager - which is used to keep track of all the open files and their editors). LogManager is responsible for both normal output and debugging output (see ''logmanager.h'' for more details). Replace the generated Execute method with this new one:<br />
<br />
int HelloWorldPlugin::Execute()<br />
{<br />
if( !IsAttached() )<br />
return -1;<br />
Manager::Get()->GetLogManager()->Log( _("Hello World!") );<br />
return 0;<br />
}<br />
<br />
This new method uses the Manager's static Get method to return the singleton Manager object, then uses that to access the LogManager through the GetLogManager method. LogManager 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].<br />
<br />
The first two lines check to see if the plugin has been attatched (in other words selected by the user in the '''Plugins->Manage plugins''' menu), and thus whether it should perform any action at all. Currently the return value of Execute is not used anywhere, but all the default plugins use -1 for failure and 0 for success.<br />
<br />
==Compile! (And test)==<br />
<br />
(New)<br />
The time is right and we should compile the project. The next step is to install the plugin. Go to the '''Plugins->Manage plugins''' option. Hit the '''Install new''' button. The manager ask you where the plugin lies. Go to that folder and select the *.cbplugin file. Code::Blocks imports your plugin automatically. If this procedure was successful you can see your plugin in the ''Installed plugins'' list. To execute your plugin go to the '''Plugins''' menu and choose your plugin. That's all.<br />
<br />
(Old)<br />
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!<br />
<br />
==Further Information==<br />
<br />
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]. <br />
<br />
Hopefully this tutorial has helped you work through a few fundamentals in terms of creating plugins, happy coding!</div>XayC