https://wiki.codeblocks.org/api.php?action=feedcontributions&user=Byo&feedformat=atomCode::Blocks - User contributions [en]2024-03-28T16:19:52ZUser contributionsMediaWiki 1.35.0https://wiki.codeblocks.org/index.php?title=WxSmith_tutorial:_Creating_items_with_custom_paint_and_mouse_handling&diff=5531WxSmith tutorial: Creating items with custom paint and mouse handling2008-06-27T20:12:32Z<p>Byo: New page: = Warning: unfinished = Welcome back :) We've already learned nice techniques of working with wxSmith in previous tutorial and now it's time for something even better. Usually when writin...</p>
<hr />
<div>= Warning: unfinished =<br />
<br />
Welcome back :) We've already learned nice techniques of working with wxSmith in previous tutorial and now it's time for something even better. Usually when writing some more advanced application, it turns out that none of items provided by wxWidgets fits our purposes, especially when we need to present some data in graphical form. Hopefully as almost all GUI tolkits, wxWidgets is also prepared for this and gives us possibility to create item with custom drawing and mouse handling - this allows us to create any item we like.<br />
<br />
= Creating item with custom paint procedure =<br />
<br />
Before we start creating our customized item, some background knowledge is needed.<br />
First thing you should know is how wxWidgets draws items.<br />
<br />
Most of items have custom paint procedures provided by operating system or some other toolkit available in system (like gtk+). In case of such items, when OS posts request to repaint item, either such message is forwarded by wxWidgets back into system or even the whole procedure is done without any wxWidgets' intervention. Unfortunately this means that we can not replace paint procedure in case of all items and even if it would work on some platforms, it won't on others. From items available in wxSmith, only wxPanel is guaranteed to work with custom paint procedure.<br />
<br />
Now if we overwrite painting on wxPanel, wxWidgets will post two events on each paint request:<br />
* erase background event (EVT_ERASE_BACKGROUND)<br />
* paint event (EVT_PAINT)<br />
<br />
First one is used to prepare area occupied by our item before adding content and the second one is used to do actual drawing. We don't have to override both events so we can only draw custom background or custom content leaving background as default one.<br />
<br />
<br />
Second thing you should know before writing custom paint method is that wxWidgets uses wxDC objects to draw. In case of erase background event, this object is provided within event, in case of paint event, we must create such object manually. To get more informations about wxDC and drawing functions, take look at [http://docs.wxwidgets.org/stable/wx_wxdc.html#wxdc this page in wxWidgets documentation].<br />
<br />
= Creating simple resource and overriding paint method =<br />
<br />
Now let's create some simple window. For our purposes we need some wxPanel inside the window which we will work on:<br />
<br />
[[Image:wxs_tut07_001.png]]<br />
<br />
Now let's go to event's tab in properties browser. You may see that wxPanel can process much more events than other items. That's because it can be use as base for custom items which may have custom handler for any standard event. Ok, let's find EVT_PAINT method (sohuld be at the top) and add new empty event.<br />
<br />
The first thing we should do inside the handler is to create wxDC object we will use. If you look at wxWidgets documentation you may read that not doing so causes wxWidgets to go into infinite loop because paint method will be recalled over and over again.<br />
<br />
There are few types of wxDC objects we could use here. The most commonly used is wxPaintDC:<br />
<br />
void Tutorial7Dialog::OnPanel1Paint(wxPaintEvent& event)<br />
{<br />
'''wxPaintDC dc( Panel1 );'''<br />
}<br />
<br />
You can see that we passed panel's pointer as argument - wxPaintDC require pointer to item we will draw on on it's constructor. Remember not to use ''this'' opinter.<br />
<br />
Now let's add some drawing code - just some diagonal line to test whether drawing does work:<br />
<br />
void Tutorial7Dialog::OnPanel1Paint(wxPaintEvent& event)<br />
{<br />
wxPaintDC dc( Panel1 );<br />
'''dc.DrawLine( 0, 0, 100, 100 );'''<br />
}<br />
<br />
Now if we run our aplication, the window will look like this:<br />
<br />
[[Image:wxs_tut07_002.png]]</div>Byohttps://wiki.codeblocks.org/index.php?title=WxSmith_tutorials&diff=5530WxSmith tutorials2008-06-27T18:37:47Z<p>Byo: /* wxSmith and wxWidgets basics */</p>
<hr />
<div>[[Category:wxSmith Documentation]]<br />
<br />
Welcome to wxSmith tutorials page. Here you can learn how to create GUI applications for wxWidgets platform using wxSmith. At the beginning we will start with some basic tutorials which will show what can you do with wxSmith and how you can create simple applications. I hope that there will also be some advanced tutorials for those who know wxWidgets very well.<br />
<br />
=== wxSmith and wxWidgets basics ===<br />
<br />
On this tutorials you will learn basic things about wxSmith and wxWidgets.<br />
<br />
* Tutorial 1: [[wxSmith tutorial: Hello world|Hello world]]<br />
* Tutorial 2: [[wxsmith tutorial: Working with items|Working with items]]<br />
* Tutorial 3: [[wxSmith tutorial: Building more complex window|Building more complex window]]<br />
* Tutorial 4: [[wxSmith tutorial: Working with multiple resources|Working with multiple resources]]<br />
* Tutorial 5: [[wxSmith tutorial: Using wxPanel resources|Using wxPanel resources]]<br />
* Tutorial 6: [[wxSmith tutorial: Accessing items in resource|Accessing items in resource]]<br />
* Tutodial 7: [[wxSmith tutorial: Creating items with custom paint and mouse handling]]</div>Byohttps://wiki.codeblocks.org/index.php?title=File:Wxs_tut05_009.png&diff=5529File:Wxs tut05 009.png2008-06-25T20:53:36Z<p>Byo: </p>
<hr />
<div></div>Byohttps://wiki.codeblocks.org/index.php?title=File:Wxs_tut05_008.png&diff=5528File:Wxs tut05 008.png2008-06-25T20:53:16Z<p>Byo: </p>
<hr />
<div></div>Byohttps://wiki.codeblocks.org/index.php?title=File:Wxs_tut05_007.png&diff=5527File:Wxs tut05 007.png2008-06-25T20:52:34Z<p>Byo: </p>
<hr />
<div></div>Byohttps://wiki.codeblocks.org/index.php?title=WxSmith_tutorial:_Using_wxPanel_resources&diff=5526WxSmith tutorial: Using wxPanel resources2008-06-25T20:52:06Z<p>Byo: </p>
<hr />
<div>[[Category:wxSmith Documentation]]<br />
<br />
= Using wxPanel resources =<br />
<br />
In some cases, one resource must be splitted into few smaller parts. Such split gives few advantages: it helps working more people on same project, it may give you cleaner view over really complex resources and it may help to divide source code for logical parts in case of few functionalities in one window. In this tutorial I'll show you how to create such resources.<br />
<br />
== Creating our playground ==<br />
<br />
wxPanel resources can not live as independent items - they must be placed inside frame or dialog. We can use main resource created inside wizard. Assuming that you've read previous tutorials, creating simple window shouldn't be a big problem for you :).<br />
<br />
Let's start with something like this:<br />
<br />
[[Image:wxs_tut05_001.png]]<br />
<br />
== Adding wxPanel using "Custom" item ==<br />
<br />
In this tutorial I'll show you two methds of embedding external wxPanel inside another resource.<br />
First one use "Custom" item which can be used to any kind of resource not know to wxSmith.<br />
<br />
So let's create wxPanel resource. Note that used embedding method will affect initial configuration of resource.<br />
We want id, size and position of our panel to be controlled by parent resource so make sure that we add them into panel's constructor:<br />
<br />
[[Image:wxs_tut05_002.png]]<br />
<br />
Now let's add some content into panel:<br />
<br />
[[Image:wxs_tut05_003.png]]<br />
<br />
Final step is to add "Custom" item into main window and configure it properly. Custom icon is the last one in the "Standard palete" identified by this icon:<br />
<br />
[[Image:wxs_tut05_004.png]]<br />
<br />
New item will be shown as black square with three question marks on the top. Let's resize it a little bit:<br />
<br />
[[Image:wxs_tut05_005.png]]<br />
<br />
Now we need to adjust custom item's properties. <br />
<br />
First thing we will adjust is "Creating code" property. As the name says, here we will be able to adjust the way wxSmith adds code responsible for creating this item. The default value is:<br />
<br />
$(THIS) = new $(CLASS)($(PARENT),$(ID),$(POS),$(SIZE),$(STYLE),wxDefaultValidator,$(NAME));<br />
<br />
You may find that there are some macros used. They are here to help you map other properties of this item into ceating code:<br />
* $(THIS) is replaced by name of variable for this item<br />
* $(CLASS) is replaced by name of item's class<br />
* $(PARENT) is replaced by name of parent item (it's granted that it will be a pointer to class derived from wxWindow)<br />
* $(ID) is replaced by value of Id property<br />
* $(POS) is replaced by value of position property (it may be adjusted by using drag boxes)<br />
* $(SIZE) is replaced by value of size property (it may be adjusted by using drag boxes)<br />
* $(STYLE) is replaced by style property - since custom item doesn't have predefined set of styles, it's threated as normal string<br />
* $(NAME) is replaced by generated name (which is equivalent to string representation of item's identifier)<br />
<br />
The default code template creates standard item which uses default set of properties. Let's replace it by value corresponding to our panel's constructor:<br />
<br />
$(THIS) = new $(CLASS)($(PARENT),$(ID),$(POS),$(SIZE));<br />
<br />
Now we have to give name of header file with our external resource in the "Include file" property. I've created wxPanel with name "InterlanPanel" so header will be "InternalPanel.h". Also let's check the "Use "" for include..." since we're including local file.<br />
<br />
The last property to adjust is the "Class name" - we need to put name of our panel here, in my case it's "InternalPanel". When we do this, our embedded resource is ready:<br />
<br />
[[Image:wxs_tut05_006.png]]<br />
<br />
== Adding custom panel through standard wxPanel ==<br />
<br />
Secend way in which external resource may be used is through normal wxPanel.<br />
If you look closer, you'll find that most of items have property called "Class name" - this is the name of class which will be used as item's type. Bu default it contains name of original class in wxWidgets. Changing it will notify that different class will be used instead.<br />
<br />
So to put our own panel here we can add "normal" panel into main resource and change class name to name of our internal resource. So far it's easy but there's one requirement to this technique - our internal resource must have exactly the same constructor arguments as in case of "original" class.<br />
<br />
So let's take a look at the wxWidgets documentation and here's declaration of wxPanel's constructor:<br />
<br />
wxPanel( wxWindow* parent, wxWindowID id = wxID_ANY, <br />
const wxPoint& pos = wxDefaultPosition, const wxSize& size = wxDefaultSize, <br />
long style = wxTAB_TRAVERSAL, const wxString& name = "panel")<br />
<br />
Now let's create our own internal resource. We will have to adjust constructor arguments as in case of previous method:<br />
<br />
[[Image:wxs_tut05_007.png]]<br />
<br />
Note that I've added custom arguments and turned off all default values (it's required since we can not easily add default values of our custom args).<br />
<br />
Now that our panel is ready we can add it to main resource - let's add "normal" panel first:<br />
<br />
[[Image:wxs_tut05_008.png]]<br />
<br />
and change "Class name" property to name of our resource (in my case it's InternalResource2).<br />
<br />
We still need to add #include "InternalResource2.h" into sources to make our project compile. In previous solution it was done automaticaly through properties. Now we don't have such system so let's add it manually (remember to put our include outside wxSmith's code section, otherwise any change in resource will remove our change). Note that we need to add it to header file of main resource:<br />
<br />
//(*Headers(Tutorial5Dialog)<br />
#include <wx/sizer.h><br />
#include <wx/panel.h><br />
#include "InternalPanel.h"<br />
#include <wx/dialog.h><br />
//*)<br />
'''#include "InternalResource2.h"'''<br />
<br />
Now we can run our application:<br />
<br />
[[Image:wxs_tut05_009.png]]<br />
<br />
<br />
<br />
<br />
<br />
I've presented two easiest methods of creating complex window from smaller resources. Perhaps you could find other ways to do it (if you do so, you can extend this tutorial :) ). On wxSmith's wishlist there's also nice feature request to allow adding external panels int more natural way (just by few clicks) which will probably make other methods obsolete. But I hope that I gave you enough informations to build nice compound resources so far :)</div>Byohttps://wiki.codeblocks.org/index.php?title=File:Wxs_tut05_004.png&diff=5525File:Wxs tut05 004.png2008-06-19T21:21:29Z<p>Byo: </p>
<hr />
<div></div>Byohttps://wiki.codeblocks.org/index.php?title=File:Wxs_tut05_006.png&diff=5524File:Wxs tut05 006.png2008-06-19T21:20:04Z<p>Byo: </p>
<hr />
<div></div>Byohttps://wiki.codeblocks.org/index.php?title=File:Wxs_tut05_005.png&diff=5523File:Wxs tut05 005.png2008-06-19T21:19:49Z<p>Byo: </p>
<hr />
<div></div>Byohttps://wiki.codeblocks.org/index.php?title=File:Wxs_tut05_003.png&diff=5522File:Wxs tut05 003.png2008-06-19T21:19:10Z<p>Byo: </p>
<hr />
<div></div>Byohttps://wiki.codeblocks.org/index.php?title=File:Wxs_tut05_002.png&diff=5521File:Wxs tut05 002.png2008-06-19T21:18:38Z<p>Byo: </p>
<hr />
<div></div>Byohttps://wiki.codeblocks.org/index.php?title=File:Wxs_tut05_001.png&diff=5520File:Wxs tut05 001.png2008-06-19T21:17:19Z<p>Byo: </p>
<hr />
<div></div>Byohttps://wiki.codeblocks.org/index.php?title=WxSmith_tutorial:_Using_wxPanel_resources&diff=5519WxSmith tutorial: Using wxPanel resources2008-06-19T21:16:48Z<p>Byo: Written first part</p>
<hr />
<div>[[Category:wxSmith Documentation]]<br />
<br />
= Warning: Unfinished =<br />
<br />
= Using wxPanel resources =<br />
<br />
In some cases, one resource must be splitted into few smaller parts. Such split gives few advantages: it helps working more people on same project, it may give you cleaner view over really complex resources and it may help to divide source code for logical parts in case of few functionalities in one window. In this tutorial I'll show you how to create such resources.<br />
<br />
== Creating our playground ==<br />
<br />
wxPanel resources can not live as independent items - they must be placed inside frame or dialog. We can use main resource created inside wizard. Assuming that you've read previous tutorials, creating simple window shouldn't be a big problem for you :).<br />
<br />
Let's start with something like this:<br />
<br />
[[Image:wxs_tut05_001.png]]<br />
<br />
== Adding wxPanel using "Custom" item ==<br />
<br />
In this tutorial I'll show you two methds of embedding external wxPanel inside another resource.<br />
First one use "Custom" item which can be used to any kind of resource not know to wxSmith.<br />
<br />
So let's create wxPanel resource. Note that used embedding method will affect initial configuration of resource.<br />
We want id, size and position of our panel to be controlled by parent resource so make sure that we add them into panel's constructor:<br />
<br />
[[Image:wxs_tut05_002.png]]<br />
<br />
Now let's add some content into panel:<br />
<br />
[[Image:wxs_tut05_003.png]]<br />
<br />
Final step is to add "Custom" item into main window and configure it properly. Custom icon is the last one in the "Standard palete" identified by this icon:<br />
<br />
[[Image:wxs_tut05_004.png]]<br />
<br />
New item will be shown as black square with three question marks on the top. Let's resize it a little bit:<br />
<br />
[[Image:wxs_tut05_005.png]]<br />
<br />
Now we need to adjust custom item's properties. <br />
<br />
First thing we will adjust is "Creating code" property. As the name says, here we will be able to adjust the way wxSmith adds code responsible for creating this item. The default value is:<br />
<br />
$(THIS) = new $(CLASS)($(PARENT),$(ID),$(POS),$(SIZE),$(STYLE),wxDefaultValidator,$(NAME));<br />
<br />
You may find that there are some macros used. They are here to help you map other properties of this item into ceating code:<br />
* $(THIS) is replaced by name of variable for this item<br />
* $(CLASS) is replaced by name of item's class<br />
* $(PARENT) is replaced by name of parent item (it's granted that it will be a pointer to class derived from wxWindow)<br />
* $(ID) is replaced by value of Id property<br />
* $(POS) is replaced by value of position property (it may be adjusted by using drag boxes)<br />
* $(SIZE) is replaced by value of size property (it may be adjusted by using drag boxes)<br />
* $(STYLE) is replaced by style property - since custom item doesn't have predefined set of styles, it's threated as normal string<br />
* $(NAME) is replaced by generated name (which is equivalent to string representation of item's identifier)<br />
<br />
The default code template creates standard item which uses default set of properties. Let's replace it by value corresponding to our panel's constructor:<br />
<br />
$(THIS) = new $(CLASS)($(PARENT),$(ID),$(POS),$(SIZE));<br />
<br />
Now we have to give name of header file with our external resource in the "Include file" property. I've created wxPanel with name "InterlanPanel" so header will be "InternalPanel.h". Also let's check the "Use "" for include..." since we're including local file.<br />
<br />
The last property to adjust is the "Class name" - we need to put name of our panel here, in my case it's "InternalPanel". When we do this, our embedded resource is ready:<br />
<br />
[[Image:wxs_tut05_006.png]]</div>Byohttps://wiki.codeblocks.org/index.php?title=Lib_finder_Timeline&diff=5482Lib finder Timeline2008-03-28T19:41:32Z<p>Byo: </p>
<hr />
<div>Timeline for lib_finder:<br />
<br />
{| 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;"<br />
|- style="background: #ececec;"<br />
! style="width: 15em" | Task<br />
! Description<br />
! style="width: 7em" | Estimated time<br />
! style="width: 5em" | Finished<br />
|-<br />
! Predefined libraries<br />
| style="text-align: left;" | Currently lib_finder allow to search for libraries and search filters can be defined in configuration files. But if someone provides library which is already set-up and this information in sure and constant, it should also be able to provide final library configuration using simillar scheme to search filters. Additionally, such library settings could give possibility to store dorectories relatively to code::blocks' directory which will allow to build some portable usb-drive C::B<br />
| 1 day<br />
| {{yes}}<br />
|-<br />
! Support for multiple configuration directories<br />
| style="text-align: left;" | Library search filters are stored in xml files located in some settings directory. Currently only one directory is scanned when those files are loaded. But it's known that on some systems (f.ex. unix) there may be more than one directory with data. A set of directories should be read, not only one.<br />
| 1 hour<br />
| {{yes}}<br />
|-<br />
! Library synonymes<br />
| style="text-align: left;" | Each library sould be accessible using more than one name. This could be usefull because even now there are different names for libraries when using lib_finder settings and pkg-config ones. <br />
| 1 day<br />
| {{no}}<br />
|-<br />
! Type of library result<br />
| style="text-align: left;" | Structure LibraryResult should have extra field called type which would be: pkg-config, predefined or detected. By providing type, all results, no matter whether stored or detected from pkg-config could use one structure. That would greatly ease things in future when other possible sources would be added<br />
| 1 day<br />
| {{yes}}<br />
|-<br />
! Edition of library results<br />
| style="text-align: left;" | There should be ability to view all known libraries and edit detected ones. That could help finding mistakes etc. It could also be usefull to set order of libraries.<br />
| 1 day<br />
| {{yes}}<br />
|-<br />
! Detection of used libraries<br />
| style="text-align: left;" | By scanning #include lines it should be easy to detect what libraries should be included with project to compile it without problems. It could be also added into HeaderFixup plugin (available using through scripting or something)<br />
| 2 days<br />
| {{no}}<br />
|-<br />
! Separate configuration for build targets<br />
| style="text-align: left;" | Each build target should have it's own set of libraries and there should be one global set of libraries.<br />
| 1 day<br />
| {{no}}<br />
|-<br />
! Library version support<br />
| style="text-align: left;" | When declaring that project use library, it should be possible to set some version filters (and other kinds of filters)<br />
| 1 week<br />
| {{no}}<br />
|-<br />
! Search results priorities<br />
| style="text-align: left;" | Search results should have priorities. Pkg-config libraries would have the lowest priority, next would be predefined results, detected libraries could have any priority declared in detection filter files. That would help finding better results.<br />
| 1 week<br />
| {{no}}<br />
|-<br />
! Set custom variables when detecting libs<br />
| style="text-align: left;" | There could be some extra option which would set value of variable, it shouldn't be possible only from path<br />
| 1 hour<br />
| {{no}}<br />
|-<br />
! Integration with scripting system<br />
| style="text-align: left;" | Some procedures (like adding library to project) should be availble in scripting system. That would allow to use lib_finder in project wizards and invoke it from other plugins.<br />
| 1 hour<br />
| {{yes}}<br />
|-<br />
! Background search<br />
| style="text-align: left;" | Searching for libraries could be done on separate thread with possibility to unfreeze the IDE wile searching.<br />
| 1 hour<br />
| {{no}}<br />
|-|}</div>Byohttps://wiki.codeblocks.org/index.php?title=Code::Completion_Rewrite&diff=5408Code::Completion Rewrite2008-03-12T08:01:23Z<p>Byo: /* 6. Advanced template argument deduction */</p>
<hr />
<div>== Background ==<br />
The current Code::Completion plug-in has some flaws, and is currently development frozen.<br />
The current plug-in lacks full support for:<br />
# function and class templates<br />
# default arguments in some cases<br />
# some of the more complicated c++ mucky business<br />
<br />
== Current Effort ==<br />
=== Structure ===<br />
The current C::C is a monolithic library of features, which could be de-coupled and split up for use in multiple plugins, providing extra functionality and flexibility in the future.<br />
Therefore, I propose the C::C be broken up into the following components:<br />
<br />
* Code::SymbolTable<br />
** Provide a list of valid symbols in the workspace, along with relevant scope information<br />
* Code::Completion<br />
** Provide Auto-complete features<br />
* Code::SymbolOutline<br />
** Provide Symbol browser, find symbol, function jump features<br />
* Code::Refactoring<br />
** Provide code refactoring features<br />
* Code::Documentation<br />
** Provide automatic code generation features<br />
<br />
=== Code::Completion ===<br />
==== Purpose Statement ====<br />
The current Code::Completion plugin is outdated, and needs a complete rewrite.<br />
The purpose of the Code::Completion plugin is thus:<br />
<br />
* Provide a list of likely symbols in the current scope as possible solutions to the current symbol.<br />
* Provide function tooltips<br />
** Parameter list<br />
** Relevant documentation<br />
* Provide completion features for class constructors<br />
* Provide completion features for initializer lists<br />
<br />
==== Process ====<br />
# Generate a list of all valid symbols in the current scope<br />
## Take global list from C::SymbolTable<br />
## Add in local scope parsed on the fly<br />
# Reduce that list to what is likely<br />
# Show that list to the user in some fashion<br />
# Insert the proper solution on user request<br />
=== Code::SymbolTable ===<br />
There will be 3 symbol lists:<br />
# global namespace<br />
# local scope<br />
# class scope<br />
<br />
Here's the current data proposal:<br />
<br />
class symbol<br />
{<br />
string name; // name of the symbol<br />
int id; // Id of the symbol, should be unique in the workspace<br />
int file_id; // Id of file where the symbol has been declared<br />
int filepos_begin; // Position where declaration of the symbol starts<br />
int filepos_end; // Position where declaration of the symbol ends<br />
int type; // Type of the symbol: macro / class / typedef / variable / function<br />
flags modifiers; // Bitfield used to mark some estra properties of symbol<br />
// like that it is static or inline<br />
int value_type_id; // Id of symbol which represents c++ type of current symbol<br />
// (like type of variable or type of returned value from function)<br />
int extra_type_id; // Extra type used in some cases<br />
list children; // List of child elements of this symbol (members in class etc)<br />
list extra_lists[3]; // See table below<br />
map extra_values; // int -> string map which can keep some extra data<br />
}<br />
<br />
class list_entry<br />
{<br />
int symbol_id; // ID of the symbol referenced<br />
int storage_class; // Storage class of the symbol (private/protected/public)<br />
}<br />
<br />
Explanation of symbol::extra_lists[]<br />
{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"<br />
|- style="background: #ececec; border: 1px solid gray;"<br />
! type<br />
! modifiers<br />
! value_type_id<br />
! extra_type<br />
! children<br />
! extra_lists[0]<br />
! extra_lists[1]<br />
! extra_lists[2]<br />
|-<br />
<br />
|-<br />
| namespace<br />
|<br />
|<br />
|<br />
| declarations in namespace<br />
|"using" namespaces<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| class / struct / union<br />
|<br />
|<br />
|<br />
| members of class<br />
| base classes<br />
| template args<br />
| friends of class<br />
|-<br />
<br />
|-<br />
| variable<br />
| extern, static, volatile, const<br />
| type of variable<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| function<br />
| static, inline, const ...<br />
| returned value<br />
|<br />
| arguments<br />
| template arguments<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| typedef<br />
| pointer, array, reference, pointer_to_member<br />
| base type<br />
| type of class in pointer_to_member<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| enum<br />
|<br />
|<br />
|<br />
| items in enum<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| enum item<br />
|<br />
|<br />
| id of enum<br />
| <br />
| <br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| macro<br />
|<br />
|<br />
|<br />
| macro parts<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| macro part<br />
| arg_to_string, va_args<br />
| number of arg or -1<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|}<br />
<br />
Comments:<br />
* Such representation would require some extra "hidden" symbols - for example when some complex type is returned from function, extra symbol of typedef representing proper value would be required.<br />
* Also in case of templates, typeid's should be threated in special way - negative value could mean to use template argument instead of some real type. Base types (the POD ones) should have some predefined type ids.<br />
<br />
Questions:<br />
* why are we storing filepos_end? Wouldn't it be much more useful to store declaration, definition info?<br />
<br />
== More complex cases of C::C usage ==<br />
<br />
Here we can put some more complex examples of c++ code where C::C may fail. Symbols that may be hard to find should be marked in bold<br />
<br />
=== 1: Fetching type of operator call ===<br />
<br />
#include <string><br />
using namespace std;<br />
<br />
int main(int,char**)<br />
{<br />
( string("first") + "second" + "third" ) . '''c_str'''();<br />
return 0;<br />
}<br />
<br />
=== 2: Template classes ===<br />
<br />
template<typename T> class Template<br />
{<br />
public:<br />
T& GetInstance() { return m_Instance; }<br />
private:<br />
T m_Instance;<br />
};<br />
<br />
class Parameter<br />
{<br />
public:<br />
void PrintfText() { printf("Text"); }<br />
};<br />
<br />
int main(int,char**)<br />
{<br />
Template<Parameter> Object;<br />
Object.GetInstance().'''PrintfText'''();<br />
}<br />
<br />
=== 3: Automated deduction of template arguments from passed function arguments ===<br />
<br />
#include <stdio.h><br />
<br />
class Class<br />
{<br />
public:<br />
void SomeFunction() { printf("SomeFunction\n"); }<br />
};<br />
<br />
template< class T > T& Function( T& arg )<br />
{<br />
return arg;<br />
}<br />
<br />
int main( int, char** )<br />
{<br />
Class f;<br />
Function(f).'''SomeFunction'''();<br />
return 0;<br />
}<br />
<br />
=== 4. Template arguments for templates ===<br />
<br />
#include <stdio.h><br />
<br />
template< template<class> class InternalTemplate, typename Type > class Test<br />
{<br />
public:<br />
<br />
InternalTemplate<Type> m_Member;<br />
};<br />
<br />
template< class T > class TestInt<br />
{<br />
public:<br />
<br />
T m_IntMember;<br />
};<br />
<br />
class Class<br />
{<br />
public:<br />
<br />
void Print() { printf("Class::Print\n"); }<br />
};<br />
<br />
int main( int, char** )<br />
{<br />
Test<TestInt,Class> Object;<br />
Object.m_Member.'''m_IntMember'''.'''Print'''();<br />
return 0;<br />
}<br />
<br />
=== 5. Partial specializations ===<br />
<br />
#include <stdio.h><br />
<br />
template< class T > class Template<br />
{<br />
public:<br />
void Print() { printf("Generic specialization\n"); }<br />
};<br />
<br />
template<> class Template<float><br />
{<br />
public:<br />
void PrintFloat() { printf("Partial specialization\n"); }<br />
};<br />
<br />
int main(int,char**)<br />
{<br />
Template<int> TInt;<br />
TInt.'''Print'''(); // PrintFloat() should not be available here<br />
<br />
Template<float> TFloat;<br />
TFloat.'''PrintFloat'''(); // Print() should not be available here<br />
<br />
return 0;<br />
}<br />
<br />
=== 6. Advanced template argument deduction ===<br />
<br />
#include <stdio.h><br />
<br />
// Class encapsulating function without arguments<br />
class Caller0<br />
{<br />
void (* m_Func )( void );<br />
<br />
public:<br />
<br />
Caller0( void (* Func )( void ) ) : m_Func(Func) {}<br />
<br />
void Call0() { m_Func(); }<br />
};<br />
<br />
// Template for class encapsulating function with one argument<br />
template < class T > class Caller1<br />
{<br />
void (* m_Func )( T );<br />
<br />
public:<br />
<br />
Caller1( void (* Func )( T ) ) : m_Func(Func) {}<br />
<br />
void Call1() { m_Func( T() ); }<br />
};<br />
<br />
// Template for class encapsulating function with two arguments<br />
template < class T1, class T2 > class Caller2<br />
{<br />
void (* m_Func )( T1, T2 );<br />
<br />
public:<br />
<br />
Caller2( void (* Func )( T1, T2 ) ) : m_Func(Func) {}<br />
<br />
void Call2() { m_Func ( T1(), T2() ); }<br />
};<br />
<br />
// This one will be used for functions without arguments<br />
Caller0 Invoke( void (* Func )( void ) )<br />
{<br />
return Caller0( Func );<br />
}<br />
<br />
// This one will be used for functions with one argument<br />
template < class T > Caller1<T> Invoke( void (* Func )( T ) )<br />
{<br />
return Caller1<T>( Func );<br />
}<br />
<br />
// This one will be used for functions with two arguments<br />
template < class T1, class T2 > Caller2<T1,T2> Invoke( void (* Func )( T1, T2 ) )<br />
{<br />
return Caller2<T1,T2> ( Func );<br />
}<br />
<br />
void Function0(void)<br />
{<br />
printf("Function0\n");<br />
}<br />
<br />
void Function1(float)<br />
{<br />
printf("Function1\n");<br />
}<br />
<br />
void Function2(int)<br />
{<br />
printf("Function2\n");<br />
}<br />
<br />
void Function3(int,float)<br />
{<br />
printf("Function3\n");<br />
}<br />
<br />
int main(int,char**)<br />
{<br />
Invoke( Function0 ).'''Call0'''();<br />
Invoke( Function1 ).'''Call1'''();<br />
Invoke( Function2 ).'''Call1'''();<br />
Invoke( Function3 ).'''Call2'''();<br />
<br />
Invoke( &Function0 ).'''Call0'''();<br />
Invoke( &Function1 ).'''Call1'''();<br />
Invoke( &Function2 ).'''Call1'''();<br />
Invoke( &Function3 ).'''Call2'''();<br />
return 0;<br />
}</div>Byohttps://wiki.codeblocks.org/index.php?title=Code::Completion_Rewrite&diff=5407Code::Completion Rewrite2008-03-12T08:00:29Z<p>Byo: /* 5. Partial specializations */</p>
<hr />
<div>== Background ==<br />
The current Code::Completion plug-in has some flaws, and is currently development frozen.<br />
The current plug-in lacks full support for:<br />
# function and class templates<br />
# default arguments in some cases<br />
# some of the more complicated c++ mucky business<br />
<br />
== Current Effort ==<br />
=== Structure ===<br />
The current C::C is a monolithic library of features, which could be de-coupled and split up for use in multiple plugins, providing extra functionality and flexibility in the future.<br />
Therefore, I propose the C::C be broken up into the following components:<br />
<br />
* Code::SymbolTable<br />
** Provide a list of valid symbols in the workspace, along with relevant scope information<br />
* Code::Completion<br />
** Provide Auto-complete features<br />
* Code::SymbolOutline<br />
** Provide Symbol browser, find symbol, function jump features<br />
* Code::Refactoring<br />
** Provide code refactoring features<br />
* Code::Documentation<br />
** Provide automatic code generation features<br />
<br />
=== Code::Completion ===<br />
==== Purpose Statement ====<br />
The current Code::Completion plugin is outdated, and needs a complete rewrite.<br />
The purpose of the Code::Completion plugin is thus:<br />
<br />
* Provide a list of likely symbols in the current scope as possible solutions to the current symbol.<br />
* Provide function tooltips<br />
** Parameter list<br />
** Relevant documentation<br />
* Provide completion features for class constructors<br />
* Provide completion features for initializer lists<br />
<br />
==== Process ====<br />
# Generate a list of all valid symbols in the current scope<br />
## Take global list from C::SymbolTable<br />
## Add in local scope parsed on the fly<br />
# Reduce that list to what is likely<br />
# Show that list to the user in some fashion<br />
# Insert the proper solution on user request<br />
=== Code::SymbolTable ===<br />
There will be 3 symbol lists:<br />
# global namespace<br />
# local scope<br />
# class scope<br />
<br />
Here's the current data proposal:<br />
<br />
class symbol<br />
{<br />
string name; // name of the symbol<br />
int id; // Id of the symbol, should be unique in the workspace<br />
int file_id; // Id of file where the symbol has been declared<br />
int filepos_begin; // Position where declaration of the symbol starts<br />
int filepos_end; // Position where declaration of the symbol ends<br />
int type; // Type of the symbol: macro / class / typedef / variable / function<br />
flags modifiers; // Bitfield used to mark some estra properties of symbol<br />
// like that it is static or inline<br />
int value_type_id; // Id of symbol which represents c++ type of current symbol<br />
// (like type of variable or type of returned value from function)<br />
int extra_type_id; // Extra type used in some cases<br />
list children; // List of child elements of this symbol (members in class etc)<br />
list extra_lists[3]; // See table below<br />
map extra_values; // int -> string map which can keep some extra data<br />
}<br />
<br />
class list_entry<br />
{<br />
int symbol_id; // ID of the symbol referenced<br />
int storage_class; // Storage class of the symbol (private/protected/public)<br />
}<br />
<br />
Explanation of symbol::extra_lists[]<br />
{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"<br />
|- style="background: #ececec; border: 1px solid gray;"<br />
! type<br />
! modifiers<br />
! value_type_id<br />
! extra_type<br />
! children<br />
! extra_lists[0]<br />
! extra_lists[1]<br />
! extra_lists[2]<br />
|-<br />
<br />
|-<br />
| namespace<br />
|<br />
|<br />
|<br />
| declarations in namespace<br />
|"using" namespaces<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| class / struct / union<br />
|<br />
|<br />
|<br />
| members of class<br />
| base classes<br />
| template args<br />
| friends of class<br />
|-<br />
<br />
|-<br />
| variable<br />
| extern, static, volatile, const<br />
| type of variable<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| function<br />
| static, inline, const ...<br />
| returned value<br />
|<br />
| arguments<br />
| template arguments<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| typedef<br />
| pointer, array, reference, pointer_to_member<br />
| base type<br />
| type of class in pointer_to_member<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| enum<br />
|<br />
|<br />
|<br />
| items in enum<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| enum item<br />
|<br />
|<br />
| id of enum<br />
| <br />
| <br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| macro<br />
|<br />
|<br />
|<br />
| macro parts<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| macro part<br />
| arg_to_string, va_args<br />
| number of arg or -1<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|}<br />
<br />
Comments:<br />
* Such representation would require some extra "hidden" symbols - for example when some complex type is returned from function, extra symbol of typedef representing proper value would be required.<br />
* Also in case of templates, typeid's should be threated in special way - negative value could mean to use template argument instead of some real type. Base types (the POD ones) should have some predefined type ids.<br />
<br />
Questions:<br />
* why are we storing filepos_end? Wouldn't it be much more useful to store declaration, definition info?<br />
<br />
== More complex cases of C::C usage ==<br />
<br />
Here we can put some more complex examples of c++ code where C::C may fail. Symbols that may be hard to find should be marked in bold<br />
<br />
=== 1: Fetching type of operator call ===<br />
<br />
#include <string><br />
using namespace std;<br />
<br />
int main(int,char**)<br />
{<br />
( string("first") + "second" + "third" ) . '''c_str'''();<br />
return 0;<br />
}<br />
<br />
=== 2: Template classes ===<br />
<br />
template<typename T> class Template<br />
{<br />
public:<br />
T& GetInstance() { return m_Instance; }<br />
private:<br />
T m_Instance;<br />
};<br />
<br />
class Parameter<br />
{<br />
public:<br />
void PrintfText() { printf("Text"); }<br />
};<br />
<br />
int main(int,char**)<br />
{<br />
Template<Parameter> Object;<br />
Object.GetInstance().'''PrintfText'''();<br />
}<br />
<br />
=== 3: Automated deduction of template arguments from passed function arguments ===<br />
<br />
#include <stdio.h><br />
<br />
class Class<br />
{<br />
public:<br />
void SomeFunction() { printf("SomeFunction\n"); }<br />
};<br />
<br />
template< class T > T& Function( T& arg )<br />
{<br />
return arg;<br />
}<br />
<br />
int main( int, char** )<br />
{<br />
Class f;<br />
Function(f).'''SomeFunction'''();<br />
return 0;<br />
}<br />
<br />
=== 4. Template arguments for templates ===<br />
<br />
#include <stdio.h><br />
<br />
template< template<class> class InternalTemplate, typename Type > class Test<br />
{<br />
public:<br />
<br />
InternalTemplate<Type> m_Member;<br />
};<br />
<br />
template< class T > class TestInt<br />
{<br />
public:<br />
<br />
T m_IntMember;<br />
};<br />
<br />
class Class<br />
{<br />
public:<br />
<br />
void Print() { printf("Class::Print\n"); }<br />
};<br />
<br />
int main( int, char** )<br />
{<br />
Test<TestInt,Class> Object;<br />
Object.m_Member.'''m_IntMember'''.'''Print'''();<br />
return 0;<br />
}<br />
<br />
=== 5. Partial specializations ===<br />
<br />
#include <stdio.h><br />
<br />
template< class T > class Template<br />
{<br />
public:<br />
void Print() { printf("Generic specialization\n"); }<br />
};<br />
<br />
template<> class Template<float><br />
{<br />
public:<br />
void PrintFloat() { printf("Partial specialization\n"); }<br />
};<br />
<br />
int main(int,char**)<br />
{<br />
Template<int> TInt;<br />
TInt.'''Print'''(); // PrintFloat() should not be available here<br />
<br />
Template<float> TFloat;<br />
TFloat.'''PrintFloat'''(); // Print() should not be available here<br />
<br />
return 0;<br />
}<br />
<br />
=== 6. Advanced template argument deduction ===<br />
<br />
#include <stdio.h><br />
<br />
// Class encapsulating function without arguments<br />
class Caller0<br />
{<br />
void (* m_Func )( void );<br />
<br />
public:<br />
<br />
Caller0( void (* Func )( void ) ) : m_Func(Func) {}<br />
<br />
void Call0() { m_Func(); }<br />
};<br />
<br />
// Template for class encapsulating function with one argument<br />
template < class T > class Caller1<br />
{<br />
void (* m_Func )( T );<br />
<br />
public:<br />
<br />
Caller1( void (* Func )( T ) ) : m_Func(Func) {}<br />
<br />
void Call1() { m_Func( T() ); }<br />
};<br />
<br />
// Template for class encapsulating function with two arguments<br />
template < class T1, class T2 > class Caller2<br />
{<br />
void (* m_Func )( T1, T2 );<br />
<br />
public:<br />
<br />
Caller2( void (* Func )( T1, T2 ) ) : m_Func(Func) {}<br />
<br />
void Call2() { m_Func ( T1(), T2() ); }<br />
};<br />
<br />
// This one will be used for functions without arguments<br />
Caller0 Invoke( void (* Func )( void ) )<br />
{<br />
return Caller0( Func );<br />
}<br />
<br />
// This one will be used for functions with one argument<br />
template < class T > Caller1<T> Invoke( void (* Func )( T ) )<br />
{<br />
return Caller1<T>( Func );<br />
}<br />
<br />
// This one will be used for functions with two arguments<br />
template < class T1, class T2 > Caller2<T1,T2> Invoke( void (* Func )( T1, T2 ) )<br />
{<br />
return Caller2<T1,T2> ( Func );<br />
}<br />
<br />
void Function0(void)<br />
{<br />
printf("Function0\n");<br />
}<br />
<br />
void Function1(float)<br />
{<br />
printf("Function1\n");<br />
}<br />
<br />
void Function2(int)<br />
{<br />
printf("Function2\n");<br />
}<br />
<br />
void Function3(int,float)<br />
{<br />
printf("Function3\n");<br />
}<br />
<br />
int main(int,char**)<br />
{<br />
Invoke( Function0 ).Call0();<br />
Invoke( Function1 ).Call1();<br />
Invoke( Function2 ).Call1();<br />
Invoke( Function3 ).Call2();<br />
<br />
Invoke( &Function0 ).Call0();<br />
Invoke( &Function1 ).Call1();<br />
Invoke( &Function2 ).Call1();<br />
Invoke( &Function3 ).Call2();<br />
return 0;<br />
}</div>Byohttps://wiki.codeblocks.org/index.php?title=Code::Completion_Rewrite&diff=5406Code::Completion Rewrite2008-03-12T07:42:52Z<p>Byo: /* 4. Template arguments for templates */</p>
<hr />
<div>== Background ==<br />
The current Code::Completion plug-in has some flaws, and is currently development frozen.<br />
The current plug-in lacks full support for:<br />
# function and class templates<br />
# default arguments in some cases<br />
# some of the more complicated c++ mucky business<br />
<br />
== Current Effort ==<br />
=== Structure ===<br />
The current C::C is a monolithic library of features, which could be de-coupled and split up for use in multiple plugins, providing extra functionality and flexibility in the future.<br />
Therefore, I propose the C::C be broken up into the following components:<br />
<br />
* Code::SymbolTable<br />
** Provide a list of valid symbols in the workspace, along with relevant scope information<br />
* Code::Completion<br />
** Provide Auto-complete features<br />
* Code::SymbolOutline<br />
** Provide Symbol browser, find symbol, function jump features<br />
* Code::Refactoring<br />
** Provide code refactoring features<br />
* Code::Documentation<br />
** Provide automatic code generation features<br />
<br />
=== Code::Completion ===<br />
==== Purpose Statement ====<br />
The current Code::Completion plugin is outdated, and needs a complete rewrite.<br />
The purpose of the Code::Completion plugin is thus:<br />
<br />
* Provide a list of likely symbols in the current scope as possible solutions to the current symbol.<br />
* Provide function tooltips<br />
** Parameter list<br />
** Relevant documentation<br />
* Provide completion features for class constructors<br />
* Provide completion features for initializer lists<br />
<br />
==== Process ====<br />
# Generate a list of all valid symbols in the current scope<br />
## Take global list from C::SymbolTable<br />
## Add in local scope parsed on the fly<br />
# Reduce that list to what is likely<br />
# Show that list to the user in some fashion<br />
# Insert the proper solution on user request<br />
=== Code::SymbolTable ===<br />
There will be 3 symbol lists:<br />
# global namespace<br />
# local scope<br />
# class scope<br />
<br />
Here's the current data proposal:<br />
<br />
class symbol<br />
{<br />
string name; // name of the symbol<br />
int id; // Id of the symbol, should be unique in the workspace<br />
int file_id; // Id of file where the symbol has been declared<br />
int filepos_begin; // Position where declaration of the symbol starts<br />
int filepos_end; // Position where declaration of the symbol ends<br />
int type; // Type of the symbol: macro / class / typedef / variable / function<br />
flags modifiers; // Bitfield used to mark some estra properties of symbol<br />
// like that it is static or inline<br />
int value_type_id; // Id of symbol which represents c++ type of current symbol<br />
// (like type of variable or type of returned value from function)<br />
int extra_type_id; // Extra type used in some cases<br />
list children; // List of child elements of this symbol (members in class etc)<br />
list extra_lists[3]; // See table below<br />
map extra_values; // int -> string map which can keep some extra data<br />
}<br />
<br />
class list_entry<br />
{<br />
int symbol_id; // ID of the symbol referenced<br />
int storage_class; // Storage class of the symbol (private/protected/public)<br />
}<br />
<br />
Explanation of symbol::extra_lists[]<br />
{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"<br />
|- style="background: #ececec; border: 1px solid gray;"<br />
! type<br />
! modifiers<br />
! value_type_id<br />
! extra_type<br />
! children<br />
! extra_lists[0]<br />
! extra_lists[1]<br />
! extra_lists[2]<br />
|-<br />
<br />
|-<br />
| namespace<br />
|<br />
|<br />
|<br />
| declarations in namespace<br />
|"using" namespaces<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| class / struct / union<br />
|<br />
|<br />
|<br />
| members of class<br />
| base classes<br />
| template args<br />
| friends of class<br />
|-<br />
<br />
|-<br />
| variable<br />
| extern, static, volatile, const<br />
| type of variable<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| function<br />
| static, inline, const ...<br />
| returned value<br />
|<br />
| arguments<br />
| template arguments<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| typedef<br />
| pointer, array, reference, pointer_to_member<br />
| base type<br />
| type of class in pointer_to_member<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| enum<br />
|<br />
|<br />
|<br />
| items in enum<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| enum item<br />
|<br />
|<br />
| id of enum<br />
| <br />
| <br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| macro<br />
|<br />
|<br />
|<br />
| macro parts<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| macro part<br />
| arg_to_string, va_args<br />
| number of arg or -1<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|}<br />
<br />
Comments:<br />
* Such representation would require some extra "hidden" symbols - for example when some complex type is returned from function, extra symbol of typedef representing proper value would be required.<br />
* Also in case of templates, typeid's should be threated in special way - negative value could mean to use template argument instead of some real type. Base types (the POD ones) should have some predefined type ids.<br />
<br />
Questions:<br />
* why are we storing filepos_end? Wouldn't it be much more useful to store declaration, definition info?<br />
<br />
== More complex cases of C::C usage ==<br />
<br />
Here we can put some more complex examples of c++ code where C::C may fail. Symbols that may be hard to find should be marked in bold<br />
<br />
=== 1: Fetching type of operator call ===<br />
<br />
#include <string><br />
using namespace std;<br />
<br />
int main(int,char**)<br />
{<br />
( string("first") + "second" + "third" ) . '''c_str'''();<br />
return 0;<br />
}<br />
<br />
=== 2: Template classes ===<br />
<br />
template<typename T> class Template<br />
{<br />
public:<br />
T& GetInstance() { return m_Instance; }<br />
private:<br />
T m_Instance;<br />
};<br />
<br />
class Parameter<br />
{<br />
public:<br />
void PrintfText() { printf("Text"); }<br />
};<br />
<br />
int main(int,char**)<br />
{<br />
Template<Parameter> Object;<br />
Object.GetInstance().'''PrintfText'''();<br />
}<br />
<br />
=== 3: Automated deduction of template arguments from passed function arguments ===<br />
<br />
#include <stdio.h><br />
<br />
class Class<br />
{<br />
public:<br />
void SomeFunction() { printf("SomeFunction\n"); }<br />
};<br />
<br />
template< class T > T& Function( T& arg )<br />
{<br />
return arg;<br />
}<br />
<br />
int main( int, char** )<br />
{<br />
Class f;<br />
Function(f).'''SomeFunction'''();<br />
return 0;<br />
}<br />
<br />
=== 4. Template arguments for templates ===<br />
<br />
#include <stdio.h><br />
<br />
template< template<class> class InternalTemplate, typename Type > class Test<br />
{<br />
public:<br />
<br />
InternalTemplate<Type> m_Member;<br />
};<br />
<br />
template< class T > class TestInt<br />
{<br />
public:<br />
<br />
T m_IntMember;<br />
};<br />
<br />
class Class<br />
{<br />
public:<br />
<br />
void Print() { printf("Class::Print\n"); }<br />
};<br />
<br />
int main( int, char** )<br />
{<br />
Test<TestInt,Class> Object;<br />
Object.m_Member.'''m_IntMember'''.'''Print'''();<br />
return 0;<br />
}<br />
<br />
=== 5. Partial specializations ===<br />
<br />
#include <stdio.h><br />
<br />
template< class T > class Template<br />
{<br />
public:<br />
void Print() { printf("Generic specialization\n"); }<br />
};<br />
<br />
template<> class Template<float><br />
{<br />
public:<br />
void PrintFloat() { printf("Partial specialization\n"); }<br />
};<br />
<br />
int main(int,char**)<br />
{<br />
Template<int> TInt;<br />
TInt.'''Print'''(); // PrintFloat() should not be available here<br />
<br />
Template<float> TFloat;<br />
TFloat.'''PrintFloat'''(); // Print() should not be available here<br />
<br />
return 0;<br />
}</div>Byohttps://wiki.codeblocks.org/index.php?title=Code::Completion_Rewrite&diff=5405Code::Completion Rewrite2008-03-11T21:36:11Z<p>Byo: /* 4. Template arguments for templates */</p>
<hr />
<div>== Background ==<br />
The current Code::Completion plug-in has some flaws, and is currently development frozen.<br />
The current plug-in lacks full support for:<br />
# function and class templates<br />
# default arguments in some cases<br />
# some of the more complicated c++ mucky business<br />
<br />
== Current Effort ==<br />
=== Structure ===<br />
The current C::C is a monolithic library of features, which could be de-coupled and split up for use in multiple plugins, providing extra functionality and flexibility in the future.<br />
Therefore, I propose the C::C be broken up into the following components:<br />
<br />
* Code::SymbolTable<br />
** Provide a list of valid symbols in the workspace, along with relevant scope information<br />
* Code::Completion<br />
** Provide Auto-complete features<br />
* Code::SymbolOutline<br />
** Provide Symbol browser, find symbol, function jump features<br />
* Code::Refactoring<br />
** Provide code refactoring features<br />
* Code::Documentation<br />
** Provide automatic code generation features<br />
<br />
=== Code::Completion ===<br />
==== Purpose Statement ====<br />
The current Code::Completion plugin is outdated, and needs a complete rewrite.<br />
The purpose of the Code::Completion plugin is thus:<br />
<br />
* Provide a list of likely symbols in the current scope as possible solutions to the current symbol.<br />
* Provide function tooltips<br />
** Parameter list<br />
** Relevant documentation<br />
* Provide completion features for class constructors<br />
* Provide completion features for initializer lists<br />
<br />
==== Process ====<br />
# Generate a list of all valid symbols in the current scope<br />
## Take global list from C::SymbolTable<br />
## Add in local scope parsed on the fly<br />
# Reduce that list to what is likely<br />
# Show that list to the user in some fashion<br />
# Insert the proper solution on user request<br />
=== Code::SymbolTable ===<br />
There will be 3 symbol lists:<br />
# global namespace<br />
# local scope<br />
# class scope<br />
<br />
Here's the current data proposal:<br />
<br />
class symbol<br />
{<br />
string name; // name of the symbol<br />
int id; // Id of the symbol, should be unique in the workspace<br />
int file_id; // Id of file where the symbol has been declared<br />
int filepos_begin; // Position where declaration of the symbol starts<br />
int filepos_end; // Position where declaration of the symbol ends<br />
int type; // Type of the symbol: macro / class / typedef / variable / function<br />
flags modifiers; // Bitfield used to mark some estra properties of symbol<br />
// like that it is static or inline<br />
int value_type_id; // Id of symbol which represents c++ type of current symbol<br />
// (like type of variable or type of returned value from function)<br />
int extra_type_id; // Extra type used in some cases<br />
list children; // List of child elements of this symbol (members in class etc)<br />
list extra_lists[3]; // See table below<br />
map extra_values; // int -> string map which can keep some extra data<br />
}<br />
<br />
class list_entry<br />
{<br />
int symbol_id; // ID of the symbol referenced<br />
int storage_class; // Storage class of the symbol (private/protected/public)<br />
}<br />
<br />
Explanation of symbol::extra_lists[]<br />
{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"<br />
|- style="background: #ececec; border: 1px solid gray;"<br />
! type<br />
! modifiers<br />
! value_type_id<br />
! extra_type<br />
! children<br />
! extra_lists[0]<br />
! extra_lists[1]<br />
! extra_lists[2]<br />
|-<br />
<br />
|-<br />
| namespace<br />
|<br />
|<br />
|<br />
| declarations in namespace<br />
|"using" namespaces<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| class / struct / union<br />
|<br />
|<br />
|<br />
| members of class<br />
| base classes<br />
| template args<br />
| friends of class<br />
|-<br />
<br />
|-<br />
| variable<br />
| extern, static, volatile, const<br />
| type of variable<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| function<br />
| static, inline, const ...<br />
| returned value<br />
|<br />
| arguments<br />
| template arguments<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| typedef<br />
| pointer, array, reference, pointer_to_member<br />
| base type<br />
| type of class in pointer_to_member<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| enum<br />
|<br />
|<br />
|<br />
| items in enum<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| enum item<br />
|<br />
|<br />
| id of enum<br />
| <br />
| <br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| macro<br />
|<br />
|<br />
|<br />
| macro parts<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| macro part<br />
| arg_to_string, va_args<br />
| number of arg or -1<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|}<br />
<br />
Comments:<br />
* Such representation would require some extra "hidden" symbols - for example when some complex type is returned from function, extra symbol of typedef representing proper value would be required.<br />
* Also in case of templates, typeid's should be threated in special way - negative value could mean to use template argument instead of some real type. Base types (the POD ones) should have some predefined type ids.<br />
<br />
Questions:<br />
* why are we storing filepos_end? Wouldn't it be much more useful to store declaration, definition info?<br />
<br />
== More complex cases of C::C usage ==<br />
<br />
Here we can put some more complex examples of c++ code where C::C may fail. Symbols that may be hard to find should be marked in bold<br />
<br />
=== 1: Fetching type of operator call ===<br />
<br />
#include <string><br />
using namespace std;<br />
<br />
int main(int,char**)<br />
{<br />
( string("first") + "second" + "third" ) . '''c_str'''();<br />
return 0;<br />
}<br />
<br />
=== 2: Template classes ===<br />
<br />
template<typename T> class Template<br />
{<br />
public:<br />
T& GetInstance() { return m_Instance; }<br />
private:<br />
T m_Instance;<br />
};<br />
<br />
class Parameter<br />
{<br />
public:<br />
void PrintfText() { printf("Text"); }<br />
};<br />
<br />
int main(int,char**)<br />
{<br />
Template<Parameter> Object;<br />
Object.GetInstance().'''PrintfText'''();<br />
}<br />
<br />
=== 3: Automated deduction of template arguments from passed function arguments ===<br />
<br />
#include <stdio.h><br />
<br />
class Class<br />
{<br />
public:<br />
void SomeFunction() { printf("SomeFunction\n"); }<br />
};<br />
<br />
template< class T > T& Function( T& arg )<br />
{<br />
return arg;<br />
}<br />
<br />
int main( int, char** )<br />
{<br />
Class f;<br />
Function(f).'''SomeFunction'''();<br />
return 0;<br />
}<br />
<br />
=== 4. Template arguments for templates ===<br />
<br />
#include <stdio.h><br />
<br />
template< template<class> class InternalTemplate, typename Type > class Test<br />
{<br />
public:<br />
<br />
InternalTemplate<Type> m_Member;<br />
};<br />
<br />
template< class T > class TestInt<br />
{<br />
public:<br />
<br />
T m_IntMember;<br />
};<br />
<br />
class Class<br />
{<br />
public:<br />
<br />
void Print() { printf("Class::Print\n"); }<br />
};<br />
<br />
int main( int, char** )<br />
{<br />
Test<TestInt,Class> Object;<br />
Object.m_Member.'''m_IntMember'''.'''Print'''();<br />
return 0;<br />
}</div>Byohttps://wiki.codeblocks.org/index.php?title=Code::Completion_Rewrite&diff=5404Code::Completion Rewrite2008-03-11T21:35:44Z<p>Byo: Added hard example 4</p>
<hr />
<div>== Background ==<br />
The current Code::Completion plug-in has some flaws, and is currently development frozen.<br />
The current plug-in lacks full support for:<br />
# function and class templates<br />
# default arguments in some cases<br />
# some of the more complicated c++ mucky business<br />
<br />
== Current Effort ==<br />
=== Structure ===<br />
The current C::C is a monolithic library of features, which could be de-coupled and split up for use in multiple plugins, providing extra functionality and flexibility in the future.<br />
Therefore, I propose the C::C be broken up into the following components:<br />
<br />
* Code::SymbolTable<br />
** Provide a list of valid symbols in the workspace, along with relevant scope information<br />
* Code::Completion<br />
** Provide Auto-complete features<br />
* Code::SymbolOutline<br />
** Provide Symbol browser, find symbol, function jump features<br />
* Code::Refactoring<br />
** Provide code refactoring features<br />
* Code::Documentation<br />
** Provide automatic code generation features<br />
<br />
=== Code::Completion ===<br />
==== Purpose Statement ====<br />
The current Code::Completion plugin is outdated, and needs a complete rewrite.<br />
The purpose of the Code::Completion plugin is thus:<br />
<br />
* Provide a list of likely symbols in the current scope as possible solutions to the current symbol.<br />
* Provide function tooltips<br />
** Parameter list<br />
** Relevant documentation<br />
* Provide completion features for class constructors<br />
* Provide completion features for initializer lists<br />
<br />
==== Process ====<br />
# Generate a list of all valid symbols in the current scope<br />
## Take global list from C::SymbolTable<br />
## Add in local scope parsed on the fly<br />
# Reduce that list to what is likely<br />
# Show that list to the user in some fashion<br />
# Insert the proper solution on user request<br />
=== Code::SymbolTable ===<br />
There will be 3 symbol lists:<br />
# global namespace<br />
# local scope<br />
# class scope<br />
<br />
Here's the current data proposal:<br />
<br />
class symbol<br />
{<br />
string name; // name of the symbol<br />
int id; // Id of the symbol, should be unique in the workspace<br />
int file_id; // Id of file where the symbol has been declared<br />
int filepos_begin; // Position where declaration of the symbol starts<br />
int filepos_end; // Position where declaration of the symbol ends<br />
int type; // Type of the symbol: macro / class / typedef / variable / function<br />
flags modifiers; // Bitfield used to mark some estra properties of symbol<br />
// like that it is static or inline<br />
int value_type_id; // Id of symbol which represents c++ type of current symbol<br />
// (like type of variable or type of returned value from function)<br />
int extra_type_id; // Extra type used in some cases<br />
list children; // List of child elements of this symbol (members in class etc)<br />
list extra_lists[3]; // See table below<br />
map extra_values; // int -> string map which can keep some extra data<br />
}<br />
<br />
class list_entry<br />
{<br />
int symbol_id; // ID of the symbol referenced<br />
int storage_class; // Storage class of the symbol (private/protected/public)<br />
}<br />
<br />
Explanation of symbol::extra_lists[]<br />
{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"<br />
|- style="background: #ececec; border: 1px solid gray;"<br />
! type<br />
! modifiers<br />
! value_type_id<br />
! extra_type<br />
! children<br />
! extra_lists[0]<br />
! extra_lists[1]<br />
! extra_lists[2]<br />
|-<br />
<br />
|-<br />
| namespace<br />
|<br />
|<br />
|<br />
| declarations in namespace<br />
|"using" namespaces<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| class / struct / union<br />
|<br />
|<br />
|<br />
| members of class<br />
| base classes<br />
| template args<br />
| friends of class<br />
|-<br />
<br />
|-<br />
| variable<br />
| extern, static, volatile, const<br />
| type of variable<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| function<br />
| static, inline, const ...<br />
| returned value<br />
|<br />
| arguments<br />
| template arguments<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| typedef<br />
| pointer, array, reference, pointer_to_member<br />
| base type<br />
| type of class in pointer_to_member<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| enum<br />
|<br />
|<br />
|<br />
| items in enum<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| enum item<br />
|<br />
|<br />
| id of enum<br />
| <br />
| <br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| macro<br />
|<br />
|<br />
|<br />
| macro parts<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| macro part<br />
| arg_to_string, va_args<br />
| number of arg or -1<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|}<br />
<br />
Comments:<br />
* Such representation would require some extra "hidden" symbols - for example when some complex type is returned from function, extra symbol of typedef representing proper value would be required.<br />
* Also in case of templates, typeid's should be threated in special way - negative value could mean to use template argument instead of some real type. Base types (the POD ones) should have some predefined type ids.<br />
<br />
Questions:<br />
* why are we storing filepos_end? Wouldn't it be much more useful to store declaration, definition info?<br />
<br />
== More complex cases of C::C usage ==<br />
<br />
Here we can put some more complex examples of c++ code where C::C may fail. Symbols that may be hard to find should be marked in bold<br />
<br />
=== 1: Fetching type of operator call ===<br />
<br />
#include <string><br />
using namespace std;<br />
<br />
int main(int,char**)<br />
{<br />
( string("first") + "second" + "third" ) . '''c_str'''();<br />
return 0;<br />
}<br />
<br />
=== 2: Template classes ===<br />
<br />
template<typename T> class Template<br />
{<br />
public:<br />
T& GetInstance() { return m_Instance; }<br />
private:<br />
T m_Instance;<br />
};<br />
<br />
class Parameter<br />
{<br />
public:<br />
void PrintfText() { printf("Text"); }<br />
};<br />
<br />
int main(int,char**)<br />
{<br />
Template<Parameter> Object;<br />
Object.GetInstance().'''PrintfText'''();<br />
}<br />
<br />
=== 3: Automated deduction of template arguments from passed function arguments ===<br />
<br />
#include <stdio.h><br />
<br />
class Class<br />
{<br />
public:<br />
void SomeFunction() { printf("SomeFunction\n"); }<br />
};<br />
<br />
template< class T > T& Function( T& arg )<br />
{<br />
return arg;<br />
}<br />
<br />
int main( int, char** )<br />
{<br />
Class f;<br />
Function(f).'''SomeFunction'''();<br />
return 0;<br />
}<br />
<br />
=== 4. Template arguments for templates ===<br />
<br />
#include <stdio.h><br />
<br />
template< template<class> class InternalTemplate, typename Type > class Test<br />
{<br />
public:<br />
<br />
InternalTemplate<Type> m_Member;<br />
};<br />
<br />
template< class T > class TestInt<br />
{<br />
public:<br />
<br />
T m_IntMember;<br />
};<br />
<br />
class Class<br />
{<br />
public:<br />
<br />
void Print() { printf("Class::Print\n"); }<br />
};<br />
<br />
int main( int, char** )<br />
{<br />
Test<TestInt,Class> Object;<br />
Object.m_Member.m_IntMember.Print();<br />
return 0;<br />
}</div>Byohttps://wiki.codeblocks.org/index.php?title=Code::Completion_Rewrite&diff=5403Code::Completion Rewrite2008-03-11T21:29:22Z<p>Byo: /* More complex cases of C::C usage */</p>
<hr />
<div>== Background ==<br />
The current Code::Completion plug-in has some flaws, and is currently development frozen.<br />
The current plug-in lacks full support for:<br />
# function and class templates<br />
# default arguments in some cases<br />
# some of the more complicated c++ mucky business<br />
<br />
== Current Effort ==<br />
=== Structure ===<br />
The current C::C is a monolithic library of features, which could be de-coupled and split up for use in multiple plugins, providing extra functionality and flexibility in the future.<br />
Therefore, I propose the C::C be broken up into the following components:<br />
<br />
* Code::SymbolTable<br />
** Provide a list of valid symbols in the workspace, along with relevant scope information<br />
* Code::Completion<br />
** Provide Auto-complete features<br />
* Code::SymbolOutline<br />
** Provide Symbol browser, find symbol, function jump features<br />
* Code::Refactoring<br />
** Provide code refactoring features<br />
* Code::Documentation<br />
** Provide automatic code generation features<br />
<br />
=== Code::Completion ===<br />
==== Purpose Statement ====<br />
The current Code::Completion plugin is outdated, and needs a complete rewrite.<br />
The purpose of the Code::Completion plugin is thus:<br />
<br />
* Provide a list of likely symbols in the current scope as possible solutions to the current symbol.<br />
* Provide function tooltips<br />
** Parameter list<br />
** Relevant documentation<br />
* Provide completion features for class constructors<br />
* Provide completion features for initializer lists<br />
<br />
==== Process ====<br />
# Generate a list of all valid symbols in the current scope<br />
## Take global list from C::SymbolTable<br />
## Add in local scope parsed on the fly<br />
# Reduce that list to what is likely<br />
# Show that list to the user in some fashion<br />
# Insert the proper solution on user request<br />
=== Code::SymbolTable ===<br />
There will be 3 symbol lists:<br />
# global namespace<br />
# local scope<br />
# class scope<br />
<br />
Here's the current data proposal:<br />
<br />
class symbol<br />
{<br />
string name; // name of the symbol<br />
int id; // Id of the symbol, should be unique in the workspace<br />
int file_id; // Id of file where the symbol has been declared<br />
int filepos_begin; // Position where declaration of the symbol starts<br />
int filepos_end; // Position where declaration of the symbol ends<br />
int type; // Type of the symbol: macro / class / typedef / variable / function<br />
flags modifiers; // Bitfield used to mark some estra properties of symbol<br />
// like that it is static or inline<br />
int value_type_id; // Id of symbol which represents c++ type of current symbol<br />
// (like type of variable or type of returned value from function)<br />
int extra_type_id; // Extra type used in some cases<br />
list children; // List of child elements of this symbol (members in class etc)<br />
list extra_lists[3]; // See table below<br />
map extra_values; // int -> string map which can keep some extra data<br />
}<br />
<br />
class list_entry<br />
{<br />
int symbol_id; // ID of the symbol referenced<br />
int storage_class; // Storage class of the symbol (private/protected/public)<br />
}<br />
<br />
Explanation of symbol::extra_lists[]<br />
{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"<br />
|- style="background: #ececec; border: 1px solid gray;"<br />
! type<br />
! modifiers<br />
! value_type_id<br />
! extra_type<br />
! children<br />
! extra_lists[0]<br />
! extra_lists[1]<br />
! extra_lists[2]<br />
|-<br />
<br />
|-<br />
| namespace<br />
|<br />
|<br />
|<br />
| declarations in namespace<br />
|"using" namespaces<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| class / struct / union<br />
|<br />
|<br />
|<br />
| members of class<br />
| base classes<br />
| template args<br />
| friends of class<br />
|-<br />
<br />
|-<br />
| variable<br />
| extern, static, volatile, const<br />
| type of variable<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| function<br />
| static, inline, const ...<br />
| returned value<br />
|<br />
| arguments<br />
| template arguments<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| typedef<br />
| pointer, array, reference, pointer_to_member<br />
| base type<br />
| type of class in pointer_to_member<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| enum<br />
|<br />
|<br />
|<br />
| items in enum<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| enum item<br />
|<br />
|<br />
| id of enum<br />
| <br />
| <br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| macro<br />
|<br />
|<br />
|<br />
| macro parts<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|-<br />
| macro part<br />
| arg_to_string, va_args<br />
| number of arg or -1<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
<br />
|}<br />
<br />
Comments:<br />
* Such representation would require some extra "hidden" symbols - for example when some complex type is returned from function, extra symbol of typedef representing proper value would be required.<br />
* Also in case of templates, typeid's should be threated in special way - negative value could mean to use template argument instead of some real type. Base types (the POD ones) should have some predefined type ids.<br />
<br />
Questions:<br />
* why are we storing filepos_end? Wouldn't it be much more useful to store declaration, definition info?<br />
<br />
== More complex cases of C::C usage ==<br />
<br />
Here we can put some more complex examples of c++ code where C::C may fail. Symbols that may be hard to find should be marked in bold<br />
<br />
=== 1: Fetching type of operator call ===<br />
<br />
#include <string><br />
using namespace std;<br />
<br />
int main(int,char**)<br />
{<br />
( string("first") + "second" + "third" ) . '''c_str'''();<br />
return 0;<br />
}<br />
<br />
=== 2: Template classes ===<br />
<br />
template<typename T> class Template<br />
{<br />
public:<br />
T& GetInstance() { return m_Instance; }<br />
private:<br />
T m_Instance;<br />
};<br />
<br />
class Parameter<br />
{<br />
public:<br />
void PrintfText() { printf("Text"); }<br />
};<br />
<br />
int main(int,char**)<br />
{<br />
Template<Parameter> Object;<br />
Object.GetInstance().'''PrintfText'''();<br />
}<br />
<br />
=== 3: Automated deduction of template arguments from passed function arguments ===<br />
<br />
#include <stdio.h><br />
<br />
class Class<br />
{<br />
public:<br />
void SomeFunction() { printf("SomeFunction\n"); }<br />
};<br />
<br />
template< class T > T& Function( T& arg )<br />
{<br />
return arg;<br />
}<br />
<br />
int main( int, char** )<br />
{<br />
Class f;<br />
Function(f).'''SomeFunction'''();<br />
return 0;<br />
}</div>Byohttps://wiki.codeblocks.org/index.php?title=Code::Completion_Rewrite&diff=5389Code::Completion Rewrite2008-03-11T12:16:56Z<p>Byo: </p>
<hr />
<div>== Background ==<br />
The current Code::Completion plug-in has some flaws, and is currently development frozen.<br />
The current plug-in lacks full support for:<br />
# function and class templates<br />
# default arguments in some cases<br />
# some of the more complicated c++ mucky business<br />
<br />
== Current Effort ==<br />
=== Current Specification ===<br />
To appear at some near date.<br />
=== Current Data Model ===<br />
Also to appear at some near date.<br />
<br />
== More complex cases of C::C usage ==<br />
<br />
Here we can put some more comples examples of c++ code where C::C may fail. Symbols that may be hard to find should be marked in bold<br />
<br />
=== 1: Fetching type of operator call ===<br />
<br />
#include <string><br />
using namespace std;<br />
<br />
int main(int,char**)<br />
{<br />
( string("first") + "second" + "third" ) . '''c_str'''();<br />
return 0;<br />
}</div>Byohttps://wiki.codeblocks.org/index.php?title=WxSmith_Timeline&diff=5315WxSmith Timeline2008-01-21T11:49:06Z<p>Byo: </p>
<hr />
<div>Timeline for wxSmith:<br />
<br />
{| 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;"<br />
|- style="background: #ececec;"<br />
! style="width: 15em" | Task<br />
! Description<br />
! style="width: 7em" | Estimated time<br />
! style="width: 5em" | Finished<br />
|-<br />
! Events in wiki<br />
| style="text-align: left" | Add description of events system into Wiki:<br />
* Choose item which generate events (few different)<br />
* Add item's source into wxSmithContribItems<br />
* Add class registering item in wxSmith<br />
* add events and describe this process in Wiki<br />
| 1 day<br />
| {{yes}}<br />
|-<br />
! Extra init code<br />
| style="text-align: left;" | Add extra initialization code added right after item is built<br />
''Warning: this may mess the code base''<br />
| 2 hours<br />
| {{yes}}<br />
|-<br />
! Insert by mouse<br />
| style="text-align: left;" | Allow adding items to resource by pointing with mouse<br />
| 1 day<br />
| {{yes}}<br />
|-<br />
! Grid<br />
| style="text-align: left;" | Add grid for containers without sizers. This will require:<br />
* Generating panel-derived widget displaying grid<br />
* Modifying mouse routines in editor<br />
* Adding new elements into configuration<br />
* Remember that grid also apply when resizing container using grid<br />
| 1 day<br />
| {{yes}}<br />
|-<br />
! Adopt new header system<br />
| style="text-align: left;" | New header generation system is now capable of generating forward declarations and list of headers splitted for pch-included and non-included. The option whether to use pch filter and/or forward declarations should be available while generating new resource<br />
| 1 day<br />
| {{yes}}<br />
|-<br />
! Add more tools<br />
| style="text-align: left;" | There are some tools which could be accessible from viasual editor:<br />
*[[Image:Chk.png]] wxColourDialog<br />
*[[Image:Chk.png]] wxDirDialog<br />
*[[Image:Chk.png]] wxFileDialog<br />
*[[Image:Nop.png]] wxFindReplaceDialog<br />
*[[Image:Chk.png]] wxMultiChoiceDialog<br />
*[[Image:Nop.png]] wxSingleChoiceDialog<br />
*[[Image:Nop.png]] wxTextEntryDialog<br />
*[[Image:Nop.png]] wxPasswordEntryDialog<br />
*[[Image:Nop.png]] wxFontDialog<br />
*[[Image:Nop.png]] wxPageSetupDialog<br />
*[[Image:Nop.png]] wxPringDialog<br />
*[[Image:Nop.png]] wxProgressDialog<br />
*[[Image:Nop.png]] wxMessageDialog<br />
*[[Image:Nop.png]] wxSymbolPickerDialog<br />
*[[Image:Nop.png]] wxRichTextFormattingDialog<br />
*[[Image:Nop.png]] wxFTP<br />
*[[Image:Nop.png]] wxHTTP<br />
*[[Image:Nop.png]] wxDialUpManager<br />
*[[Image:Nop.png]] wxSocketClient (?)<br />
| 1 week<br />
| {{no}}<br />
|-<br />
! Fix dragbox bug<br />
| style="text-align: left;" | Sometimes on linux when resource is more complicated, drag boxes are placed in invalid position. It looks like the positions are calculated before main panel (the one which not yet belongs to the resource or the main resource's panel) is shifted using it's sizer.<br />
| 1 day<br />
| {{no}}<br />
|-<br />
! Add ability to fetch buttons from wxStdDialogButtonSizer<br />
| style="text-align: left;" | It should be quite easy to fetch buttons from this sizer, it may be done using FindWindow when using XRC (by using OnBuildXRCFetchingCode) and simply by storing pointers when using source mode (just by assigning pointers when generating <br />
| 1 day<br />
| {{no}}<br />
|-<br />
! Virtual-function events<br />
| style="text-align: left;" | Some items provide functinalities in derived classes only by calling virtual functions. Such functions could be threated as some kind of events and could be generated automatically by wxSmith (by automatically generating some derived class)<br />
| 1 week<br />
| {{no}}<br />
|-<br />
! Include one resource in another<br />
| style="text-align: left;" | There could be some special item which would allow adding other resources (like wxPanels) into another ones. Curently it msut be done by making some tricks like changing "Class name" or by using custom item. wxSmith could really easily integrate with such resources. The only problem I see here is that there's changing list of constructor arguments which can be passed into other resources and wxSmith won't be able to guess values for custom arguments - but this can be implemented similarily to generation of custom resources - by providing some kond of script-code where all arguments would be provided by the user<br />
| 3 days<br />
| {{no}}<br />
|-<br />
! Using //{ and //} comments to allow folding of wxSmith code<br />
| style="text-align: left;" | In resouce wizard there could be an option to automatically add //{ and //} comments which notify wxScintilla that the block should be foldable. One of following solutions could be used here:<br />
<br />
Firts solution:<br />
<br />
//{//(*CodeName<br />
...<br />
//*)//}<br />
<br />
It will require changing detection of block folding<br />
<br />
Second solution:<br />
<br />
//{ wxSmith-generated code<br />
//(*CodeName<br />
..<br />
//*)<br />
//}<br />
<br />
Third solution:<br />
<br />
//{ wxSmith-generated code<br />
//(*CodeName<br />
..<br />
//*)//}<br />
<br />
| 1 hour<br />
| {{no}}<br />
|-<br />
|}</div>Byohttps://wiki.codeblocks.org/index.php?title=WxSmith_tutorial:_Accessing_items_in_resource&diff=5312WxSmith tutorial: Accessing items in resource2008-01-19T17:19:31Z<p>Byo: /* Warning: Unfinished */</p>
<hr />
<div>= 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>Byohttps://wiki.codeblocks.org/index.php?title=WxSmith_tutorial:_Accessing_items_in_resource&diff=5311WxSmith tutorial: Accessing items in resource2008-01-19T17:18:57Z<p>Byo: </p>
<hr />
<div>= Warning: Unfinished =<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>Byohttps://wiki.codeblocks.org/index.php?title=File:Wxs_tut06_002.png&diff=5310File:Wxs tut06 002.png2008-01-19T17:00:10Z<p>Byo: </p>
<hr />
<div></div>Byohttps://wiki.codeblocks.org/index.php?title=WxSmith_tutorial:_Accessing_items_in_resource&diff=5309WxSmith tutorial: Accessing items in resource2008-01-19T16:37:39Z<p>Byo: /* Changing label in wxStaticText */</p>
<hr />
<div>= Warning: Unfinished =<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.</div>Byohttps://wiki.codeblocks.org/index.php?title=WxSmith_tutorial:_Accessing_items_in_resource&diff=5308WxSmith tutorial: Accessing items in resource2008-01-19T16:36:26Z<p>Byo: /* Accessing items through members of resource class */</p>
<hr />
<div>= Warning: Unfinished =<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.</div>Byohttps://wiki.codeblocks.org/index.php?title=WxSmith_tutorial:_Accessing_items_in_resource&diff=5307WxSmith tutorial: Accessing items in resource2008-01-19T16:36:07Z<p>Byo: New page: = Warning: Unfinished = = Accessing items in resource = 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 r...</p>
<hr />
<div>= Warning: Unfinished =<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 />
<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.</div>Byohttps://wiki.codeblocks.org/index.php?title=File:Wxs_tut06_001.png&diff=5306File:Wxs tut06 001.png2008-01-19T15:39:51Z<p>Byo: </p>
<hr />
<div></div>Byohttps://wiki.codeblocks.org/index.php?title=WxSmith_tutorials&diff=5305WxSmith tutorials2008-01-19T15:30:18Z<p>Byo: /* wxSmith and wxWidgets basics */</p>
<hr />
<div>[[Category:wxSmith Documentation]]<br />
<br />
Welcome to wxSmith tutorials page. Here you can learn how to create GUI applications for wxWidgets platform using wxSmith. At the beginning we will start with some basic tutorials which will show what can you do with wxSmith and how you can create simple applications. I hope that there will also be some advanced tutorials for those who know wxWidgets very well.<br />
<br />
=== wxSmith and wxWidgets basics ===<br />
<br />
On this tutorials you will learn basic things about wxSmith and wxWidgets.<br />
<br />
* Tutorial 1: [[wxSmith tutorial: Hello world|Hello world]]<br />
* Tutorial 2: [[wxsmith tutorial: Working with items|Working with items]]<br />
* Tutorial 3: [[wxSmith tutorial: Building more complex window|Building more complex window]]<br />
* Tutorial 4: [[wxSmith tutorial: Working with multiple resources|Working with multiple resources]]<br />
* Tutorial 5: [[wxSmith tutorial: Using wxPanel resources|Using wxPanel resources]]<br />
* Tutorial 6: [[wxSmith tutorial: Accessing items in resource|Accessing items in resource]]</div>Byohttps://wiki.codeblocks.org/index.php?title=WxSmith_tutorials&diff=5304WxSmith tutorials2008-01-19T15:14:47Z<p>Byo: /* wxSmith and wxWidgets basics */</p>
<hr />
<div>[[Category:wxSmith Documentation]]<br />
<br />
Welcome to wxSmith tutorials page. Here you can learn how to create GUI applications for wxWidgets platform using wxSmith. At the beginning we will start with some basic tutorials which will show what can you do with wxSmith and how you can create simple applications. I hope that there will also be some advanced tutorials for those who know wxWidgets very well.<br />
<br />
=== wxSmith and wxWidgets basics ===<br />
<br />
On this tutorials you will learn basic things about wxSmith and wxWidgets.<br />
<br />
* Tutorial 1: [[wxSmith tutorial: Hello world|Hello world]]<br />
* Tutorial 2: [[wxsmith tutorial: Working with items|Working with items]]<br />
* Tutorial 3: [[wxSmith tutorial: Building more complex window|Building more complex window]]<br />
* Tutorial 4: [[wxSmith tutorial: Accessing items in resource|Accessing items in resource]]<br />
* Tutorial 5: [[wxSmith tutorial: Working with multiple resources|Working with multiple resources]]</div>Byohttps://wiki.codeblocks.org/index.php?title=WxSmith_tutorial:_Working_with_multiple_resources&diff=5295WxSmith tutorial: Working with multiple resources2008-01-18T23:17:11Z<p>Byo: New page: = Working with multiple resources = 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...</p>
<hr />
<div>= 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>Byohttps://wiki.codeblocks.org/index.php?title=File:Wxs_tut04_006.png&diff=5294File:Wxs tut04 006.png2008-01-18T22:40:53Z<p>Byo: </p>
<hr />
<div></div>Byohttps://wiki.codeblocks.org/index.php?title=File:Wxs_tut04_005.png&diff=5293File:Wxs tut04 005.png2008-01-18T22:18:57Z<p>Byo: </p>
<hr />
<div></div>Byohttps://wiki.codeblocks.org/index.php?title=File:Wxs_tut04_004.png&diff=5292File:Wxs tut04 004.png2008-01-18T21:57:03Z<p>Byo: </p>
<hr />
<div></div>Byohttps://wiki.codeblocks.org/index.php?title=File:Wxs_tut04_003.png&diff=5291File:Wxs tut04 003.png2008-01-18T21:48:41Z<p>Byo: </p>
<hr />
<div></div>Byohttps://wiki.codeblocks.org/index.php?title=File:Wxs_tut04_002.png&diff=5290File:Wxs tut04 002.png2008-01-18T21:34:15Z<p>Byo: </p>
<hr />
<div></div>Byohttps://wiki.codeblocks.org/index.php?title=File:Wxs_tut04_001.png&diff=5289File:Wxs tut04 001.png2008-01-18T21:24:48Z<p>Byo: </p>
<hr />
<div></div>Byohttps://wiki.codeblocks.org/index.php?title=WxSmith_tutorials&diff=5288WxSmith tutorials2008-01-18T20:44:21Z<p>Byo: /* wxSmith and wxWidgets basics */</p>
<hr />
<div>[[Category:wxSmith Documentation]]<br />
<br />
Welcome to wxSmith tutorials page. Here you can learn how to create GUI applications for wxWidgets platform using wxSmith. At the beginning we will start with some basic tutorials which will show what can you do with wxSmith and how you can create simple applications. I hope that there will also be some advanced tutorials for those who know wxWidgets very well.<br />
<br />
=== wxSmith and wxWidgets basics ===<br />
<br />
On this tutorials you will learn basic things about wxSmith and wxWidgets.<br />
<br />
* Tutorial 1: [[wxSmith tutorial: Hello world|Hello world]]<br />
* Tutorial 2: [[wxsmith tutorial: Working with items|Working with items]]<br />
* Tutorial 3: [[wxSmith tutorial: Building more complex window|Building more complex window]]<br />
* Tutorial 4: [[wxSmith tutorial: Working with multiple resources|Working with multiple resources]]</div>Byohttps://wiki.codeblocks.org/index.php?title=WxSmith_tutorial:_Building_more_complex_window&diff=5287WxSmith tutorial: Building more complex window2008-01-18T20:43:12Z<p>Byo: /* Warning: unfinished */</p>
<hr />
<div>[[Category:wxSmith Documentation]]<br />
<br />
<br />
<br />
= Building more complex window =<br />
<br />
Hi, in this tutorial I'll sow you some example of more complex window. Actually it would look complex when you start working with wxSmith. After writing few applications you will probably build few resources with this or even higher complexity so don't be scared. I'm working with wxSmith almost every day (it's really the best way to find bugs and discover nice improovements and that's what I should do as it's creator ;)) and although it may look comlex at the beginning, you can quickly get comfortable with it.<br />
<br />
I also want you to know that as I'm writing the beginning of this tutorial, I'm also beginning of writing the application - I didn't prepared ready solution since I would like to show process of creating window in natural way (maybe even with some mistakes), so while writing the tutorial I'll also create the application.<br />
<br />
We will start with empty frame - if you've read previous tutorials you shouold create one without problems.<br />
<br />
== First task - some basic concept ==<br />
<br />
My proposition for exmple application would be something to manage colleciton of CD-roms. So at the beginning we should realize what should be presented at the main window. Let's say that we would have most informations at the main window (although it may not be a very good assumption, it would help to show creation of more complex resources).<br />
<br />
I would like to have some list of CD-roms on the left and some details of selected CD-rom on the right. So basically we have two regions in our window: one with the list and one with the details. I'd like also to use sizers because the application should be cross-platform and main window should be resizable.<br />
<br />
== Building skeleton ==<br />
<br />
If want the application to look nice on both windows and linux, we should do some trick presented in the first tutorial - we had to add extra wxPanel into frame to make the background better. Let's to the same thing here:<br />
<br />
* First add wxBoxSizer directly into resource<br />
* Add wxPanel into that sizer<br />
* Set size of border to 0 to make the panel cover entine window<br />
<br />
Now we should have some this result:<br />
<br />
[[Image:wxs_tut03_001.png]]<br />
<br />
Now let's add wxBoxSizer into it - this sizer will manage out two main regions. After that the tree structure should look like this:<br />
<br />
[[Image:wxs_tut03_002.png]]<br />
<br />
Now we can start filling those two regions - each one may have only one item (so the sizer we've just added will manage them). Usually in such sutiatuion I use wxStaticBoxSizer because we can mark regions and put some name for them. So let's add two wxStaticBoxSizer-s into the window. Be carefull while adding the second one because you may add it into the first region - always remember that parent for new items is always the item totally covered with blue:<br />
<br />
[[Image:wxs_tut03_003.png]]<br />
<br />
To add second sizer properly you must click on the border surrounding the first one just like on the picture. Note that now the resource is small but it will change when we will add some items into regions.<br />
<br />
<br />
== Building the '''List of CDs''' region ==<br />
<br />
Ok, now let's add some item which will show list of CDs. We can use wxListBox here:<br />
<br />
[[Image:wxs_tut03_004.png]]<br />
<br />
The list is rather small so let's resize it using drag-boxes to something bigger and higher:<br />
<br />
[[Image:wxs_tut03_005.png]]<br />
<br />
Ok, but the second sizer did not resize. That's right since we didn't turn on it's '''Expand''' flag. To do this let's click on the second sizer and check it's '''Expand'' property:<br />
<br />
[[Image:wxs_tut03_006.png]]<br />
<br />
Now we can change labels of regions since they are fully visible now. To do this click on each region's sizer and change the '''Label''' property:<br />
<br />
[[Image:wxs_tut03_007.png]]<br />
<br />
Ok but we would like to have ability to add and delete selected cd - we will insert two buttons for this purpose in the first region. To add the button choose it from palette and add into the sizer. Note that we can now point wxListBox item - it can not have children so wxSmith will try to add new item before or after it. After adding button we would have such result:<br />
<br />
[[Image:wxs_tut03_008.png]]<br />
<br />
Hmm, the button should be under the list, not next to it. wxStaticBoxSizer did align items as it should - by default it aligns them in horizontal line. To change the direction to vertical, you can change the '''Orientation''' property of wxStaticBoxSizer. But before we change it let's predict one more thing. I would like to have two buttons instead of only one and I'd like them to be aligned horizontally. Since wxStaticBox will be changed to vertical mode, we will have to use another sizer used only for buttons. So let's add wxBoxSizer right after the list and before button:<br />
<br />
[[Image:wxs_tut03_009.png]]<br />
<br />
Now let's change '''Orientation''' of the wxStaticBoxSizer to vertical. After changing we have following result:<br />
<br />
[[Image:wxs_tut03_010.png]]<br />
<br />
We can see that something's wrong here. The wxBoxSizer is abnormally stretched and if we scroll the editor we can see that the same goes to button. We said in previous tutorial that wxBoxSizer an wxStaticBoxSizer are trying to keep same size of items in one direction - that's what happened here. wxStaticBoxSizer used the highest item (list of CDs) and applied this height into all managed items. How to disable it? By setting '''Proportion''' property of both wxBoxSizer and wxButton to 0. This will notify that those items shouldn't be used in height calculations:<br />
<br />
[[Image:wxs_tut03_011.png]]<br />
<br />
<br />
Now let's move the button into the wxBoxSizer - you can very easily do it by clickong on the button and dragging it into the sizer. After that we can add second button next to the first one:<br />
<br />
[[Image:wxs_tut03_012.png]]<br />
<br />
Nowe we can see that the list don't have '''Expand''' property set (otherwise it would be almost as wide as the region.<br />
<br />
Now I'd like to see how current work does look in the application. We could simply run it (F9) or by pressing the preview button on the right part of wxSmith editor:<br />
<br />
[[Image:wxs_tut03_013.png]]<br />
<br />
(If you run application you will see that there's menu and statusbar, on the preview it won't show, wxSmith still misses few features ;) )<br />
<br />
Our window looks good, not perfect but let's leave some polishing for later and fill the CD details region.<br />
<br />
== Building '''CD details''' region ==<br />
<br />
Inside CD details I'd like to have description of CD:<br />
* Type (Music/Program/Backup/Other)<br />
* Title<br />
* Artist/Author<br />
* Date of release<br />
* Description<br />
<br />
For such list we would need some grid sizer. Ok, but the region has wxStaticBoxSizer which align items only in one line. To overcome this limitation we can just add another sizer into wxStaticBoxSizer and use new one as the grid. From two available sizers I suggest wxFlexGridSizer (wxGridSizer would force all cells to have same size which wouldn't look good because row with description may need some more space than others). So let's add new sizer:<br />
* Add wxFlexGridSizer into wxStaticBoxSizer<br />
* Check '''Expand''' property of new item<br />
* Set '''Border Size''' to 0 to avoid some unwanted border.<br />
<br />
=== Adding items ===<br />
<br />
Data presented here should be shown in two columns - first for the label and second for value so let's change the '''Cols''' property to 2. And now it's time to add the content. For labels we will use wxStaticText and for the value we will use different items:<br />
* wxChoice for Type<br />
* wxTextCtrl for Title, Artist/Author and Description<br />
* wxDatePickerCtrl for Date of release<br />
<br />
After adding items we should have following view:<br />
<br />
[[Image:wxs_tut03_014.png]]<br />
<br />
<br />
Hmm, as I've said at the beginning - I didn't prepared anything before writing this tutorial. And guess what. It looks like wxDatePickerCtrl is broken on linux and sometimes crashes C::B (I didn't check on windows), don't know yet whether it's in wxWidgets or wxSmith - I'll have to investigate it. So we will have to change wxDatePickerCtrl to something else or remove it.<br />
<br />
There's alternative for wxDatePickerCtrl - wxCallendarCtrl so first let's try to replace wxDatePickerCtrl. First we will have to remove wrong item (by using 'delete' key or by pressing 'X' button on the right side of the editor). After the change we can see that generated callendar is quite but according to other items in this region. We can shrink it a little bit by checking '''wxCAL_SEQUENTIAL_MONTH_SELECTION''' inside the '''Style''' property but it will make the item harder to navigate. We can additionally set '''wxSUNKEN_BORDER''' style to add some nice border around the callendar. Ok, not perfect but acceptable ;)<br />
<br />
Now we have this screen:<br />
<br />
[[Image:wxs_tut03_015.png]]<br />
<br />
=== Customizing and adjusting items ===<br />
<br />
<br />
Ok, it looks like we have few things to do now:<br />
* First is to check '''Expand''' property for the first region since (it didn't expand when the second region increased height)<br />
* Second is to set proper labels for values in '''CD details''' region<br />
* Third is to check '''Expand''' property for all items with values in same region <br />
* Fourth thing is to adjust items used to edit values in '''CD details''' region<br />
<br />
First three tasks are quite easy and I'll leave them to you :)<br />
<br />
Fourth task will require few new things so I'll describe it better:<br />
<br />
First let's remove text from text boxes - it's set by default but it would be better to have empty text by default. Text can be changed by modifying '''Text''' property so you should do this very quickly.<br />
<br />
Now we have to set some values which could be choosen from '''Type''' value. It's done by editing '''Choices''' property of wxChoice. This is more advanced value consisting of few strings to entering it inside one line of text could be hard. Because of that, instead of text, there's a button on the right side. When you click it, new window will pop-up where you can enter choices:<br />
<br />
Music<br />
Program<br />
Backup<br />
Other<br />
<br />
== Let's check how does the window resize ==<br />
<br />
We have the first version of our window. But it's not the end of work. If we want it to be user-friendly, it should give ability to resize. We can check it by either showing preview or building and running application. The latter is preffered since it may produce better results. If the window will show, we should experiment by resizing it:<br />
<br />
[[Image:wxs_tut03_016.png]]<br />
<br />
<br />
We can see two wrong things in this window:<br />
* Regions did not expand vertically and stay centered<br />
* Content of second region did not react for the resize<br />
<br />
The first problem should be cuased by some missing '''Expand''' property so let's find it.<br />
<br />
First we should check if regions have '''Expand''' property set: yes they have so this is not the problem. Generally in such situations we should continue checking in parent item - this is wxBoxSizer which always expand. Next there's wxPanel we used to make nice background and voila: this one does miss the '''Expand''' property. So let's check it and test the result again and it works fine. <br />
<br />
Now the second issue. Content inside '''CD details''' pane was based on wxFlexGridSizer. If you look into previous tutorial you may find out that this sizer has special property called '''Growable cols'''. Using this property we can set columns which should resize. I'd like the column with values to grow (we don't need more space for labels, dont we? ;) ) so let's set the '''Growable cols''' to '''"1"''' (idexes are 0-based). Note that you may quickly find the wxFlexGridSizer by ooking into resource tree - we have only one such sizer in our project.<br />
<br />
Now we have some more correct results:<br />
<br />
[[Image:wxs_tut03_017.png]]<br />
<br />
<br />
<br />
== Continue polishing the window ==<br />
<br />
<br />
As I look into our window I see that I left few things on the first region. Buttons don't have new labels and there's to much space between them and the list so we can update those things right now.<br />
<br />
As usual I'll leave changing the Labels to you - those buttons should be called '''Add''' and '''Delete'''. And now let's remove the wasted space.<br />
<br />
The space is added because each item inside sizers may have extra border. By default it's set to 5 pixels so if we remove the border around buttons we would have more free space. But than the buttons won't have any space between them.<br />
<br />
To overcome this problem we could use another property related to border also called '''Border''' (jay, I have to fix the naming before someone notice it) which expands to few check-boxes. By checking or unchecking them we can enable or disable border at some item's edge. So if we remove top/bottom/left edge borders of the first button and top/bottom/right edge borders of the second button we would remove extra space but buttons will still have some gap between them. Here's how the property should look like for the first button:<br />
<br />
[[Image:wxs_tut03_018.png]]<br />
<br />
<br />
<br />
== Final words ==<br />
<br />
<br />
Here we reach the end of this tutorial. Of course the window we've built is not in it's final shape and it could be adjusted - for example we could add some list remembering when and who borrowed the CD from us and who has it now, we could add some searching and so on. But to keep this tutorial quite short, I've decided to leave all those upgrades to you. I hope that you've learned something new and interesting here. Good bye and see you in next tutorial :)</div>Byohttps://wiki.codeblocks.org/index.php?title=WxSmith_tutorial:_Building_more_complex_window&diff=5286WxSmith tutorial: Building more complex window2008-01-18T20:41:49Z<p>Byo: /* Building more complex window */</p>
<hr />
<div>[[Category:wxSmith Documentation]]<br />
<br />
= Warning: unfinished =<br />
<br />
= Building more complex window =<br />
<br />
Hi, in this tutorial I'll sow you some example of more complex window. Actually it would look complex when you start working with wxSmith. After writing few applications you will probably build few resources with this or even higher complexity so don't be scared. I'm working with wxSmith almost every day (it's really the best way to find bugs and discover nice improovements and that's what I should do as it's creator ;)) and although it may look comlex at the beginning, you can quickly get comfortable with it.<br />
<br />
I also want you to know that as I'm writing the beginning of this tutorial, I'm also beginning of writing the application - I didn't prepared ready solution since I would like to show process of creating window in natural way (maybe even with some mistakes), so while writing the tutorial I'll also create the application.<br />
<br />
We will start with empty frame - if you've read previous tutorials you shouold create one without problems.<br />
<br />
== First task - some basic concept ==<br />
<br />
My proposition for exmple application would be something to manage colleciton of CD-roms. So at the beginning we should realize what should be presented at the main window. Let's say that we would have most informations at the main window (although it may not be a very good assumption, it would help to show creation of more complex resources).<br />
<br />
I would like to have some list of CD-roms on the left and some details of selected CD-rom on the right. So basically we have two regions in our window: one with the list and one with the details. I'd like also to use sizers because the application should be cross-platform and main window should be resizable.<br />
<br />
== Building skeleton ==<br />
<br />
If want the application to look nice on both windows and linux, we should do some trick presented in the first tutorial - we had to add extra wxPanel into frame to make the background better. Let's to the same thing here:<br />
<br />
* First add wxBoxSizer directly into resource<br />
* Add wxPanel into that sizer<br />
* Set size of border to 0 to make the panel cover entine window<br />
<br />
Now we should have some this result:<br />
<br />
[[Image:wxs_tut03_001.png]]<br />
<br />
Now let's add wxBoxSizer into it - this sizer will manage out two main regions. After that the tree structure should look like this:<br />
<br />
[[Image:wxs_tut03_002.png]]<br />
<br />
Now we can start filling those two regions - each one may have only one item (so the sizer we've just added will manage them). Usually in such sutiatuion I use wxStaticBoxSizer because we can mark regions and put some name for them. So let's add two wxStaticBoxSizer-s into the window. Be carefull while adding the second one because you may add it into the first region - always remember that parent for new items is always the item totally covered with blue:<br />
<br />
[[Image:wxs_tut03_003.png]]<br />
<br />
To add second sizer properly you must click on the border surrounding the first one just like on the picture. Note that now the resource is small but it will change when we will add some items into regions.<br />
<br />
<br />
== Building the '''List of CDs''' region ==<br />
<br />
Ok, now let's add some item which will show list of CDs. We can use wxListBox here:<br />
<br />
[[Image:wxs_tut03_004.png]]<br />
<br />
The list is rather small so let's resize it using drag-boxes to something bigger and higher:<br />
<br />
[[Image:wxs_tut03_005.png]]<br />
<br />
Ok, but the second sizer did not resize. That's right since we didn't turn on it's '''Expand''' flag. To do this let's click on the second sizer and check it's '''Expand'' property:<br />
<br />
[[Image:wxs_tut03_006.png]]<br />
<br />
Now we can change labels of regions since they are fully visible now. To do this click on each region's sizer and change the '''Label''' property:<br />
<br />
[[Image:wxs_tut03_007.png]]<br />
<br />
Ok but we would like to have ability to add and delete selected cd - we will insert two buttons for this purpose in the first region. To add the button choose it from palette and add into the sizer. Note that we can now point wxListBox item - it can not have children so wxSmith will try to add new item before or after it. After adding button we would have such result:<br />
<br />
[[Image:wxs_tut03_008.png]]<br />
<br />
Hmm, the button should be under the list, not next to it. wxStaticBoxSizer did align items as it should - by default it aligns them in horizontal line. To change the direction to vertical, you can change the '''Orientation''' property of wxStaticBoxSizer. But before we change it let's predict one more thing. I would like to have two buttons instead of only one and I'd like them to be aligned horizontally. Since wxStaticBox will be changed to vertical mode, we will have to use another sizer used only for buttons. So let's add wxBoxSizer right after the list and before button:<br />
<br />
[[Image:wxs_tut03_009.png]]<br />
<br />
Now let's change '''Orientation''' of the wxStaticBoxSizer to vertical. After changing we have following result:<br />
<br />
[[Image:wxs_tut03_010.png]]<br />
<br />
We can see that something's wrong here. The wxBoxSizer is abnormally stretched and if we scroll the editor we can see that the same goes to button. We said in previous tutorial that wxBoxSizer an wxStaticBoxSizer are trying to keep same size of items in one direction - that's what happened here. wxStaticBoxSizer used the highest item (list of CDs) and applied this height into all managed items. How to disable it? By setting '''Proportion''' property of both wxBoxSizer and wxButton to 0. This will notify that those items shouldn't be used in height calculations:<br />
<br />
[[Image:wxs_tut03_011.png]]<br />
<br />
<br />
Now let's move the button into the wxBoxSizer - you can very easily do it by clickong on the button and dragging it into the sizer. After that we can add second button next to the first one:<br />
<br />
[[Image:wxs_tut03_012.png]]<br />
<br />
Nowe we can see that the list don't have '''Expand''' property set (otherwise it would be almost as wide as the region.<br />
<br />
Now I'd like to see how current work does look in the application. We could simply run it (F9) or by pressing the preview button on the right part of wxSmith editor:<br />
<br />
[[Image:wxs_tut03_013.png]]<br />
<br />
(If you run application you will see that there's menu and statusbar, on the preview it won't show, wxSmith still misses few features ;) )<br />
<br />
Our window looks good, not perfect but let's leave some polishing for later and fill the CD details region.<br />
<br />
== Building '''CD details''' region ==<br />
<br />
Inside CD details I'd like to have description of CD:<br />
* Type (Music/Program/Backup/Other)<br />
* Title<br />
* Artist/Author<br />
* Date of release<br />
* Description<br />
<br />
For such list we would need some grid sizer. Ok, but the region has wxStaticBoxSizer which align items only in one line. To overcome this limitation we can just add another sizer into wxStaticBoxSizer and use new one as the grid. From two available sizers I suggest wxFlexGridSizer (wxGridSizer would force all cells to have same size which wouldn't look good because row with description may need some more space than others). So let's add new sizer:<br />
* Add wxFlexGridSizer into wxStaticBoxSizer<br />
* Check '''Expand''' property of new item<br />
* Set '''Border Size''' to 0 to avoid some unwanted border.<br />
<br />
=== Adding items ===<br />
<br />
Data presented here should be shown in two columns - first for the label and second for value so let's change the '''Cols''' property to 2. And now it's time to add the content. For labels we will use wxStaticText and for the value we will use different items:<br />
* wxChoice for Type<br />
* wxTextCtrl for Title, Artist/Author and Description<br />
* wxDatePickerCtrl for Date of release<br />
<br />
After adding items we should have following view:<br />
<br />
[[Image:wxs_tut03_014.png]]<br />
<br />
<br />
Hmm, as I've said at the beginning - I didn't prepared anything before writing this tutorial. And guess what. It looks like wxDatePickerCtrl is broken on linux and sometimes crashes C::B (I didn't check on windows), don't know yet whether it's in wxWidgets or wxSmith - I'll have to investigate it. So we will have to change wxDatePickerCtrl to something else or remove it.<br />
<br />
There's alternative for wxDatePickerCtrl - wxCallendarCtrl so first let's try to replace wxDatePickerCtrl. First we will have to remove wrong item (by using 'delete' key or by pressing 'X' button on the right side of the editor). After the change we can see that generated callendar is quite but according to other items in this region. We can shrink it a little bit by checking '''wxCAL_SEQUENTIAL_MONTH_SELECTION''' inside the '''Style''' property but it will make the item harder to navigate. We can additionally set '''wxSUNKEN_BORDER''' style to add some nice border around the callendar. Ok, not perfect but acceptable ;)<br />
<br />
Now we have this screen:<br />
<br />
[[Image:wxs_tut03_015.png]]<br />
<br />
=== Customizing and adjusting items ===<br />
<br />
<br />
Ok, it looks like we have few things to do now:<br />
* First is to check '''Expand''' property for the first region since (it didn't expand when the second region increased height)<br />
* Second is to set proper labels for values in '''CD details''' region<br />
* Third is to check '''Expand''' property for all items with values in same region <br />
* Fourth thing is to adjust items used to edit values in '''CD details''' region<br />
<br />
First three tasks are quite easy and I'll leave them to you :)<br />
<br />
Fourth task will require few new things so I'll describe it better:<br />
<br />
First let's remove text from text boxes - it's set by default but it would be better to have empty text by default. Text can be changed by modifying '''Text''' property so you should do this very quickly.<br />
<br />
Now we have to set some values which could be choosen from '''Type''' value. It's done by editing '''Choices''' property of wxChoice. This is more advanced value consisting of few strings to entering it inside one line of text could be hard. Because of that, instead of text, there's a button on the right side. When you click it, new window will pop-up where you can enter choices:<br />
<br />
Music<br />
Program<br />
Backup<br />
Other<br />
<br />
== Let's check how does the window resize ==<br />
<br />
We have the first version of our window. But it's not the end of work. If we want it to be user-friendly, it should give ability to resize. We can check it by either showing preview or building and running application. The latter is preffered since it may produce better results. If the window will show, we should experiment by resizing it:<br />
<br />
[[Image:wxs_tut03_016.png]]<br />
<br />
<br />
We can see two wrong things in this window:<br />
* Regions did not expand vertically and stay centered<br />
* Content of second region did not react for the resize<br />
<br />
The first problem should be cuased by some missing '''Expand''' property so let's find it.<br />
<br />
First we should check if regions have '''Expand''' property set: yes they have so this is not the problem. Generally in such situations we should continue checking in parent item - this is wxBoxSizer which always expand. Next there's wxPanel we used to make nice background and voila: this one does miss the '''Expand''' property. So let's check it and test the result again and it works fine. <br />
<br />
Now the second issue. Content inside '''CD details''' pane was based on wxFlexGridSizer. If you look into previous tutorial you may find out that this sizer has special property called '''Growable cols'''. Using this property we can set columns which should resize. I'd like the column with values to grow (we don't need more space for labels, dont we? ;) ) so let's set the '''Growable cols''' to '''"1"''' (idexes are 0-based). Note that you may quickly find the wxFlexGridSizer by ooking into resource tree - we have only one such sizer in our project.<br />
<br />
Now we have some more correct results:<br />
<br />
[[Image:wxs_tut03_017.png]]<br />
<br />
<br />
<br />
== Continue polishing the window ==<br />
<br />
<br />
As I look into our window I see that I left few things on the first region. Buttons don't have new labels and there's to much space between them and the list so we can update those things right now.<br />
<br />
As usual I'll leave changing the Labels to you - those buttons should be called '''Add''' and '''Delete'''. And now let's remove the wasted space.<br />
<br />
The space is added because each item inside sizers may have extra border. By default it's set to 5 pixels so if we remove the border around buttons we would have more free space. But than the buttons won't have any space between them.<br />
<br />
To overcome this problem we could use another property related to border also called '''Border''' (jay, I have to fix the naming before someone notice it) which expands to few check-boxes. By checking or unchecking them we can enable or disable border at some item's edge. So if we remove top/bottom/left edge borders of the first button and top/bottom/right edge borders of the second button we would remove extra space but buttons will still have some gap between them. Here's how the property should look like for the first button:<br />
<br />
[[Image:wxs_tut03_018.png]]<br />
<br />
<br />
<br />
== Final words ==<br />
<br />
<br />
Here we reach the end of this tutorial. Of course the window we've built is not in it's final shape and it could be adjusted - for example we could add some list remembering when and who borrowed the CD from us and who has it now, we could add some searching and so on. But to keep this tutorial quite short, I've decided to leave all those upgrades to you. I hope that you've learned something new and interesting here. Good bye and see you in next tutorial :)</div>Byohttps://wiki.codeblocks.org/index.php?title=WxSmith_tutorial:_Building_more_complex_window&diff=5254WxSmith tutorial: Building more complex window2008-01-09T22:59:38Z<p>Byo: /* Continue polishing the window */</p>
<hr />
<div>[[Category:wxSmith Documentation]]<br />
<br />
= Warning: unfinished =<br />
<br />
= Building more complex window =<br />
<br />
Hi, in this tutorial I'll sow you some example of more complex window. Actually it would look complex when you start working with wxSmith. After writing few applications you will probably build few resources with this or even higher complexity so don't be scared. I'm working with wxSmith almost every day (it's really the best way to find bugs and discover nice improovements and that's what I should do as it's creator ;)) and athough edition may look comlex at the beginning, it's not hard to get used to it.<br />
<br />
I also want you to know that as I'm writing the beginning of this tutorial, I'm also beginning of writing the application - I didn't prepared ready solution since I would like to show process of creating window in really natural way (maybe even with some mistakes), so while writing the tutorial I'll also create the application.<br />
<br />
We will start with empty frame - if you've read previous tutorials you shouold create one without problems.<br />
<br />
== First task - some basic concept ==<br />
<br />
My proposition for exmple application would be something to manage colleciton of CD-roms. So at the beginning we should realize what should be presented at the main window. Let's say that we would have most informations at the main window (although it may not be a very good assumption, it would help to show creation of more complex resources).<br />
<br />
I would like to have some list of CD-roms on the left and some details of selected CD-rom on the right. So basically we have two regions in our window: one with the list and one with the details. I'd like also to use sizers because the application should be cross-platform and main window should be resizable.<br />
<br />
== Building skeleton ==<br />
<br />
If want the application to look nice on both windows and linux, we should do some trick presented in the first tutorial - we had to add extra wxPanel into frame to make the background better. Let's to the same thing here:<br />
<br />
* First add wxBoxSizer directly into resource<br />
* Add wxPanel into that sizer<br />
* Set size of border to 0 to make the panel cover entine window<br />
<br />
Now we should have some this result:<br />
<br />
[[Image:wxs_tut03_001.png]]<br />
<br />
Now let's add wxBoxSizer into it - this sizer will manage out two main regions. After that the tree structure should look like this:<br />
<br />
[[Image:wxs_tut03_002.png]]<br />
<br />
Now we can start filling those two regions - each one may have only one item (so the sizer we've just added will manage them). Usually in such sutiatuion I use wxStaticBoxSizer because we can mark regions and put some name for them. So let's add two wxStaticBoxSizer-s into the window. Be carefull while adding the second one because you may add it into the first region - always remember that parent for new items is always the item totally covered with blue:<br />
<br />
[[Image:wxs_tut03_003.png]]<br />
<br />
To add second sizer properly you must click on the border surrounding the first one just like on the picture. Note that now the resource is small but it will change when we will add some items into regions.<br />
<br />
<br />
== Building the '''List of CDs''' region ==<br />
<br />
Ok, now let's add some item which will show list of CDs. We can use wxListBox here:<br />
<br />
[[Image:wxs_tut03_004.png]]<br />
<br />
The list is rather small so let's resize it using drag-boxes to something bigger and higher:<br />
<br />
[[Image:wxs_tut03_005.png]]<br />
<br />
Ok, but the second sizer did not resize. That's right since we didn't turn on it's '''Expand''' flag. To do this let's click on the second sizer and check it's '''Expand'' property:<br />
<br />
[[Image:wxs_tut03_006.png]]<br />
<br />
Now we can change labels of regions since they are fully visible now. To do this click on each region's sizer and change the '''Label''' property:<br />
<br />
[[Image:wxs_tut03_007.png]]<br />
<br />
Ok but we would like to have ability to add and delete selected cd - we will insert two buttons for this purpose in the first region. To add the button choose it from palette and add into the sizer. Note that we can now point wxListBox item - it can not have children so wxSmith will try to add new item before or after it. After adding button we would have such result:<br />
<br />
[[Image:wxs_tut03_008.png]]<br />
<br />
Hmm, the button should be under the list, not next to it. wxStaticBoxSizer did align items as it should - by default it aligns them in horizontal line. To change the direction to vertical, you can change the '''Orientation''' property of wxStaticBoxSizer. But before we change it let's predict one more thing. I would like to have two buttons instead of only one and I'd like them to be aligned horizontally. Since wxStaticBox will be changed to vertical mode, we will have to use another sizer used only for buttons. So let's add wxBoxSizer right after the list and before button:<br />
<br />
[[Image:wxs_tut03_009.png]]<br />
<br />
Now let's change '''Orientation''' of the wxStaticBoxSizer to vertical. After changing we have following result:<br />
<br />
[[Image:wxs_tut03_010.png]]<br />
<br />
We can see that something's wrong here. The wxBoxSizer is abnormally stretched and if we scroll the editor we can see that the same goes to button. We said in previous tutorial that wxBoxSizer an wxStaticBoxSizer are trying to keep same size of items in one direction - that's what happened here. wxStaticBoxSizer used the highest item (list of CDs) and applied this height into all managed items. How to disable it? By setting '''Proportion''' property of both wxBoxSizer and wxButton to 0. This will notify that those items shouldn't be used in height calculations:<br />
<br />
[[Image:wxs_tut03_011.png]]<br />
<br />
<br />
Now let's move the button into the wxBoxSizer - you can very easily do it by clickong on the button and dragging it into the sizer. After that we can add second button next to the first one:<br />
<br />
[[Image:wxs_tut03_012.png]]<br />
<br />
Nowe we can see that the list don't have '''Expand''' property set (otherwise it would be almost as wide as the region.<br />
<br />
Now I'd like to see how current work does look in the application. We could simply run it (F9) or by pressing the preview button on the right part of wxSmith editor:<br />
<br />
[[Image:wxs_tut03_013.png]]<br />
<br />
(If you run application you will see that there's menu and statusbar, on the preview it won't show, wxSmith still misses few features ;) )<br />
<br />
Our window looks good, not perfect but let's leave some polishing for later and fill the CD details region.<br />
<br />
== Building '''CD details''' region ==<br />
<br />
Inside CD details I'd like to have description of CD:<br />
* Type (Music/Program/Backup/Other)<br />
* Title<br />
* Artist/Author<br />
* Date of release<br />
* Description<br />
<br />
For such list we would need some grid sizer. Ok, but the region has wxStaticBoxSizer which align items only in one line. To overcome this limitation we can just add another sizer into wxStaticBoxSizer and use new one as the grid. From two available sizers I suggest wxFlexGridSizer (wxGridSizer would force all cells to have same size which wouldn't look good because row with description may need some more space than others). So let's add new sizer:<br />
* Add wxFlexGridSizer into wxStaticBoxSizer<br />
* Check '''Expand''' property of new item<br />
* Set '''Border Size''' to 0 to avoid some unwanted border.<br />
<br />
=== Adding items ===<br />
<br />
Data presented here should be shown in two columns - first for the label and second for value so let's change the '''Cols''' property to 2. And now it's time to add the content. For labels we will use wxStaticText and for the value we will use different items:<br />
* wxChoice for Type<br />
* wxTextCtrl for Title, Artist/Author and Description<br />
* wxDatePickerCtrl for Date of release<br />
<br />
After adding items we should have following view:<br />
<br />
[[Image:wxs_tut03_014.png]]<br />
<br />
<br />
Hmm, as I've said at the beginning - I didn't prepared anything before writing this tutorial. And guess what. It looks like wxDatePickerCtrl is broken on linux and sometimes crashes C::B (I didn't check on windows), don't know yet whether it's in wxWidgets or wxSmith - I'll have to investigate it. So we will have to change wxDatePickerCtrl to something else or remove it.<br />
<br />
There's alternative for wxDatePickerCtrl - wxCallendarCtrl so first let's try to replace wxDatePickerCtrl. First we will have to remove wrong item (by using 'delete' key or by pressing 'X' button on the right side of the editor). After the change we can see that generated callendar is quite but according to other items in this region. We can shrink it a little bit by checking '''wxCAL_SEQUENTIAL_MONTH_SELECTION''' inside the '''Style''' property but it will make the item harder to navigate. We can additionally set '''wxSUNKEN_BORDER''' style to add some nice border around the callendar. Ok, not perfect but acceptable ;)<br />
<br />
Now we have this screen:<br />
<br />
[[Image:wxs_tut03_015.png]]<br />
<br />
=== Customizing and adjusting items ===<br />
<br />
<br />
Ok, it looks like we have few things to do now:<br />
* First is to check '''Expand''' property for the first region since (it didn't expand when the second region increased height)<br />
* Second is to set proper labels for values in '''CD details''' region<br />
* Third is to check '''Expand''' property for all items with values in same region <br />
* Fourth thing is to adjust items used to edit values in '''CD details''' region<br />
<br />
First three tasks are quite easy and I'll leave them to you :)<br />
<br />
Fourth task will require few new things so I'll describe it better:<br />
<br />
First let's remove text from text boxes - it's set by default but it would be better to have empty text by default. Text can be changed by modifying '''Text''' property so you should do this very quickly.<br />
<br />
Now we have to set some values which could be choosen from '''Type''' value. It's done by editing '''Choices''' property of wxChoice. This is more advanced value consisting of few strings to entering it inside one line of text could be hard. Because of that, instead of text, there's a button on the right side. When you click it, new window will pop-up where you can enter choices:<br />
<br />
Music<br />
Program<br />
Backup<br />
Other<br />
<br />
== Let's check how does the window resize ==<br />
<br />
We have the first version of our window. But it's not the end of work. If we want it to be user-friendly, it should give ability to resize. We can check it by either showing preview or building and running application. The latter is preffered since it may produce better results. If the window will show, we should experiment by resizing it:<br />
<br />
[[Image:wxs_tut03_016.png]]<br />
<br />
<br />
We can see two wrong things in this window:<br />
* Regions did not expand vertically and stay centered<br />
* Content of second region did not react for the resize<br />
<br />
The first problem should be cuased by some missing '''Expand''' property so let's find it.<br />
<br />
First we should check if regions have '''Expand''' property set: yes they have so this is not the problem. Generally in such situations we should continue checking in parent item - this is wxBoxSizer which always expand. Next there's wxPanel we used to make nice background and voila: this one does miss the '''Expand''' property. So let's check it and test the result again and it works fine. <br />
<br />
Now the second issue. Content inside '''CD details''' pane was based on wxFlexGridSizer. If you look into previous tutorial you may find out that this sizer has special property called '''Growable cols'''. Using this property we can set columns which should resize. I'd like the column with values to grow (we don't need more space for labels, dont we? ;) ) so let's set the '''Growable cols''' to '''"1"''' (idexes are 0-based). Note that you may quickly find the wxFlexGridSizer by ooking into resource tree - we have only one such sizer in our project.<br />
<br />
Now we have some more correct results:<br />
<br />
[[Image:wxs_tut03_017.png]]<br />
<br />
<br />
<br />
== Continue polishing the window ==<br />
<br />
<br />
As I look into our window I see that I left few things on the first region. Buttons don't have new labels and there's to much space between them and the list so we can update those things right now.<br />
<br />
As usual I'll leave changing the Labels to you - those buttons should be called '''Add''' and '''Delete'''. And now let's remove the wasted space.<br />
<br />
The space is added because each item inside sizers may have extra border. By default it's set to 5 pixels so if we remove the border around buttons we would have more free space. But than the buttons won't have any space between them.<br />
<br />
To overcome this problem we could use another property related to border also called '''Border''' (jay, I have to fix the naming before someone notice it) which expands to few check-boxes. By checking or unchecking them we can enable or disable border at some item's edge. So if we remove top/bottom/left edge borders of the first button and top/bottom/right edge borders of the second button we would remove extra space but buttons will still have some gap between them. Here's how the property should look like for the first button:<br />
<br />
[[Image:wxs_tut03_018.png]]<br />
<br />
<br />
<br />
== Final words ==<br />
<br />
<br />
Here we reach the end of this tutorial. Of course the window we've built is not in it's final shape and it could be adjusted - for example we could add some list remembering when and who borrowed the CD from us and who has it now, we could add some searching and so on. But to keep this tutorial quite short, I've decided to leave all those upgrades to you. I hope that you've learned something new and interesting here. Good bye and see you in next tutorial :)</div>Byohttps://wiki.codeblocks.org/index.php?title=WxSmith_tutorial:_Building_more_complex_window&diff=5253WxSmith tutorial: Building more complex window2008-01-09T22:42:15Z<p>Byo: /* Let's check how does the window resize */</p>
<hr />
<div>[[Category:wxSmith Documentation]]<br />
<br />
= Warning: unfinished =<br />
<br />
= Building more complex window =<br />
<br />
Hi, in this tutorial I'll sow you some example of more complex window. Actually it would look complex when you start working with wxSmith. After writing few applications you will probably build few resources with this or even higher complexity so don't be scared. I'm working with wxSmith almost every day (it's really the best way to find bugs and discover nice improovements and that's what I should do as it's creator ;)) and athough edition may look comlex at the beginning, it's not hard to get used to it.<br />
<br />
I also want you to know that as I'm writing the beginning of this tutorial, I'm also beginning of writing the application - I didn't prepared ready solution since I would like to show process of creating window in really natural way (maybe even with some mistakes), so while writing the tutorial I'll also create the application.<br />
<br />
We will start with empty frame - if you've read previous tutorials you shouold create one without problems.<br />
<br />
== First task - some basic concept ==<br />
<br />
My proposition for exmple application would be something to manage colleciton of CD-roms. So at the beginning we should realize what should be presented at the main window. Let's say that we would have most informations at the main window (although it may not be a very good assumption, it would help to show creation of more complex resources).<br />
<br />
I would like to have some list of CD-roms on the left and some details of selected CD-rom on the right. So basically we have two regions in our window: one with the list and one with the details. I'd like also to use sizers because the application should be cross-platform and main window should be resizable.<br />
<br />
== Building skeleton ==<br />
<br />
If want the application to look nice on both windows and linux, we should do some trick presented in the first tutorial - we had to add extra wxPanel into frame to make the background better. Let's to the same thing here:<br />
<br />
* First add wxBoxSizer directly into resource<br />
* Add wxPanel into that sizer<br />
* Set size of border to 0 to make the panel cover entine window<br />
<br />
Now we should have some this result:<br />
<br />
[[Image:wxs_tut03_001.png]]<br />
<br />
Now let's add wxBoxSizer into it - this sizer will manage out two main regions. After that the tree structure should look like this:<br />
<br />
[[Image:wxs_tut03_002.png]]<br />
<br />
Now we can start filling those two regions - each one may have only one item (so the sizer we've just added will manage them). Usually in such sutiatuion I use wxStaticBoxSizer because we can mark regions and put some name for them. So let's add two wxStaticBoxSizer-s into the window. Be carefull while adding the second one because you may add it into the first region - always remember that parent for new items is always the item totally covered with blue:<br />
<br />
[[Image:wxs_tut03_003.png]]<br />
<br />
To add second sizer properly you must click on the border surrounding the first one just like on the picture. Note that now the resource is small but it will change when we will add some items into regions.<br />
<br />
<br />
== Building the '''List of CDs''' region ==<br />
<br />
Ok, now let's add some item which will show list of CDs. We can use wxListBox here:<br />
<br />
[[Image:wxs_tut03_004.png]]<br />
<br />
The list is rather small so let's resize it using drag-boxes to something bigger and higher:<br />
<br />
[[Image:wxs_tut03_005.png]]<br />
<br />
Ok, but the second sizer did not resize. That's right since we didn't turn on it's '''Expand''' flag. To do this let's click on the second sizer and check it's '''Expand'' property:<br />
<br />
[[Image:wxs_tut03_006.png]]<br />
<br />
Now we can change labels of regions since they are fully visible now. To do this click on each region's sizer and change the '''Label''' property:<br />
<br />
[[Image:wxs_tut03_007.png]]<br />
<br />
Ok but we would like to have ability to add and delete selected cd - we will insert two buttons for this purpose in the first region. To add the button choose it from palette and add into the sizer. Note that we can now point wxListBox item - it can not have children so wxSmith will try to add new item before or after it. After adding button we would have such result:<br />
<br />
[[Image:wxs_tut03_008.png]]<br />
<br />
Hmm, the button should be under the list, not next to it. wxStaticBoxSizer did align items as it should - by default it aligns them in horizontal line. To change the direction to vertical, you can change the '''Orientation''' property of wxStaticBoxSizer. But before we change it let's predict one more thing. I would like to have two buttons instead of only one and I'd like them to be aligned horizontally. Since wxStaticBox will be changed to vertical mode, we will have to use another sizer used only for buttons. So let's add wxBoxSizer right after the list and before button:<br />
<br />
[[Image:wxs_tut03_009.png]]<br />
<br />
Now let's change '''Orientation''' of the wxStaticBoxSizer to vertical. After changing we have following result:<br />
<br />
[[Image:wxs_tut03_010.png]]<br />
<br />
We can see that something's wrong here. The wxBoxSizer is abnormally stretched and if we scroll the editor we can see that the same goes to button. We said in previous tutorial that wxBoxSizer an wxStaticBoxSizer are trying to keep same size of items in one direction - that's what happened here. wxStaticBoxSizer used the highest item (list of CDs) and applied this height into all managed items. How to disable it? By setting '''Proportion''' property of both wxBoxSizer and wxButton to 0. This will notify that those items shouldn't be used in height calculations:<br />
<br />
[[Image:wxs_tut03_011.png]]<br />
<br />
<br />
Now let's move the button into the wxBoxSizer - you can very easily do it by clickong on the button and dragging it into the sizer. After that we can add second button next to the first one:<br />
<br />
[[Image:wxs_tut03_012.png]]<br />
<br />
Nowe we can see that the list don't have '''Expand''' property set (otherwise it would be almost as wide as the region.<br />
<br />
Now I'd like to see how current work does look in the application. We could simply run it (F9) or by pressing the preview button on the right part of wxSmith editor:<br />
<br />
[[Image:wxs_tut03_013.png]]<br />
<br />
(If you run application you will see that there's menu and statusbar, on the preview it won't show, wxSmith still misses few features ;) )<br />
<br />
Our window looks good, not perfect but let's leave some polishing for later and fill the CD details region.<br />
<br />
== Building '''CD details''' region ==<br />
<br />
Inside CD details I'd like to have description of CD:<br />
* Type (Music/Program/Backup/Other)<br />
* Title<br />
* Artist/Author<br />
* Date of release<br />
* Description<br />
<br />
For such list we would need some grid sizer. Ok, but the region has wxStaticBoxSizer which align items only in one line. To overcome this limitation we can just add another sizer into wxStaticBoxSizer and use new one as the grid. From two available sizers I suggest wxFlexGridSizer (wxGridSizer would force all cells to have same size which wouldn't look good because row with description may need some more space than others). So let's add new sizer:<br />
* Add wxFlexGridSizer into wxStaticBoxSizer<br />
* Check '''Expand''' property of new item<br />
* Set '''Border Size''' to 0 to avoid some unwanted border.<br />
<br />
=== Adding items ===<br />
<br />
Data presented here should be shown in two columns - first for the label and second for value so let's change the '''Cols''' property to 2. And now it's time to add the content. For labels we will use wxStaticText and for the value we will use different items:<br />
* wxChoice for Type<br />
* wxTextCtrl for Title, Artist/Author and Description<br />
* wxDatePickerCtrl for Date of release<br />
<br />
After adding items we should have following view:<br />
<br />
[[Image:wxs_tut03_014.png]]<br />
<br />
<br />
Hmm, as I've said at the beginning - I didn't prepared anything before writing this tutorial. And guess what. It looks like wxDatePickerCtrl is broken on linux and sometimes crashes C::B (I didn't check on windows), don't know yet whether it's in wxWidgets or wxSmith - I'll have to investigate it. So we will have to change wxDatePickerCtrl to something else or remove it.<br />
<br />
There's alternative for wxDatePickerCtrl - wxCallendarCtrl so first let's try to replace wxDatePickerCtrl. First we will have to remove wrong item (by using 'delete' key or by pressing 'X' button on the right side of the editor). After the change we can see that generated callendar is quite but according to other items in this region. We can shrink it a little bit by checking '''wxCAL_SEQUENTIAL_MONTH_SELECTION''' inside the '''Style''' property but it will make the item harder to navigate. We can additionally set '''wxSUNKEN_BORDER''' style to add some nice border around the callendar. Ok, not perfect but acceptable ;)<br />
<br />
Now we have this screen:<br />
<br />
[[Image:wxs_tut03_015.png]]<br />
<br />
=== Customizing and adjusting items ===<br />
<br />
<br />
Ok, it looks like we have few things to do now:<br />
* First is to check '''Expand''' property for the first region since (it didn't expand when the second region increased height)<br />
* Second is to set proper labels for values in '''CD details''' region<br />
* Third is to check '''Expand''' property for all items with values in same region <br />
* Fourth thing is to adjust items used to edit values in '''CD details''' region<br />
<br />
First three tasks are quite easy and I'll leave them to you :)<br />
<br />
Fourth task will require few new things so I'll describe it better:<br />
<br />
First let's remove text from text boxes - it's set by default but it would be better to have empty text by default. Text can be changed by modifying '''Text''' property so you should do this very quickly.<br />
<br />
Now we have to set some values which could be choosen from '''Type''' value. It's done by editing '''Choices''' property of wxChoice. This is more advanced value consisting of few strings to entering it inside one line of text could be hard. Because of that, instead of text, there's a button on the right side. When you click it, new window will pop-up where you can enter choices:<br />
<br />
Music<br />
Program<br />
Backup<br />
Other<br />
<br />
== Let's check how does the window resize ==<br />
<br />
We have the first version of our window. But it's not the end of work. If we want it to be user-friendly, it should give ability to resize. We can check it by either showing preview or building and running application. The latter is preffered since it may produce better results. If the window will show, we should experiment by resizing it:<br />
<br />
[[Image:wxs_tut03_016.png]]<br />
<br />
<br />
We can see two wrong things in this window:<br />
* Regions did not expand vertically and stay centered<br />
* Content of second region did not react for the resize<br />
<br />
The first problem should be cuased by some missing '''Expand''' property so let's find it.<br />
<br />
First we should check if regions have '''Expand''' property set: yes they have so this is not the problem. Generally in such situations we should continue checking in parent item - this is wxBoxSizer which always expand. Next there's wxPanel we used to make nice background and voila: this one does miss the '''Expand''' property. So let's check it and test the result again and it works fine. <br />
<br />
Now the second issue. Content inside '''CD details''' pane was based on wxFlexGridSizer. If you look into previous tutorial you may find out that this sizer has special property called '''Growable cols'''. Using this property we can set columns which should resize. I'd like the column with values to grow (we don't need more space for labels, dont we? ;) ) so let's set the '''Growable cols''' to '''"1"''' (idexes are 0-based). Note that you may quickly find the wxFlexGridSizer by ooking into resource tree - we have only one such sizer in our project.<br />
<br />
Now we have some more correct results:<br />
<br />
[[Image:wxs_tut03_017.png]]<br />
<br />
<br />
<br />
== Continue polishing the window ==<br />
<br />
<br />
As I look into our window I see that I left few things on the first region. Buttons don't have new labels and there's to much space between them and the list so we can update those things right now.<br />
<br />
As usual I'll leave changing the Labels to you - those buttons should be called '''Add''' and '''Delete'''. And now let's remove the wasted space.<br />
<br />
The space is added because each item inside sizers may have extra border. By default it's set to 5 pixels so if we remove the border around buttons we would have more free space. But than the buttons won't have any space between them.<br />
<br />
To overcome this problem we could use another property related to border also called '''Border''' (jay, I have to fix the naming before someone notice it) which expands to few check-boxes. By checking or unchecking them we can enable or disable border at some item's edge. So if we remove top/bottom/left edge borders of the first button and top/bottom/right edge borders of the second button we would remove extra space but buttons will still have some gap between them. Here's how the property should look like for the first button:<br />
<br />
[[Image:wxs_tut03_018.png]]</div>Byohttps://wiki.codeblocks.org/index.php?title=File:Wxs_tut03_018.png&diff=5252File:Wxs tut03 018.png2008-01-09T22:41:26Z<p>Byo: </p>
<hr />
<div></div>Byohttps://wiki.codeblocks.org/index.php?title=WxSmith_tutorial:_Building_more_complex_window&diff=5251WxSmith tutorial: Building more complex window2008-01-09T22:31:04Z<p>Byo: /* Let's check how does the window resize */</p>
<hr />
<div>[[Category:wxSmith Documentation]]<br />
<br />
= Warning: unfinished =<br />
<br />
= Building more complex window =<br />
<br />
Hi, in this tutorial I'll sow you some example of more complex window. Actually it would look complex when you start working with wxSmith. After writing few applications you will probably build few resources with this or even higher complexity so don't be scared. I'm working with wxSmith almost every day (it's really the best way to find bugs and discover nice improovements and that's what I should do as it's creator ;)) and athough edition may look comlex at the beginning, it's not hard to get used to it.<br />
<br />
I also want you to know that as I'm writing the beginning of this tutorial, I'm also beginning of writing the application - I didn't prepared ready solution since I would like to show process of creating window in really natural way (maybe even with some mistakes), so while writing the tutorial I'll also create the application.<br />
<br />
We will start with empty frame - if you've read previous tutorials you shouold create one without problems.<br />
<br />
== First task - some basic concept ==<br />
<br />
My proposition for exmple application would be something to manage colleciton of CD-roms. So at the beginning we should realize what should be presented at the main window. Let's say that we would have most informations at the main window (although it may not be a very good assumption, it would help to show creation of more complex resources).<br />
<br />
I would like to have some list of CD-roms on the left and some details of selected CD-rom on the right. So basically we have two regions in our window: one with the list and one with the details. I'd like also to use sizers because the application should be cross-platform and main window should be resizable.<br />
<br />
== Building skeleton ==<br />
<br />
If want the application to look nice on both windows and linux, we should do some trick presented in the first tutorial - we had to add extra wxPanel into frame to make the background better. Let's to the same thing here:<br />
<br />
* First add wxBoxSizer directly into resource<br />
* Add wxPanel into that sizer<br />
* Set size of border to 0 to make the panel cover entine window<br />
<br />
Now we should have some this result:<br />
<br />
[[Image:wxs_tut03_001.png]]<br />
<br />
Now let's add wxBoxSizer into it - this sizer will manage out two main regions. After that the tree structure should look like this:<br />
<br />
[[Image:wxs_tut03_002.png]]<br />
<br />
Now we can start filling those two regions - each one may have only one item (so the sizer we've just added will manage them). Usually in such sutiatuion I use wxStaticBoxSizer because we can mark regions and put some name for them. So let's add two wxStaticBoxSizer-s into the window. Be carefull while adding the second one because you may add it into the first region - always remember that parent for new items is always the item totally covered with blue:<br />
<br />
[[Image:wxs_tut03_003.png]]<br />
<br />
To add second sizer properly you must click on the border surrounding the first one just like on the picture. Note that now the resource is small but it will change when we will add some items into regions.<br />
<br />
<br />
== Building the '''List of CDs''' region ==<br />
<br />
Ok, now let's add some item which will show list of CDs. We can use wxListBox here:<br />
<br />
[[Image:wxs_tut03_004.png]]<br />
<br />
The list is rather small so let's resize it using drag-boxes to something bigger and higher:<br />
<br />
[[Image:wxs_tut03_005.png]]<br />
<br />
Ok, but the second sizer did not resize. That's right since we didn't turn on it's '''Expand''' flag. To do this let's click on the second sizer and check it's '''Expand'' property:<br />
<br />
[[Image:wxs_tut03_006.png]]<br />
<br />
Now we can change labels of regions since they are fully visible now. To do this click on each region's sizer and change the '''Label''' property:<br />
<br />
[[Image:wxs_tut03_007.png]]<br />
<br />
Ok but we would like to have ability to add and delete selected cd - we will insert two buttons for this purpose in the first region. To add the button choose it from palette and add into the sizer. Note that we can now point wxListBox item - it can not have children so wxSmith will try to add new item before or after it. After adding button we would have such result:<br />
<br />
[[Image:wxs_tut03_008.png]]<br />
<br />
Hmm, the button should be under the list, not next to it. wxStaticBoxSizer did align items as it should - by default it aligns them in horizontal line. To change the direction to vertical, you can change the '''Orientation''' property of wxStaticBoxSizer. But before we change it let's predict one more thing. I would like to have two buttons instead of only one and I'd like them to be aligned horizontally. Since wxStaticBox will be changed to vertical mode, we will have to use another sizer used only for buttons. So let's add wxBoxSizer right after the list and before button:<br />
<br />
[[Image:wxs_tut03_009.png]]<br />
<br />
Now let's change '''Orientation''' of the wxStaticBoxSizer to vertical. After changing we have following result:<br />
<br />
[[Image:wxs_tut03_010.png]]<br />
<br />
We can see that something's wrong here. The wxBoxSizer is abnormally stretched and if we scroll the editor we can see that the same goes to button. We said in previous tutorial that wxBoxSizer an wxStaticBoxSizer are trying to keep same size of items in one direction - that's what happened here. wxStaticBoxSizer used the highest item (list of CDs) and applied this height into all managed items. How to disable it? By setting '''Proportion''' property of both wxBoxSizer and wxButton to 0. This will notify that those items shouldn't be used in height calculations:<br />
<br />
[[Image:wxs_tut03_011.png]]<br />
<br />
<br />
Now let's move the button into the wxBoxSizer - you can very easily do it by clickong on the button and dragging it into the sizer. After that we can add second button next to the first one:<br />
<br />
[[Image:wxs_tut03_012.png]]<br />
<br />
Nowe we can see that the list don't have '''Expand''' property set (otherwise it would be almost as wide as the region.<br />
<br />
Now I'd like to see how current work does look in the application. We could simply run it (F9) or by pressing the preview button on the right part of wxSmith editor:<br />
<br />
[[Image:wxs_tut03_013.png]]<br />
<br />
(If you run application you will see that there's menu and statusbar, on the preview it won't show, wxSmith still misses few features ;) )<br />
<br />
Our window looks good, not perfect but let's leave some polishing for later and fill the CD details region.<br />
<br />
== Building '''CD details''' region ==<br />
<br />
Inside CD details I'd like to have description of CD:<br />
* Type (Music/Program/Backup/Other)<br />
* Title<br />
* Artist/Author<br />
* Date of release<br />
* Description<br />
<br />
For such list we would need some grid sizer. Ok, but the region has wxStaticBoxSizer which align items only in one line. To overcome this limitation we can just add another sizer into wxStaticBoxSizer and use new one as the grid. From two available sizers I suggest wxFlexGridSizer (wxGridSizer would force all cells to have same size which wouldn't look good because row with description may need some more space than others). So let's add new sizer:<br />
* Add wxFlexGridSizer into wxStaticBoxSizer<br />
* Check '''Expand''' property of new item<br />
* Set '''Border Size''' to 0 to avoid some unwanted border.<br />
<br />
=== Adding items ===<br />
<br />
Data presented here should be shown in two columns - first for the label and second for value so let's change the '''Cols''' property to 2. And now it's time to add the content. For labels we will use wxStaticText and for the value we will use different items:<br />
* wxChoice for Type<br />
* wxTextCtrl for Title, Artist/Author and Description<br />
* wxDatePickerCtrl for Date of release<br />
<br />
After adding items we should have following view:<br />
<br />
[[Image:wxs_tut03_014.png]]<br />
<br />
<br />
Hmm, as I've said at the beginning - I didn't prepared anything before writing this tutorial. And guess what. It looks like wxDatePickerCtrl is broken on linux and sometimes crashes C::B (I didn't check on windows), don't know yet whether it's in wxWidgets or wxSmith - I'll have to investigate it. So we will have to change wxDatePickerCtrl to something else or remove it.<br />
<br />
There's alternative for wxDatePickerCtrl - wxCallendarCtrl so first let's try to replace wxDatePickerCtrl. First we will have to remove wrong item (by using 'delete' key or by pressing 'X' button on the right side of the editor). After the change we can see that generated callendar is quite but according to other items in this region. We can shrink it a little bit by checking '''wxCAL_SEQUENTIAL_MONTH_SELECTION''' inside the '''Style''' property but it will make the item harder to navigate. We can additionally set '''wxSUNKEN_BORDER''' style to add some nice border around the callendar. Ok, not perfect but acceptable ;)<br />
<br />
Now we have this screen:<br />
<br />
[[Image:wxs_tut03_015.png]]<br />
<br />
=== Customizing and adjusting items ===<br />
<br />
<br />
Ok, it looks like we have few things to do now:<br />
* First is to check '''Expand''' property for the first region since (it didn't expand when the second region increased height)<br />
* Second is to set proper labels for values in '''CD details''' region<br />
* Third is to check '''Expand''' property for all items with values in same region <br />
* Fourth thing is to adjust items used to edit values in '''CD details''' region<br />
<br />
First three tasks are quite easy and I'll leave them to you :)<br />
<br />
Fourth task will require few new things so I'll describe it better:<br />
<br />
First let's remove text from text boxes - it's set by default but it would be better to have empty text by default. Text can be changed by modifying '''Text''' property so you should do this very quickly.<br />
<br />
Now we have to set some values which could be choosen from '''Type''' value. It's done by editing '''Choices''' property of wxChoice. This is more advanced value consisting of few strings to entering it inside one line of text could be hard. Because of that, instead of text, there's a button on the right side. When you click it, new window will pop-up where you can enter choices:<br />
<br />
Music<br />
Program<br />
Backup<br />
Other<br />
<br />
== Let's check how does the window resize ==<br />
<br />
We have the first version of our window. But it's not the end of work. If we want it to be user-friendly, it should give ability to resize. We can check it by either showing preview or building and running application. The latter is preffered since it may produce better results. If the window will show, we should experiment by resizing it:<br />
<br />
[[Image:wxs_tut03_016.png]]<br />
<br />
<br />
We can see two wrong things in this window:<br />
* Regions did not expand vertically and stay centered<br />
* Content of second region did not react for the resize<br />
<br />
The first problem should be cuased by some missing '''Expand''' property so let's find it.<br />
<br />
First we should check if regions have '''Expand''' property set: yes they have so this is not the problem. Generally in such situations we should continue checking in parent item - this is wxBoxSizer which always expand. Next there's wxPanel we used to make nice background and voila: this one does miss the '''Expand''' property. So let's check it and test the result again and it works fine. <br />
<br />
Now the second issue. Content inside '''CD details''' pane was based on wxFlexGridSizer. If you look into previous tutorial you may find out that this sizer has special property called '''Growable cols'''. Using this property we can set columns which should resize. I'd like the column with values to grow (we don't need more space for labels, dont we? ;) ) so let's set the '''Growable cols''' to '''"1"''' (idexes are 0-based). Note that you may quickly find the wxFlexGridSizer by ooking into resource tree - we have only one such sizer in our project.<br />
<br />
Now we have some more correct results:<br />
<br />
[[Image:wxs_tut03_017.png]]</div>Byohttps://wiki.codeblocks.org/index.php?title=WxSmith_tutorial:_Building_more_complex_window&diff=5250WxSmith tutorial: Building more complex window2008-01-09T22:30:43Z<p>Byo: /* Customizing and adjusting items */</p>
<hr />
<div>[[Category:wxSmith Documentation]]<br />
<br />
= Warning: unfinished =<br />
<br />
= Building more complex window =<br />
<br />
Hi, in this tutorial I'll sow you some example of more complex window. Actually it would look complex when you start working with wxSmith. After writing few applications you will probably build few resources with this or even higher complexity so don't be scared. I'm working with wxSmith almost every day (it's really the best way to find bugs and discover nice improovements and that's what I should do as it's creator ;)) and athough edition may look comlex at the beginning, it's not hard to get used to it.<br />
<br />
I also want you to know that as I'm writing the beginning of this tutorial, I'm also beginning of writing the application - I didn't prepared ready solution since I would like to show process of creating window in really natural way (maybe even with some mistakes), so while writing the tutorial I'll also create the application.<br />
<br />
We will start with empty frame - if you've read previous tutorials you shouold create one without problems.<br />
<br />
== First task - some basic concept ==<br />
<br />
My proposition for exmple application would be something to manage colleciton of CD-roms. So at the beginning we should realize what should be presented at the main window. Let's say that we would have most informations at the main window (although it may not be a very good assumption, it would help to show creation of more complex resources).<br />
<br />
I would like to have some list of CD-roms on the left and some details of selected CD-rom on the right. So basically we have two regions in our window: one with the list and one with the details. I'd like also to use sizers because the application should be cross-platform and main window should be resizable.<br />
<br />
== Building skeleton ==<br />
<br />
If want the application to look nice on both windows and linux, we should do some trick presented in the first tutorial - we had to add extra wxPanel into frame to make the background better. Let's to the same thing here:<br />
<br />
* First add wxBoxSizer directly into resource<br />
* Add wxPanel into that sizer<br />
* Set size of border to 0 to make the panel cover entine window<br />
<br />
Now we should have some this result:<br />
<br />
[[Image:wxs_tut03_001.png]]<br />
<br />
Now let's add wxBoxSizer into it - this sizer will manage out two main regions. After that the tree structure should look like this:<br />
<br />
[[Image:wxs_tut03_002.png]]<br />
<br />
Now we can start filling those two regions - each one may have only one item (so the sizer we've just added will manage them). Usually in such sutiatuion I use wxStaticBoxSizer because we can mark regions and put some name for them. So let's add two wxStaticBoxSizer-s into the window. Be carefull while adding the second one because you may add it into the first region - always remember that parent for new items is always the item totally covered with blue:<br />
<br />
[[Image:wxs_tut03_003.png]]<br />
<br />
To add second sizer properly you must click on the border surrounding the first one just like on the picture. Note that now the resource is small but it will change when we will add some items into regions.<br />
<br />
<br />
== Building the '''List of CDs''' region ==<br />
<br />
Ok, now let's add some item which will show list of CDs. We can use wxListBox here:<br />
<br />
[[Image:wxs_tut03_004.png]]<br />
<br />
The list is rather small so let's resize it using drag-boxes to something bigger and higher:<br />
<br />
[[Image:wxs_tut03_005.png]]<br />
<br />
Ok, but the second sizer did not resize. That's right since we didn't turn on it's '''Expand''' flag. To do this let's click on the second sizer and check it's '''Expand'' property:<br />
<br />
[[Image:wxs_tut03_006.png]]<br />
<br />
Now we can change labels of regions since they are fully visible now. To do this click on each region's sizer and change the '''Label''' property:<br />
<br />
[[Image:wxs_tut03_007.png]]<br />
<br />
Ok but we would like to have ability to add and delete selected cd - we will insert two buttons for this purpose in the first region. To add the button choose it from palette and add into the sizer. Note that we can now point wxListBox item - it can not have children so wxSmith will try to add new item before or after it. After adding button we would have such result:<br />
<br />
[[Image:wxs_tut03_008.png]]<br />
<br />
Hmm, the button should be under the list, not next to it. wxStaticBoxSizer did align items as it should - by default it aligns them in horizontal line. To change the direction to vertical, you can change the '''Orientation''' property of wxStaticBoxSizer. But before we change it let's predict one more thing. I would like to have two buttons instead of only one and I'd like them to be aligned horizontally. Since wxStaticBox will be changed to vertical mode, we will have to use another sizer used only for buttons. So let's add wxBoxSizer right after the list and before button:<br />
<br />
[[Image:wxs_tut03_009.png]]<br />
<br />
Now let's change '''Orientation''' of the wxStaticBoxSizer to vertical. After changing we have following result:<br />
<br />
[[Image:wxs_tut03_010.png]]<br />
<br />
We can see that something's wrong here. The wxBoxSizer is abnormally stretched and if we scroll the editor we can see that the same goes to button. We said in previous tutorial that wxBoxSizer an wxStaticBoxSizer are trying to keep same size of items in one direction - that's what happened here. wxStaticBoxSizer used the highest item (list of CDs) and applied this height into all managed items. How to disable it? By setting '''Proportion''' property of both wxBoxSizer and wxButton to 0. This will notify that those items shouldn't be used in height calculations:<br />
<br />
[[Image:wxs_tut03_011.png]]<br />
<br />
<br />
Now let's move the button into the wxBoxSizer - you can very easily do it by clickong on the button and dragging it into the sizer. After that we can add second button next to the first one:<br />
<br />
[[Image:wxs_tut03_012.png]]<br />
<br />
Nowe we can see that the list don't have '''Expand''' property set (otherwise it would be almost as wide as the region.<br />
<br />
Now I'd like to see how current work does look in the application. We could simply run it (F9) or by pressing the preview button on the right part of wxSmith editor:<br />
<br />
[[Image:wxs_tut03_013.png]]<br />
<br />
(If you run application you will see that there's menu and statusbar, on the preview it won't show, wxSmith still misses few features ;) )<br />
<br />
Our window looks good, not perfect but let's leave some polishing for later and fill the CD details region.<br />
<br />
== Building '''CD details''' region ==<br />
<br />
Inside CD details I'd like to have description of CD:<br />
* Type (Music/Program/Backup/Other)<br />
* Title<br />
* Artist/Author<br />
* Date of release<br />
* Description<br />
<br />
For such list we would need some grid sizer. Ok, but the region has wxStaticBoxSizer which align items only in one line. To overcome this limitation we can just add another sizer into wxStaticBoxSizer and use new one as the grid. From two available sizers I suggest wxFlexGridSizer (wxGridSizer would force all cells to have same size which wouldn't look good because row with description may need some more space than others). So let's add new sizer:<br />
* Add wxFlexGridSizer into wxStaticBoxSizer<br />
* Check '''Expand''' property of new item<br />
* Set '''Border Size''' to 0 to avoid some unwanted border.<br />
<br />
=== Adding items ===<br />
<br />
Data presented here should be shown in two columns - first for the label and second for value so let's change the '''Cols''' property to 2. And now it's time to add the content. For labels we will use wxStaticText and for the value we will use different items:<br />
* wxChoice for Type<br />
* wxTextCtrl for Title, Artist/Author and Description<br />
* wxDatePickerCtrl for Date of release<br />
<br />
After adding items we should have following view:<br />
<br />
[[Image:wxs_tut03_014.png]]<br />
<br />
<br />
Hmm, as I've said at the beginning - I didn't prepared anything before writing this tutorial. And guess what. It looks like wxDatePickerCtrl is broken on linux and sometimes crashes C::B (I didn't check on windows), don't know yet whether it's in wxWidgets or wxSmith - I'll have to investigate it. So we will have to change wxDatePickerCtrl to something else or remove it.<br />
<br />
There's alternative for wxDatePickerCtrl - wxCallendarCtrl so first let's try to replace wxDatePickerCtrl. First we will have to remove wrong item (by using 'delete' key or by pressing 'X' button on the right side of the editor). After the change we can see that generated callendar is quite but according to other items in this region. We can shrink it a little bit by checking '''wxCAL_SEQUENTIAL_MONTH_SELECTION''' inside the '''Style''' property but it will make the item harder to navigate. We can additionally set '''wxSUNKEN_BORDER''' style to add some nice border around the callendar. Ok, not perfect but acceptable ;)<br />
<br />
Now we have this screen:<br />
<br />
[[Image:wxs_tut03_015.png]]<br />
<br />
=== Customizing and adjusting items ===<br />
<br />
<br />
Ok, it looks like we have few things to do now:<br />
* First is to check '''Expand''' property for the first region since (it didn't expand when the second region increased height)<br />
* Second is to set proper labels for values in '''CD details''' region<br />
* Third is to check '''Expand''' property for all items with values in same region <br />
* Fourth thing is to adjust items used to edit values in '''CD details''' region<br />
<br />
First three tasks are quite easy and I'll leave them to you :)<br />
<br />
Fourth task will require few new things so I'll describe it better:<br />
<br />
First let's remove text from text boxes - it's set by default but it would be better to have empty text by default. Text can be changed by modifying '''Text''' property so you should do this very quickly.<br />
<br />
Now we have to set some values which could be choosen from '''Type''' value. It's done by editing '''Choices''' property of wxChoice. This is more advanced value consisting of few strings to entering it inside one line of text could be hard. Because of that, instead of text, there's a button on the right side. When you click it, new window will pop-up where you can enter choices:<br />
<br />
Music<br />
Program<br />
Backup<br />
Other<br />
<br />
== Let's check how does the window resize ==<br />
<br />
We have the first version of our window. But it's not the end of work. If we want it to be user-friendly, it should give ability to resize. We can check it by either showing preview or building and running application. The latter is preffered since it may produce better results. If the window will show, we should experiment by resizing it:<br />
<br />
[[Image:wxs_tut03_016.png]]<br />
<br />
<br />
We can see two wrong things in this window:<br />
* Regions did not expand vertically and stay centered<br />
* Content of second region did not react for the resize<br />
<br />
The first problem should be cuased by some missing '''Expand''' property so let's find it.<br />
<br />
First we should check if regions have '''Expand''' property set: yes they have so this is not the problem. Generally in such situations we should continue checking in parent item - this is wxBoxSizer which always expand. Next there's wxPanel we used to make nice background and voila: this one does miss the '''Expand''' property. So let's check it and test the result again and it works fine. <br />
<br />
Now the second issue. Content inside '''CD details''' pane was based on wxFlexGridSizer. If you look into previous tutorial you may find out that this sizer has special property called '''Growable cols'''. Using this property we can set columns which should resize. I'd like the column with values to grow (we don't need more space for labels, dont we? ;) ) so let's set the '''Growable cols''' to '''"1"''' (idexes are 0-based). Note that you may quickly find the wxFlexGridSizer by ooking into resource tree - we have only one such sizer in our project.<br />
<br />
Now we have some more correct results:<br />
<br />
[[Image:wxs_tut03_17.png]]</div>Byohttps://wiki.codeblocks.org/index.php?title=File:Wxs_tut03_017.png&diff=5249File:Wxs tut03 017.png2008-01-09T22:30:17Z<p>Byo: </p>
<hr />
<div></div>Byohttps://wiki.codeblocks.org/index.php?title=File:Wxs_tut03_016.png&diff=5248File:Wxs tut03 016.png2008-01-09T22:18:42Z<p>Byo: </p>
<hr />
<div></div>Byohttps://wiki.codeblocks.org/index.php?title=WxSmith_tutorial:_Building_more_complex_window&diff=5247WxSmith tutorial: Building more complex window2008-01-09T22:04:47Z<p>Byo: </p>
<hr />
<div>[[Category:wxSmith Documentation]]<br />
<br />
= Warning: unfinished =<br />
<br />
= Building more complex window =<br />
<br />
Hi, in this tutorial I'll sow you some example of more complex window. Actually it would look complex when you start working with wxSmith. After writing few applications you will probably build few resources with this or even higher complexity so don't be scared. I'm working with wxSmith almost every day (it's really the best way to find bugs and discover nice improovements and that's what I should do as it's creator ;)) and athough edition may look comlex at the beginning, it's not hard to get used to it.<br />
<br />
I also want you to know that as I'm writing the beginning of this tutorial, I'm also beginning of writing the application - I didn't prepared ready solution since I would like to show process of creating window in really natural way (maybe even with some mistakes), so while writing the tutorial I'll also create the application.<br />
<br />
We will start with empty frame - if you've read previous tutorials you shouold create one without problems.<br />
<br />
== First task - some basic concept ==<br />
<br />
My proposition for exmple application would be something to manage colleciton of CD-roms. So at the beginning we should realize what should be presented at the main window. Let's say that we would have most informations at the main window (although it may not be a very good assumption, it would help to show creation of more complex resources).<br />
<br />
I would like to have some list of CD-roms on the left and some details of selected CD-rom on the right. So basically we have two regions in our window: one with the list and one with the details. I'd like also to use sizers because the application should be cross-platform and main window should be resizable.<br />
<br />
== Building skeleton ==<br />
<br />
If want the application to look nice on both windows and linux, we should do some trick presented in the first tutorial - we had to add extra wxPanel into frame to make the background better. Let's to the same thing here:<br />
<br />
* First add wxBoxSizer directly into resource<br />
* Add wxPanel into that sizer<br />
* Set size of border to 0 to make the panel cover entine window<br />
<br />
Now we should have some this result:<br />
<br />
[[Image:wxs_tut03_001.png]]<br />
<br />
Now let's add wxBoxSizer into it - this sizer will manage out two main regions. After that the tree structure should look like this:<br />
<br />
[[Image:wxs_tut03_002.png]]<br />
<br />
Now we can start filling those two regions - each one may have only one item (so the sizer we've just added will manage them). Usually in such sutiatuion I use wxStaticBoxSizer because we can mark regions and put some name for them. So let's add two wxStaticBoxSizer-s into the window. Be carefull while adding the second one because you may add it into the first region - always remember that parent for new items is always the item totally covered with blue:<br />
<br />
[[Image:wxs_tut03_003.png]]<br />
<br />
To add second sizer properly you must click on the border surrounding the first one just like on the picture. Note that now the resource is small but it will change when we will add some items into regions.<br />
<br />
<br />
== Building the '''List of CDs''' region ==<br />
<br />
Ok, now let's add some item which will show list of CDs. We can use wxListBox here:<br />
<br />
[[Image:wxs_tut03_004.png]]<br />
<br />
The list is rather small so let's resize it using drag-boxes to something bigger and higher:<br />
<br />
[[Image:wxs_tut03_005.png]]<br />
<br />
Ok, but the second sizer did not resize. That's right since we didn't turn on it's '''Expand''' flag. To do this let's click on the second sizer and check it's '''Expand'' property:<br />
<br />
[[Image:wxs_tut03_006.png]]<br />
<br />
Now we can change labels of regions since they are fully visible now. To do this click on each region's sizer and change the '''Label''' property:<br />
<br />
[[Image:wxs_tut03_007.png]]<br />
<br />
Ok but we would like to have ability to add and delete selected cd - we will insert two buttons for this purpose in the first region. To add the button choose it from palette and add into the sizer. Note that we can now point wxListBox item - it can not have children so wxSmith will try to add new item before or after it. After adding button we would have such result:<br />
<br />
[[Image:wxs_tut03_008.png]]<br />
<br />
Hmm, the button should be under the list, not next to it. wxStaticBoxSizer did align items as it should - by default it aligns them in horizontal line. To change the direction to vertical, you can change the '''Orientation''' property of wxStaticBoxSizer. But before we change it let's predict one more thing. I would like to have two buttons instead of only one and I'd like them to be aligned horizontally. Since wxStaticBox will be changed to vertical mode, we will have to use another sizer used only for buttons. So let's add wxBoxSizer right after the list and before button:<br />
<br />
[[Image:wxs_tut03_009.png]]<br />
<br />
Now let's change '''Orientation''' of the wxStaticBoxSizer to vertical. After changing we have following result:<br />
<br />
[[Image:wxs_tut03_010.png]]<br />
<br />
We can see that something's wrong here. The wxBoxSizer is abnormally stretched and if we scroll the editor we can see that the same goes to button. We said in previous tutorial that wxBoxSizer an wxStaticBoxSizer are trying to keep same size of items in one direction - that's what happened here. wxStaticBoxSizer used the highest item (list of CDs) and applied this height into all managed items. How to disable it? By setting '''Proportion''' property of both wxBoxSizer and wxButton to 0. This will notify that those items shouldn't be used in height calculations:<br />
<br />
[[Image:wxs_tut03_011.png]]<br />
<br />
<br />
Now let's move the button into the wxBoxSizer - you can very easily do it by clickong on the button and dragging it into the sizer. After that we can add second button next to the first one:<br />
<br />
[[Image:wxs_tut03_012.png]]<br />
<br />
Nowe we can see that the list don't have '''Expand''' property set (otherwise it would be almost as wide as the region.<br />
<br />
Now I'd like to see how current work does look in the application. We could simply run it (F9) or by pressing the preview button on the right part of wxSmith editor:<br />
<br />
[[Image:wxs_tut03_013.png]]<br />
<br />
(If you run application you will see that there's menu and statusbar, on the preview it won't show, wxSmith still misses few features ;) )<br />
<br />
Our window looks good, not perfect but let's leave some polishing for later and fill the CD details region.<br />
<br />
== Building '''CD details''' region ==<br />
<br />
Inside CD details I'd like to have description of CD:<br />
* Type (Music/Program/Backup/Other)<br />
* Title<br />
* Artist/Author<br />
* Date of release<br />
* Description<br />
<br />
For such list we would need some grid sizer. Ok, but the region has wxStaticBoxSizer which align items only in one line. To overcome this limitation we can just add another sizer into wxStaticBoxSizer and use new one as the grid. From two available sizers I suggest wxFlexGridSizer (wxGridSizer would force all cells to have same size which wouldn't look good because row with description may need some more space than others). So let's add new sizer:<br />
* Add wxFlexGridSizer into wxStaticBoxSizer<br />
* Check '''Expand''' property of new item<br />
* Set '''Border Size''' to 0 to avoid some unwanted border.<br />
<br />
=== Adding items ===<br />
<br />
Data presented here should be shown in two columns - first for the label and second for value so let's change the '''Cols''' property to 2. And now it's time to add the content. For labels we will use wxStaticText and for the value we will use different items:<br />
* wxChoice for Type<br />
* wxTextCtrl for Title, Artist/Author and Description<br />
* wxDatePickerCtrl for Date of release<br />
<br />
After adding items we should have following view:<br />
<br />
[[Image:wxs_tut03_014.png]]<br />
<br />
<br />
Hmm, as I've said at the beginning - I didn't prepared anything before writing this tutorial. And guess what. It looks like wxDatePickerCtrl is broken on linux and sometimes crashes C::B (I didn't check on windows), don't know yet whether it's in wxWidgets or wxSmith - I'll have to investigate it. So we will have to change wxDatePickerCtrl to something else or remove it.<br />
<br />
There's alternative for wxDatePickerCtrl - wxCallendarCtrl so first let's try to replace wxDatePickerCtrl. First we will have to remove wrong item (by using 'delete' key or by pressing 'X' button on the right side of the editor). After the change we can see that generated callendar is quite but according to other items in this region. We can shrink it a little bit by checking '''wxCAL_SEQUENTIAL_MONTH_SELECTION''' inside the '''Style''' property but it will make the item harder to navigate. We can additionally set '''wxSUNKEN_BORDER''' style to add some nice border around the callendar. Ok, not perfect but acceptable ;)<br />
<br />
Now we have this screen:<br />
<br />
[[Image:wxs_tut03_015.png]]<br />
<br />
=== Customizing and adjusting items ===<br />
<br />
Ok, it looks like we have few things to do now:<br />
* First is to check '''Expand''' property for the first region since (it didn't expand when the second region increased height)<br />
* Second is to set proper labels for values if '''CD details''' region<br />
* Third thing is to adjust items used to edit values in '''CD details''' region<br />
<br />
First two tasks are quite easy and I leave them to you :)<br />
<br />
Third task will require few new things so I'll describe it better:</div>Byohttps://wiki.codeblocks.org/index.php?title=WxSmith_tutorial:_Building_more_complex_window&diff=5246WxSmith tutorial: Building more complex window2008-01-09T21:56:50Z<p>Byo: </p>
<hr />
<div>[[Category:wxSmith Documentation]]<br />
<br />
= Warning: unfinished =<br />
<br />
= Building more complex window =<br />
<br />
Hi, in this tutorial I'll sow you some example of more complex window. Actually it would look complex when you start working with wxSmith. After writing few applications you will probably build few resources with this or even higher complexity so don't be scared. I'm working with wxSmith almost every day (it's really the best way to find bugs and discover nice improovements and that's what I should do as it's creator ;)) and athough edition may look comlex at the beginning, it's not hard to get used to it.<br />
<br />
I also want you to know that as I'm writing the beginning of this tutorial, I'm also beginning of writing the application - I didn't prepared ready solution since I would like to show process of creating window in really natural way (maybe even with some mistakes), so while writing the tutorial I'll also create the application.<br />
<br />
We will start with empty frame - if you've read previous tutorials you shouold create one without problems.<br />
<br />
== First task - some basic concept ==<br />
<br />
My proposition for exmple application would be something to manage colleciton of CD-roms. So at the beginning we should realize what should be presented at the main window. Let's say that we would have most informations at the main window (although it may not be a very good assumption, it would help to show creation of more complex resources).<br />
<br />
I would like to have some list of CD-roms on the left and some details of selected CD-rom on the right. So basically we have two regions in our window: one with the list and one with the details. I'd like also to use sizers because the application should be cross-platform and main window should be resizable.<br />
<br />
We also want the application to look nice on both windows and linux. If you remember the first tutorial, we had to add extra wxPanel into frame to make the background better so let's to the same thing here:<br />
<br />
* First add wxBoxSizer directly into resource<br />
* Add wxPanel into that sizer<br />
* Set size of border to 0 to make the panel cover entine window<br />
<br />
Now we should have some this result:<br />
<br />
[[Image:wxs_tut03_001.png]]<br />
<br />
Now let's add wxBoxSizer into it - this sizer will manage out two main regions. After that the tree structure should look like this:<br />
<br />
[[Image:wxs_tut03_002.png]]<br />
<br />
Now we can start filling those two regions - each one may have only one item (so the sizer we've just added will manage them). Usually in such sutiatuion I use wxStaticBoxSizer because we can mark regions and put some name for them. So let's add two wxStaticBoxSizer-s into the window. Be carefull while adding the second one because you may add it into the first region - always remember that parent for new items is always the item totally covered with blue:<br />
<br />
[[Image:wxs_tut03_003.png]]<br />
<br />
To add second sizer properly you must click on the border surrounding the first one just like on the picture. Note that now the resource is small but it will change when we will add some items into regions.<br />
<br />
<br />
Ok, now let's add some item which will show list of CDs. We can use wxListBox here:<br />
<br />
[[Image:wxs_tut03_004.png]]<br />
<br />
The list is rather small so let's resize it using drag-boxes to something bigger and higher:<br />
<br />
[[Image:wxs_tut03_005.png]]<br />
<br />
Ok, but the second sizer did not resize. That's right since we didn't turn on it's '''Expand''' flag. To do this let's click on the second sizer and check it's '''Expand'' property:<br />
<br />
[[Image:wxs_tut03_006.png]]<br />
<br />
Now we can change labels of regions since they are fully visible now. To do this click on each region's sizer and change the '''Label''' property:<br />
<br />
[[Image:wxs_tut03_007.png]]<br />
<br />
Ok but we would like to have ability to add and delete selected cd - we will insert two buttons for this purpose in the first region. To add the button choose it from palette and add into the sizer. Note that we can now point wxListBox item - it can not have children so wxSmith will try to add new item before or after it. After adding button we would have such result:<br />
<br />
[[Image:wxs_tut03_008.png]]<br />
<br />
Hmm, the button should be under the list, not next to it. wxStaticBoxSizer did align items as it should - by default it aligns them in horizontal line. To change the direction to vertical, you can change the '''Orientation''' property of wxStaticBoxSizer. But before we change it let's predict one more thing. I would like to have two buttons instead of only one and I'd like them to be aligned horizontally. Since wxStaticBox will be changed to vertical mode, we will have to use another sizer used only for buttons. So let's add wxBoxSizer right after the list and before button:<br />
<br />
[[Image:wxs_tut03_009.png]]<br />
<br />
Now let's change '''Orientation''' of the wxStaticBoxSizer to vertical. After changing we have following result:<br />
<br />
[[Image:wxs_tut03_010.png]]<br />
<br />
We can see that something's wrong here. The wxBoxSizer is abnormally stretched and if we scroll the editor we can see that the same goes to button. We said in previous tutorial that wxBoxSizer an wxStaticBoxSizer are trying to keep same size of items in one direction - that's what happened here. wxStaticBoxSizer used the highest item (list of CDs) and applied this height into all managed items. How to disable it? By setting '''Proportion''' property of both wxBoxSizer and wxButton to 0. This will notify that those items shouldn't be used in height calculations:<br />
<br />
[[Image:wxs_tut03_011.png]]<br />
<br />
<br />
Now let's move the button into the wxBoxSizer - you can very easily do it by clickong on the button and dragging it into the sizer. After that we can add second button next to the first one:<br />
<br />
[[Image:wxs_tut03_012.png]]<br />
<br />
Nowe we can see that the list don't have '''Expand''' property set (otherwise it would be almost as wide as the region.<br />
<br />
Now I'd like to see how current work does look in the application. We could simply run it (F9) or by pressing the preview button on the right part of wxSmith editor:<br />
<br />
[[Image:wxs_tut03_013.png]]<br />
<br />
(If you run application you will see that there's menu and statusbar, on the preview it won't show, wxSmith still misses few features ;) )<br />
<br />
Our window looks good, not perfect but let's leave some polishing for later and fill the CD details region.<br />
<br />
<br />
Inside CD details I'd like to have description of CD:<br />
* Type (Music/Program/Backup/Other)<br />
* Title<br />
* Artist/Author<br />
* Date of release<br />
* Description<br />
<br />
For such list we would need some grid sizer. Ok, but the region has wxStaticBoxSizer which align items only in one line. To overcome this limitation we can just add another sizer into wxStaticBoxSizer and use new one as the grid. From two available sizers I suggest wxFlexGridSizer (wxGridSizer would force all cells to have same size which wouldn't look good because row with description may need some more space than others). So let's add new sizer:<br />
* Add wxFlexGridSizer into wxStaticBoxSizer<br />
* Check '''Expand''' property of new item<br />
* Set '''Border Size''' to 0 to avoid some unwanted border.<br />
<br />
Data presented here should be shown in two columns - first for the label and second for value so let's change the '''Cols''' property to 2. And now it's time to add the content. For labels we will use wxStaticText and for the value we will use different items:<br />
* wxChoice for Type<br />
* wxTextCtrl for Title, Artist/Author and Description<br />
* wxDatePickerCtrl for Date of release<br />
<br />
After adding items we should have following view:<br />
<br />
[[Image:wxs_tut03_014.png]]<br />
<br />
<br />
Hmm, as I've said at the beginning - I didn't prepared anything before writing this tutorial. And guess what. It looks like wxDatePickerCtrl is broken on linux and sometimes crashes C::B (I didn't check on windows), don't know yet whether it's in wxWidgets or wxSmith - I'll have to investigate it. So we will have to change wxDatePickerCtrl to something else or remove it.<br />
<br />
There's alternative for wxDatePickerCtrl - wxCallendarCtrl so first let's try to replace wxDatePickerCtrl. First we will have to remove wrong item (by using 'delete' key or by pressing 'X' button on the right side of the editor). After the change we can see that generated callendar is quite but according to other items in this region. We can shrink it a little bit by checking '''wxCAL_SEQUENTIAL_MONTH_SELECTION''' inside the '''Style''' property but it will make the item harder to navigate. We can additionally set '''wxSUNKEN_BORDER''' style to add some nice border around the callendar. Ok, not perfect but acceptable ;)<br />
<br />
Now we have this screen:<br />
<br />
[[Image:wxs_tut03_015.png]]<br />
<br />
Ok, it looks like we have few things to do now:<br />
* First is to check '''Expand''' property for the first region since (it didn't expand when the second region increased height)<br />
* Second is to set proper labels for values if '''CD details''' region<br />
* Third thing is to adjust items used to edit values in '''CD details''' region<br />
<br />
First two tasks are quite easy and I leave them to you :)<br />
<br />
Third task will require few new things so I'll describe it better:</div>Byo