Messages

Thanks. It is something that I was planning to add in the future but just has a very low priority.

Do you have a github account? Then you can send your change as a pull request and the commit will be linked to your account. Otherwise I will just commit it myself. Either way I'm first going to slightly change the code to fit my code style though.

The function can be renamed to parseLayout.

I'm still missing something here, what is the width (the 36 in your earlier example) that you pass to the layoutWidth function?
Could you put this in a small but more complete example?

I'll take a better look at this in the next few days.

I'm not sure what dist is in your example. But the distance to side is a space reserved for every tab inside the tab widget, so the calculation has to depend on how many tabs you have.

So it would start making a difference whether you first call setSize and then addTab or the other way around. Although that probably isn't going to be a big issue. Getting the same behavior between calling setSize before or after gui.add is however going to be harder to solve.

It might be doable, could you elaborate some more on how you calculate the dist variable?

The problem with tab is that it's size depends on its contents, that is why setSize was never implemented.
I could map the height from setSize to the item height, but setting the width of a tab widget has no meaning.
This is a problem that I am aware of but at this point I have no idea how to solve it.

No, it's not supported. ListBox only changes text color on hover and when a line is selected, all other lines use the same color.

Both issues were caused by the same bug.
The internal Panel inside the ChatBox was never told that it was inside a ChildWindow so it didn't update its clipping area like it should. I seem to have introduced this bug when I recently split the initialize function into a setParent and a setFont function which means that it is possible that there are other widgets with the same problem. I tested a select few other widgets which worked fine though. I don't have time to test all the widgets, so in the unlikely event that you come across another widget that has its text cut off then just let me know and I'll fix it asap.

The fixed version can be downloaded from github.

When you want to pass functions and parameters in c++ in a flexible way then you need std::function and std::bind, which is why they are used by the tgui callback system. You might want to read a few tutorials about them to understand a bit how they work because unless you use unbound parameters the connect function will work exactly the same as an std::bind call (except for the signal name that you pass as first parameter).

My connect function actually takes care of the std::bind itself to make it easier but the same rules apply as if you write:

Code (cpp) Select Expand

button->connect("pressed", std::bind(f, std::ref(i)));

So the reason why you need the std::ref is all because of how std::bind works. Just consider that std::bind will copy all parameters for later use, if the function takes a reference then it will get a reference to this copied variable. The std::ref is probably something like a pointer, instead of the original variable a pointer to it will be copied and when the function gets called it will be dereferenced for you. I don't know how std::function, std::bind and std::ref work internally, but that is basically how they behave.

Another thing that I wondered about, is what is the scope of the function that is called by the button, once it's connected. I assumed it's the same scope as where the button was created, am I right?

The question didn't make much sense earlier but I realize now that you might have used the wrong term, I guess the question is rather what the lifetime would be, not the scope.
Technically a function doesn't has a lifetime so if taken literally the question still wouldn't make sense but if the function is a member function of a class then there is the lifetime of the class to take into account. If the class has been destroyed before the callback is send then the function will be called with an invalid 'this' pointer. Trying to access any member variable would lead to a crash.
So the answer that I think you were looking for is that the class object of which you bind the function indeed has to live longer than the button or live until you unbind the signal yourself.

what is the scope of the function that is called

The function can be anywhere, just like you can call any function yourself as long as it has been declared before.

Also, what if the function has a return type? Let's say return type int. How could I catch that int when the function returns?

This is not possible. You wouldn't be able to access the return value even if the function would return something since the function is called internally and there is nowhere in your code where you would get the return. If a function need to "return" something then give it a reference parameter and pass it with std::ref.

Code (cpp) Select Expand

void f(int& x) { x = 5; }
int i = 0;
button->connect("pressed", f, std::ref(i));
// i is 0 here but will become 5 once the callback is triggered

The first parameter to the connect function is the name of the trigger to bind which should be "pressed", not "bpressed".
If that is not the problem then post the error you are getting, the other parameters seem to be correct though.

If you don't mind me saying, the tutorials could be a little clearer and explain stuff a little more in detail.

It's hard for me to know which things have to be explained better, if you have suggestions on what to add to the tutorial to make it easier to understand then feel free to suggest them.

It works fine here, are you setting an id as second parameter to listBox->addItem? Because you have to give the ids yourself otherwise the id will just be empty.

I can't look into it right now, but you should check is you have a nullptr somewhere. My guess would be that you are calling the connect function on a nullptr.

The line is indeed missing in ListBox and ComboBox, updated on github.
I found it strange that I would have introduced a bug like that during the opacity rewrite, but after looking through the changes it seems like they just never supported transparency at all for their background image.

The add function takes an optional boolean as second parameter which determines whether the new tab will immediately be selected or not. If true is passed (default) then the new tab will be selected and thus a callback will be triggered to indicate that the selected tab has changed. So if you don't want this you can pass false as second parameter to the add function.

For some reason it didn't want to load the pdb file so I ended up just adding all tgui cpp files directly in the project to debug it.

The "bug" seems to be that I loop over a list of textures even though no textures are loaded. The code did not give problems on any other platform or in release mode because the iterators are not used when no textures are loaded. But they were still being incremented even when invalid which visual studio checks in debug mode.

Source code for fixed version can be found on github: https://github.com/texus/TGUI

When you build tgui there should have been more files inside the build folder next to the .lib files (some .pdb files). Could you send these files too? I can reproduce the crash here but I can't debug it without these pdb files. Without those files I would have to replace all sfml and tgui libraries which could take some time (since I don't normally work on windows).

Most errors like these are caused by wrong settings so I honestly didn't even look at your code earlier.

Code (cpp) Select Expand

tgui::Button::Ptr new_game_button;

new_game_button will be a nullptr here. It should be

Code (cpp) Select Expand

tgui::Button::Ptr new_game_button = std::make_shared<tgui::Button>();

But an "Unhandled exception" coming from inside sfml is a strange error for this scenario. A nullptr is not really the first thing that you would think about.

Double check these things: https://forum.tgui.eu/index.php?topic=216.msg1092#msg1092

There are a few things you could check.
- So the debug settings link against the sfml and tgui libraries ending with "-d"?
- Are u using the precompiled tgui libraries or did you compile tgui yourself?
- Print pTab right before calling add to make sure it isn't a nullptr.
- Could you show the exact code that you are using (preferably just a simple main function)?
- Could you get a call stack of when the assertion happens?

This is probably due to some incompatibility in some library or settings, especially because you mention that it works fine in release mode. Check the things mentioned in this post: https://forum.tgui.eu/index.php?topic=216.msg1092#msg1092

The bug has been fixed, the latest tgui version will now always give the second result.

The first one is another bug, the second one is the only correct outcome. I want to make fixed sizes possible in the future but it is not supported yet.

gui there is not a pointer, it's asking me for the actual object.

The solution is actually very simple:

Code (cpp) Select Expand

tgui::Button::Ptr new_game_button(*guiPtr);

Since the constructor takes a reference to a gui it won't even be copied in that line.

I checked the documentation, and it's a typedef for a sharedptr for a Button

You either checked the wrong documentation or you misinterpreted it. In v0.7-dev it is indeed a normal std::shared_ptr, but in v0.6 it is a typedef to my own custom smart pointer class.

why does it need that gui parameter?

Constructing a widget goes in 3 steps (although you only need 2 lines):
(1) Constructing the widget (just executing the constructor, no theme/skin is loaded at this point)
(2) Loading the widget (specifying how the widget looks)
(3) Adding the widget to the gui

In tgui 0.6 and earlier, step (1) and (3) were done together, while step (2) is done with the load function. It is because (3) is done that the gui parameter is needed.

Code (cpp) Select Expand

tgui::Button::Ptr button(gui);
button->load("TGUI/widgets/Black.conf");

In v0.7-dev I have changed the way widgets are loaded so that (1) and (2) happen together while (3) is a seperate step. Here it is more clear that you would just have to use '->' instead of '.' when gui is a pointer.

Code (cpp) Select Expand

tgui::Button::Ptr button = theme->load("button");
gui.add(button);

I recommend v0.7-alpha2 for new projects btw, many things have been improved since v0.6.

the compiler is not letting me store the reference in a variable inside Game_State_Manager, for some reason, it complains that I have to initialize references in the constructor initialization list (I have to confess I don't know what it's talking about )

The constructor of a class consists of two parts: the initializer list and the constructor body. Before the body of the constructor is executed, all members of the class have already been initialized (although plain types like int are just random values). The reference has to already refer to a variable during this initialization step, it is already too late when the body of the constructor is executed. So it has to happen in the initializer list of which you find an example below (notice the ':' after the constructor).

Code (cpp) Select Expand

class Test
{
public:
    Test(int& i);

private:
    int x;
    int y;
    int& z;
}

Test::Test(int& i) :
    x(i), // Give x the value of the variable i
    z(i) // Make z a reference to the variable i
{
}

Variable y is not mentioned in the initializer list, it has received default initialization. Since it is an int its value is undefined, but if it were a class then its default constructor (constructor that takes no parameters) would have been called.

Note that when a class has a reference as member, it becomes impossible to make copies of instances of that class. So using a pointer instead of a reference is sometimes better.

No, this is not possible with just a Button.

You would have to use a button without text and use a Label which you position like this:

Code (cpp) Select Expand

label->setPosition(tgui::bindPosition(button));

or if you want to fine-tune the distance to the top left corner a bit more:

Code (cpp) Select Expand

label->setPosition(tgui::bindPosition(button) + sf::Vector(4, 2));