Messages

Yes, this is indeed a typo (the code was like that in v0.5), thanks for reporting.

It will be fixed in the next few minutes.

when i use callback.text=="Open" only the first method will be called

I'm not sure what you mean with this.

The callback.text=="Open" should succeed for the Open item in the File, Tiles and Objects menus.
In order to identify which menu, you'll have to check callback.index as well (File will be 0, Tiles will be 2 and Objects will be 3).

I never really though that anyone would need the same string in the menu bar, so I never cared to look for a more intuitive way to handle that callback. But I did add the callback.index to make it possible.

Code Select Expand

this->moveTile
That won't work, it has to be "&Menu::moveTile".

You might need to know a little about c++11 and more specifically about std::function, std::bind and std::ref to fully understand this code. Without c++11 (or boost) it wouldn't be even possible to write something like this. The callback system is the only reason why tgui no longer supports older compilers.

It doesn't requires much code, but its not very easy.

Code Select Expand

void moveSprite(tgui::Slider::Ptr slider, sf::Sprite& sprite, int minY, int maxY)
{
    // Puts the sprite on position minY when the slider has value 0,
    // on position maxY when the slider has its maximum value,
    // and somewhere inbetween otherwise.
    // Note that this formula will only work when the minimum of slider is 0, otherwise it has to be changed.
    sprite.setPosition(sprite.getPosition().x, minY + (slider->getValue() / (float)slider->getMaximum()) * (maxY - minY));
}

// Let the slider call the moveSprite function when its value changes.
// The sprite will be placed between Y position 20 and 100, the X position will remain unchanged here.
slider->bindCallback(std::bind(moveSprite, slider, std::ref(sprite), 20, 100), tgui::Slider::ValueChanged);

This will only work when moveSprite is a free function. If it is part of a class, you need some different parameters.

Code Select Expand

// pointerToMyClassInstance will be 'this' when this line is inside a function of MyClass.
slider->bindCallback(std::bind(&MyClass::moveSprite, pointerToMyClassInstance, slider, std::ref(sprite), 20, 100), tgui::Slider::ValueChanged);

You might want to read the tutorial about callbacks.

If you have an sf::Texture that you want to display as a background of the child window, then you can use the setBackgroundTexture function.

Otherwise you have to create a Canvas widget inside the child window. The Canvas class is a wrapper around sf::RenderTexture, so you use it in the same way.

Code Select Expand

tgui::Canvas::Ptr canvas(*child);
canvas->setSize(child->getSize().x, child->getSize().y);

// This code is executed every time the sprite/texture changes.
// Either once when the sprite is a static image, or every frame when constantly changing the image.
canvas->clear();
canvas->draw(sprite);
canvas->display();


Code Select Expand

tgui::EditBox::Ptr name(*create);
That line is wrong.

What you are doing there is creating a new editbox variable, instead of using the one from the Menu class.

Replace that line (and the ones below it which have the same mistake) by the following:

Code Select Expand

create->add(name);

An alternative would be to call the constructor of the variable in the initialize list of the constructor of your Menu class, but that will just make it a lot more complicated in this case because the child window would not yet be fully initialized when initializing the edit box.

The getText function should work. Could you write a minimal but complete example code that reproduces the issue?

Btw, I really recommend using meaningful variable names, because you are making it ten times harder for someone else to understand your code by just using letters for variables.

When creating a button you pass its parent. So normally you have a line like this that will add the button to the gui.

Code Select Expand

tgui::Button::Ptr button(gui);

The only difference is that instead of the gui you now just pass the child window.

Code Select Expand

tgui::ChildWindow::Ptr child(gui);
tgui::Button::Ptr button(*child);

This is actually the first time that I notice that I have been talking to different persons in this topic .

Otherwise, I'm happy to wait until your updated release.

I try to not make multiple releases in less than a month, especially not for one small bug. Creating these precompiled libraries is too time consuming. I have automated the compilation, but there is still a lot of work to do on every release. So you shouldn't expect a v0.6.4 release soon.

There are two ways to get the changes from github. The first way is to go to the github page and click the "Download ZIP" button. Then follow the CMake tutorial for VS or the CMake tutorial for C::B. In short, you run cmake which creates a project file which you then open and build which will provide you with the libraries.

The other way is slightly more work, but will make it a lot faster to recompile the libraries if I make another change. You will need to download git and then clone my repository (running "git clone https://github.com/texus/TGUI" from the command line will create the TGUI folder). Then follow the same steps as in the other option. But if I make a change afterwards, then all you need to do is pull the latest changes ("git pull" from the command line). The cmake step is no longer needed, you can directly open the project file and rebuild it.
I usually do it all from a terminal as I'm used of doing this on linux, but there are also graphical interfaces available on windows to make it even easier.

I've made a commit on github that should hopefully fix your problems.

The change is not finished yet (Tab widget hasn't been changed yet, and I still have to actually test the code), but I hope that it will work for what you need so that you don't have any problems with this anymore.

After I finish the change (hopefully tomorrow) I'll make sure to fully test it with different viewports, view sizes and view centers to make sure that my code finally supports every combination.

Damn. I'll make sure to look for a different way to do the clipping in v0.7.

The Label has to know its absolute position on the screen, but it currently only knows its relative position.
I'll see if I can fix it this evening.

Edit: the bug seems to be a little trickier than I thought. I'll try to have it fixed tonight or tomorrow though.

Strange. I just tested creating a Label like this and I could not reproduce it.

Code Select Expand

tgui::Label::Ptr label(gui);
label->setText("Hello");

After compiling SFML, did you compile TGUI again with the new SFML libraries?
Depending on your compiler you could also just use the precompiled libraries.

You forgot to load a font.

Add this after creating the gui:

Code Select Expand

gui.setGlobalFont("data/TGUI/fonts/DejaVuSans.ttf");

I had to add that to even get the text in the buttons and editbox to show up.

But on top of this, the labels are white, so is your background. So also try changing the text color:

Code Select Expand

labelUsername->setTextColor(sf::Color::Black);

The fix has been made on the master branch on github (https://github.com/texus/TGUI), which will be released as v0.6.3 later this weekend.

I don't totally understand your code

That piece of code isn't meant to be understood. Its meant to be written once and hope that you never have to change it again .
The reason why it is so complex is because I need the coordinate on the sceen with the bottom left corner being the origin. To find that point I have to take into account that sfml has its origin in the top left corner, the view size can be different than the window and I also have to watch the viewport apparently.
Maybe if SFML issue #1 gets added one day it would become a lot easier.

(You just wrote m_background and m_size in place of m_Background and m_Size :p)

Thats because I was developing on the v0.7 branch, I made a small naming convention change there. Luckily you could see the mistake yourself here, in other widgets there were differences like m_LeftBorder vs m_borders.left.

I didn't notice that the Label was inside a Panel at first. The Panel is also doing some clipping.

The changes that have to be made are in the calculation of topLeftPosition and bottomLeftPosition. These calculations did not take the viewport into account. When I wrotes these formulas once I hoped that I would never have to touch them again, but it seems that they weren't perfect after all.

The code in Label.cpp has to be

Code Select Expand

sf::Vector2f topLeftPosition
    = states.transform.transformPoint(((getPosition().x - target.getView().getCenter().x + (target.getView().getSize().x / 2.f)) * target.getView().getViewport().width) + (target.getView().getSize().x * target.getView().getViewport().left),
                                      ((getPosition().y - target.getView().getCenter().y + (target.getView().getSize().y / 2.f)) * target.getView().getViewport().height) + (target.getView().getSize().y * target.getView().getViewport().top));
sf::Vector2f bottomRightPosition
    = states.transform.transformPoint((getPosition().x + m_background.getSize().x - target.getView().getCenter().x + (target.getView().getSize().x / 2.f)) * target.getView().getViewport().width + (target.getView().getSize().x * target.getView().getViewport().left),
                                      (getPosition().y + m_background.getSize().y - target.getView().getCenter().y + (target.getView().getSize().y / 2.f)) * target.getView().getViewport().height + (target.getView().getSize().y * target.getView().getViewport().top));

And in Panel.cpp

Code Select Expand

sf::Vector2f topLeftPosition
    = states.transform.transformPoint(((getPosition().x - target.getView().getCenter().x + (target.getView().getSize().x / 2.f)) * target.getView().getViewport().width) + (target.getView().getSize().x * target.getView().getViewport().left),
                                      ((getPosition().y - target.getView().getCenter().y + (target.getView().getSize().y / 2.f)) * target.getView().getViewport().height) + (target.getView().getSize().y * target.getView().getViewport().top));
sf::Vector2f bottomRightPosition
    = states.transform.transformPoint((getPosition().x + m_size.x - target.getView().getCenter().x + (target.getView().getSize().x / 2.f)) * target.getView().getViewport().width + (target.getView().getSize().x * target.getView().getViewport().left),
                                      (getPosition().y + m_size.y - target.getView().getCenter().y + (target.getView().getSize().y / 2.f)) * target.getView().getViewport().height + (target.getView().getSize().y * target.getView().getViewport().top));

I'm going to sleep now, but I'll continue this tomorrow. Other widgets will need the same fix, and I somehow feel that there is also something wrong when changing the view size.

I'm surprised that a bug as big is this one hasn't been noticed before. I guess nobody needed to change the viewport in his program until now.

Ok, I can reproduce it but I'll look into this in more detail tomorrow.

The only thing you can do now is comment out line 378 in Label.cpp (the one with glScissor) and compile the changed tgui version. That will disable the clipping in Label, which is not really needed in 99.9% of the cases anyway.

But some other widgets are going to have the same problem, so I'll try to fix this as soon as possible.

This is most likely a bug in tgui. The viewort isn't used in calculations.

But I can't immediately reproduce it, could you send a small example code the produces the error?

(Texus: I speak french at first, and I can see you're belgian, so can I speak with you in french?)

Nope, I speak dutch. I know a little french, but not enough to really communicate with it.

Edit: I've been able to reproduce it. I'm looking into it.
Edit2: I can only reproduce a similar bug, not yet the exact same thing. So I can still use an example so that I can test whether my fix holds in your situation as well (which I doubt).

I changed this part though, still look good?

Yep, that still looks good.

// <---since we already found a widget, why keep going, why not break out of loop; ?

As you can see, when the boolean is false, the mouseNotOnWidget() function is called.
Imagine the following situation:
You move the mouse on the background picture, and then continue to move the mouse over a button (which is on top of the picture). Since we are looping over the widgets backwards, we will find the button. But the picture will never be told that the mouse is no longer on top of it. Hence once we find the widget, we tell all remaining ones that the mouse can't be on them.

Edit: I though about it a bit longer and you can indeed use the shorter code. Its only inside tgui that the longer version is required.

As said, option 1 isn't that hard:

Code Select Expand

#include <TGUI/TGUI.hpp>

///////////////////////////////////////////////////////////////////////

tgui::Widget::Ptr mouseOnWhichWidget(float x, float y, std::vector<tgui::Widget::Ptr>& widgets)
{
    bool widgetFound = false;
    tgui::Widget::Ptr widget = nullptr;

    // Loop through all widgets
    for (std::vector<tgui::Widget::Ptr>::reverse_iterator it = widgets.rbegin(); it != widgets.rend(); ++it)
    {
        // Check if the widget is visible and enabled
        if (((*it)->isVisible()) && ((*it)->isEnabled()))
        {
            if (widgetFound == false)
            {
                // Return the widget if the mouse is on top of it
                if ((*it)->mouseOnWidget(x, y))
                {
                    widget = *it;
                    widgetFound = true;
                }
            }
            else // The widget was already found, so tell the other widgets that the mouse can't be on them
                (*it)->mouseNotOnWidget();
        }
    }

    return widget;
}

///////////////////////////////////////////////////////////////////////

int main()
{
    sf::RenderWindow window(sf::VideoMode(930, 700), "TGUI window");
    tgui::Gui gui(window);

    if (gui.setGlobalFont("TGUI/fonts/DejaVuSans.ttf") == false)
        return 1;

    tgui::Widget::Ptr draggingWidget = nullptr;
    sf::Vector2f draggingPosition;

    tgui::Panel::Ptr panel1(gui);
    tgui::Panel::Ptr panel2(gui);

    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
            else
            {
                if (event.type == sf::Event::MouseButtonPressed)
                {
                    tgui::Widget::Ptr widget = mouseOnWhichWidget(event.mouseButton.x, event.mouseButton.y, gui.getWidgets());
                    if ((widget.get() == panel1.get()) || (widget.get() == panel2.get()))
                    {
                        if (mouseOnWhichWidget(event.mouseButton.x, event.mouseButton.y, tgui::Panel::Ptr(widget)->getWidgets()) == nullptr)
                        {
                            draggingWidget = widget;
                            draggingPosition = sf::Vector2f(event.mouseButton.x, event.mouseButton.y);
                        }
                    }
                }
                else if (event.type == sf::Event::MouseButtonReleased)
                {
                    draggingWidget = nullptr;
                }
                else if (event.type == sf::Event::MouseMoved)
                {
                    if (draggingWidget != nullptr)
                    {
                        draggingWidget->setPosition(draggingWidget->getPosition().x + event.mouseMove.x - draggingPosition.x,
                                                    draggingWidget->getPosition().y + event.mouseMove.y - draggingPosition.y);

                        draggingPosition = sf::Vector2f(event.mouseMove.x, event.mouseMove.y);
                    }
                }
            }

            gui.handleEvent(event);
        }

        window.clear();
        gui.draw();
        window.display();

        sf::sleep(sf::milliseconds(1));
    }

    return 0;
}

While writing the code I even found a bug in tgui . Trying to compare two widget pointers is not possible (function can't access private variable). That is why you have to use the '.get()' like in the above code.

Are there options I didn't see?

I don't see another option either.

3. Make child windows transparent and disabled when not in moving mode. Unfortunately when transparent, the child window (logically) makes its contents transparent too.

There are of course workarounds to avoid making the whole contents transparent (without having to reset the transparency of every single widget in the window). You could have a panel inside the child window and all widgets inside the panel. Then after setting transparency of the child window to 0, you just set the panel to transparency 255 again.
But disabling the child window will also disable the widgets inside it, so this might not even be an option.

1. First idea was panels, but they can't be moved around without me doing stuff with them, and I'd rather just do solution 4 than have to deal with panels that overlap, are invisible, and or are disabled.

If you would use a slightly edited version of the code in Container::mouseOnWhichWidget then it shouldn't be much of a problem. But unlike my suggestion before which didn't handle overlapping, you have to call the code twice: once to find out on which panel the mouse is on, and then on the widgets inside the panel to check if the mouse is on them. The code in that function also takes care of ignoring the invisible and disabled widgets.

But whatever way you choose, it will always be kindof a hack.

This is not yet available, you will have to implement this yourself.

The simpelest way to check if the mouse is on top of the panel and not on top of any of its widgets is with the mouseOnWidget function:

Code Select Expand


// Do this when the mouse goes down
if (panel->mouseOnWidget(x, y)
{
    bool mouseOnAnyWidget = false;
    for (auto& widget : panel->getWidgets())
    {
        if (widget->mouseOnWidget(x - panel->getPosition(), y - panel->getPosition()))
        {
            mouseOnAnyWidget = true;
            break;
        }
    }

    // If mouseOnAnyWidget is false here then you should start dragging the panel, until you get a mouse released event
}

This code has a few limitations:
- There should not be an overlapping widget in front of the panel
- The widgets inside the panel should not be overlapping
- Invisible and disabled widgets will react on this code

If you need to work around the second or third limitation (if you use invisisible or disabled widgets, or if widgets in your panel overlap) then just have a look at this code: https://github.com/texus/TGUI/blob/master/src/TGUI/Container.cpp#L1267 (the function is private, but you can almost literaly copy the code.

I deliberatly left this option out, because when handing the events, the gui won't know about these states. (read: I once added it but then I noticed that it didn't work so I removed it again)

I haven't looked yet at the changes you made, but when scaling like that you should notice that although the gui gets scaled correctly, the mouse events (e.g. button changing color on mouse hover) will still happen as if the gui wasn't scaled, thus when the mouse is on the wrong position.
Does it actually work with your changes?

What you want is probably to change the view. When passing 'false' to gui.draw and gui.handleEvents, they will use the current view from the window. So if you set the view to twice as small, the gui will appear twice as big.

The gui.draw function takes care of the rendering and the gui.handleEvent function takes care of sending the events to the widgets and making them respond in the right way.

So if you tell the draw function to use a different view then you should also give this view to handleEvent.

Code Select Expand

gui.handleEvent(event, false);

Also make sure that the same view is set at the moment the draw function is called and at the moment handleEvent is called. But this doesn't look like a problem in your minimum code.

So, i must try to compile sfml with my compiler?

You can try it. But if you really downloaded the SJLJ version and the compiler used by codeblocks is still the correct one then it isn't going to make a difference.

I noticed, that the app requires at once libgcc_s_dw2-1.dll and libgcc_s_sjlj-1.dll. How he can require two different libraries at once?

I never had this problem, so I can only guess. You have three things: the code that you compile yourself, the sfml libs and the tgui libs. I would except that one of these is compiled with the wrong compiler.

But I would expect linking errors when you are using a library that is compiled agains the wrong compiler version. So maybe the sfml and tgui dlls that you have next to your exe are wrong while the .a files are the right ones. You can also try static linking, if the problem is with the dlls then this will work.

Anyway, perhaps you should send me the full project (e.g. on dropbox), including the sfml and tgui libraries and dlls. That way I can try replacing some of these files with versions on my pc and perhaps discover where the mistake is.

I get the same error, but the procedure is gxx_personality_sj0

These kind of errors mean that the libraries aren't compatible with the compiler as far as I know.
But it seems like one part tries to use gxx_personality_v0 (dwarf2?) and another part gxx_personality_sj0 (sjlj?).

Did you compile sfml yourself as well (with the same compiler)?

Perhaps you can try with the tgui precompiled libraries. It also includes the sfml libraries, so you'll be sure that the libraries are compatible. And they has been tested with MinGW 4.7.1-TDM.