Messages

It works now.

Although this is good to hear, it means that the c++11 issue is more severe than I thought.
Getting strange behaviour just because the library wasn't compiled correctly isn't very good.

I tried to delay it as long as possible, but it is time that tgui starts making use of c++11.
I'll replace boost with c++11 ASAP to get rid of these problems. Then I can also finally start making use of the many c++11 features that I couldn't use until now.

Are you by any chance using c++11?

I recently was made aware that if you use the "-std=c++11" option for your own project, you should also compile tgui with this option.
I added a warning for that in the tutorial:

If you are going to use c++11 then you will have to check "Advanced" and add "-std=c++11″ (or "-std=c++0x" if you have an older compiler) to CMAKE_CXX_FLAGS.

That is what you have to do in cmake to compile tgui with c++11.

The crash at exit is caused by this, and perhaps your other problem as well.

Strange, it works for me.

Are you still using the exact same code as above with only the button->load line changed?
What does the load function return, true of false?
Did you copy the widgets folder from tgui as-is, without changing any files?
Nothing is being printed in the terminal?

You could also try loading Black.conf instead and see if it gives the same result.

A lot has changed since v0.5, including the way widgets are loaded.
They are now loaded with a config file instead of through a path name.

So to load the button you would need:

Code Select Expand

button->load("widgets/BabyBlue.conf");

You didn't say what version you were using so I just gave an answer without even considering that you may have been using a different version.

If you are just starting with tgui then using v0.6 might indeed be better because it is a huge improvement, it just lacks tutorials.

In v0.5 this would have been what you needed.

Code Select Expand

tgui::Button* button = gui.add<tgui::Button>();
tgui::Button* button2 = child->add<tgui::Button>();

There is only one difference.
Because child window itself is a pointer, you have to pass its value.

Code Select Expand

tgui::Button::Ptr button(gui);
tgui::Button::Ptr button2(*child); // child is a tgui::ChildWindow::Ptr

It was not the idea. If a widget have a margin of 0 and another a size of 30, if the size of the grid is changed (increased by 30 for example), they should have margin like 15 and 45 and not like 30 and 30.

That is indeed better.

If you speak at a final (graphical) level you are right, but if you speak at the code (algorithm) level (that I assumed), you are wrong. If you add a widget to the second column (even if grid is empty), you should leave it at the second column (and the first column will have a width of 0 if there is no widget). Now if you add a widget to the first column, you can leave the widget of the second column untouched (in term of position in the grid), only the (x, y) pixels position will be changed.

That was the idea, I was talking at a graphical level.

Your idea for the setSize function is one hand better than clipping, but on the other hand, setSize(getSize()) will not give the same grid like you may expect. All borders will be made the same size while before you could have some widgets without borders and other widgets with big borders.

Anyway, I'm sure you'll find other widgets that don't stay identical on setSize(getSize()) so thats not an issue to me. Having an empty setSize function is even worse. So I'll try to implement your idea for setSize.

The problem of automatically resize the grid using "grid[2][3] = ..." is that if you try (only) to access to widget at (2,3), and if it doesn't exist you will create it (similar to the std::map [] operator). Or am I wrong?
That is why I proposed a function like grid->addWidget(myWidget, 2, 3, ...); So you can have a better control of this.

It would indeed be similar to std::map's bracket operator.
In the end, I don't think it really matters. With the brackets operator, you will indeed create extra space which contains a nullptr. Program will crash if you try to use the nullptr. With the addWidget way, requesting a widget (either with [] operator or with getWidget function) would result in perhaps an exception being thrown.
So I see it like this. Both methods are fatal if you try to use a cell that didn't contain anything. You could catch the error but I don't see any usage for that. And if you really needed to check if some cell was empty then it was probably with the idea to add a widget there anyway if there isn't one. Which means it doesn't matter to reserve the extra space already when accessing a cell.
So I basically see those methods as equivalent and this is thus just a design issue. Some would prefer writing the brackets, others might prefer using the function. But I spend too many words on this already, and actually I don't even care which of the two methods is used.

I am not sure you should move widgets when they are placed. You can want to have a widget at (0,1) and an other at (1,0). If you move the first at (0,0), you will not have the expected layout.

The assumption in my example was that the grid was empty. Obviously when there are widgets in the first column (lets say with a max width of 50 and no borders), widgets added to the second column will have a left of 50.

I really should take a look at other gui's like qt and gtk, because so far I have never looked there for inspiration. I just did it my own way so far, or in a way suggested by users.

Grid::setSize() (and probably Grid in general) should be heavily inspired of Qt QGridLayout. This can lead to a very powerful widget in TGUI.

The current idea is to implement decent layouts in v0.7.
The only two big changes that should still be done in v0.6 are TextBox and the new form builder. Other than this there are just some small changes and then v0.6 will be finished. After that I will start working on layouts.

Moreover, currently, if the (auto-sized) grid need a size greater than its parent size to be correctly displayed, how this work?

Nothing special happens, it is just drawn as usually. It doesn't matter if a part is drawn outside of the screen. And child windows use clipping to avoid that widgets draw outsize of them.

You probably have considered many possibilities but, to be sure I understand, when you will do "grid[2][3] = ..." you will need to already have grid of a minimal size of (3, 4)?

My idea was actually to automatically resize the grid if it wasn't big enough. I wanted you to be able to set grid[1][0] even before you set grid[0][0] so that you just don't have to care about how many rows or columns there are: grid will take care of it. If you had a picture in [ 0 ][ 1 ] then it would be placed on position (0, 0) until you put a widget in [ 0 ][ 0 ] and then the picture will just move. It just requires some extra code in the brackets operator.

By the way, I see (in documentation) that Grid::setSize() "currently does nothing". Normal?

Yes, its normal. I recently decided that every widget requires a setSize and getSize function. Although getSize is defined for every widget, some widgets don't have a meaning for setSize.
What would happen if setSize was called on a Grid? Should it be cropped and all widgets outide this area be invisible? Or should the widgets inside the grid be resized so that together the widgets fill the size? To avoid making a decision right away, I just implemented an empty setSize method. Before this, there wasn't a setSize function at all, so its not like something is missing that was previously there.

Depending on how I will have free time to work on my project, it is possible that I need this and start some work on it. I will inform you when (and if) I start. If I do this, I will make a Pull Request on github.

Its actually quite a big change, its not just adding a brackets operator. The "grid[2][3] = button" was just a simplified version. In reality I was thinking more of "grid[2][3] = tgui::Grid::Cell(button, tgui::Borders(...), tgui::Layout::Centered)" and a lot of internal changes. So if you would make the changes that you need and contribute them then thats very kind, but I will probably make a lot of changes to it afterwards anyway.

And with my current definition of "not soon", it still means that I could be working on this next week.
I got plenty of time these days, but I have soo many things to write that I just don't know where to start. And because this change is a bit smaller than write a completely new form builder or rewriting the entire TextBox class, I might find more motivation to work on Grid instead.

I just compared the contents of the .a and .lib files on windows with the .so files from linux, and it seems that Slider2d is not in the libraries on windows. The part that has to do with SharedWidgetPtr is in there, but the Slider2d class itself is absend. The strange thing is, that on linux everything is ok. So its not like I forgot to add Slider2d to my cmake script because then it wouldn't be in the .so file either. So I'm not sure where I will have to look to fix this issue.

A warning for the c++11 has been added to the tutorial.

Some widgets are created inside tgui without a parent, so they don't always need one. A widget can normally function fine without a parent.

You could add a "void initialize(tgui::Container *const container)" function to your class. It will be called when the widget is added to the container, which is right after your contructor finishes in this case.

Or you could override the "void setSize(float width, float height)" function. By the time you would call that function, the parent will already be initialized.

I'm not sure if you are going to add more code, but in your current code the 'parentSize' doesn't do much. The parameter in addRow was actually added for creating empty rows. Once you add a widget to the row, the height of the row will become the height of that widget.

Grid should be rewritten in the future too (so that you can just write something like "grid[2][3] = button"), but I already have so much to do that this won't come soon.

For the reason you only see your logo...
You are creating buttons instead of labels. Buttons require a background image and you thus need to use the load function before they will show up. If you only need text then you should use tgui::Label instead.

Edit: That's not really the issue here. There is no parent yet, so there is no font yet. Without a font, the labels can't draw anything.
You should move the creation of the labels to the initialize function.

Code Select Expand

void initialize(tgui::Container *const container)
{
    setGlobalFont(container->getGlobalFont());

    // Create the labels here
}

Another option is to create the labels like now, but set the font in the initialize method

Code (cpp) Select Expand

void initialize(tgui::Container *const container)
{
    for all labels in m_menuItems:
        label->setTextFont(container->getGlobalFont());
}

Edit2:
You should also ask yourself if you really need an interface that inherits from Grid.
If you don't need this design then it could be better to place the tgui::Grid::Ptr as a member of Interface instead of using inheritance. That way you have your own constructor that can have any parameter (and thus has anything it needs) and can add the widgets to the grid without problems.

The check function doesn't has any parameters. Two different functions are provided to change the state of the checkbox, check and uncheck.

So the change you have to make is replacing
CheckBoxUcenik1->check(valueUcenik1);  // error here
by
if (valueUcenik1)
    CheckBoxUcenik1->check();
else
    CheckBoxUcenik1->uncheck();

I looked at the c++11 issue and it seems like it has something to do with boost. If I uncomment everything related to boost (basically the whole callback system) then the crash no longer occurs.

I only used boost to support older compilers as long as possible, so once I start using c++11 in my own code this issue will go away.

I was already considering whether c++11 would be for v0.6 or for v0.7, but this issue increases the chance that I will replace boost with c++11 in v0.6. Once I make the change, the "-std=c++11" option will be automatically set in cmake and you will have to set it in codeblocks in order to use tgui.

For now you'll just have to do with manually putting that option into cmake.

I compiled it from the latest git version and it worked great with examples (excepted Slider2d on FullExample but it is a dev version, no?).

What's wrong with Slider2d?
There was a problem with MenuBar because of a recent changed but thats fixed now.
It is a development version, but usually eveything works. From time to time I just forget to update the example code or the form builder.

SFML 2.0 packages are not built using c++11 (normally) but I use them without any problem in my c++11 project. So why, for TGUI, I need to build using c++11?

I'm actually surprised that it wouldn't work when tgui isn't compiled with c++11. I'll look into this.

EDIT: Now I also remember that I had some problems with the font file: "Failed to add a new character to the font: the maximum texture size has been reached".
I tried to replace the font by an other version of DejaVuSans that I use in one project and it worked... Personally I don't understand why... I uploaded the working font if you are interested. The file is too big... Can you increase the max size, please? (compressed size is around 300KB)

I can't allow bigger files to be uploaded. I could, but I only have very limited disk space on my host. And I wouldn't even know where I would have to change the upload limit. Although a few extra KBs won't hurt, I prefer to have as much data as possible on external servers. You could perhaps temporary put it on dropbox or something similar.

Is the issue really with tgui anyway? Try loading it with an sf::Font and sf::Text and see if you get the same error. If you do then its just the font file that's corrupted.

Alright. Take your time, there's no hurry.

I found the problem that caused the errors with dynamic linking.

But I now hate windows even more than before.
The whole issue had nothing to do with ChatBox. After searching for the difference between TextBox and ChatBox I came to the simple conclusion: there wasn't any difference in the way they were used. In the end it turned out that you may not use "__declspec(dllimport)" for template classes (but have to do this for all other classes).
Where did I read that when searching info about dllexport and dllimport? Right, nowhere.

But anyway, I removed one word from my code and now using dlls should be possible again.

Question: when building TGUI should the "TGUI_USE_STATIC_STD_LIBS" be checked when building for static SFML?

Normally no.

If you use the precompiled sfml library then you must leave this unchecked.

This is about building static std libraries. If you check it when building tgui then it should also be checked in sfml (which isn't the case in the sfml that you download from the site). And only then you have to change the "Code Generation->Runtime Library" option in visual studio.
I prefer linux for this because there it doesn't matter how libs are compiled, but on windows these 3 options have to match each other (or you will get errors or crashes).

So if you had this option checked then it might be the reason for the crash.

You should take a look at Grid.

If you know all widgets in the table upfront then you can use it.
Just use addToRow to add the widget in the next column and addRow to start a new row.

It currently has its limits though. You can't just change any row or column, you have to add the widgets row by row. But depending on the situation this could be enough.

Edit: The limitation has been removed. You can now add widgets in any row or column, the grid will automatically resize.

I think you forgot to define SFML_STATIC.

I changed C++->Code Generation->Runtime Library to Multi-threaded Debug

You shouldn't touch this option. It is only needed when linking to the STL libraries statically, which you normally don't do.

And i get error in line " snimi << Text; " Gcc complain that it cant do anything with Text. error: no match for 'operator<<' in 'snimi << Text'
Any solution to this? Since i cant bust my head again with vectors.

sf::String::toAnsiString() will return an std::string from the sf::String.
So the line can be

Code Select Expand

snimi << Text.toAnsiString();

In many situations, you won't need the callback id.

It is only needed when all callback comes in place and you have to figure out where the callback came from.
If you would have menuButtonClicked and quitButtonClicked callback functions then you don't need a callback id. These functions don't even need a parameter (unless they need access to certain variables).

The way you are handling callbacks can be considered the 'old' (and easiest) way, it was the only way to handle callbacks in v0.5. But as you can see in the callbacks tutorial, you no longer have to poll the callbacks from the gui and depending on your code and situation an id isn't needed.

Not every widget has a state and I think you might be able to miss events (by the time you reach that code the mouse might have gone up already).

You don't set a text size, which means the button is allowed to choose the best fitting size.
It probably takes a different size for the words menu and quit (although I would expect menu to have a slightly larger size).

Try giving both buttons a fixed size with setTextSize (you can use getTextSize in your code to find out the size that it is currently using).

The problem only occurs with dynamic linking on windows.
So as a temporary workaround you can just use static linking.

I'll continue searching for the problem, but so far I have absolutely no idea what could be causing this error.

Texus you should use : https://lmgtfy.com/?q=vector%3A%3Apush_back lol

I prefer this one
With that last '!cpp' you even get to cplusplus.com immediately.