Messages

You are already linking to opengl so I suspect the problem is in the library order. The dependencies belong behind the library in gcc. Just like you have tgui before sfml and sfml-window before sfml-system, you should put GL after tgui. This does not matter for dynamic linking, but you are linking to tgui statically.

This is unrelated but you should be aware of one thing: you should always link tgui in the same way as sfml. I have never tried static linking on linux so I can't tell if it gives problems or not, but on windows linking like you are doing leads to linking errors or crashes. Either link both tgui and sfml dynamically or link both of them statically. I would suggest dyamic linking because linking statically to sfml on linux can be a pain.

Edit: nevermind this post, I didn't read your edit.

src/main.cpp:11:19: error: no matching constructor for initialization of
      'tgui::Label::Ptr' (aka 'shared_ptr<tgui::Label>')
        tgui::Label::Ptr labelUsername(gui);

You are still using example code for 0.6 while you have tgui 0.7-dev installed.

In both versions tgui::Label::Ptr exists, but only in v0.7 is it of type shared_ptr<tgui::Label>. In v0.6 I had my own smart pointer class which allowed me to define my own constructor which could take the gui as parameter.

You should try with the following code (you will have to edit the filenames of font, images and themes for the code to actually run).

Code (cpp) Select Expand

#include <TGUI/TGUI.hpp>

void login(tgui::EditBox::Ptr username, tgui::EditBox::Ptr password)
{
    std::cout << "Username: " << username->getText().toAnsiString() << std::endl;
    std::cout << "Password: " << password->getText().toAnsiString() << std::endl;
}

void loadWidgets( tgui::Gui& gui )
{
    // Get a bound version of the window size
    // Passing this to setPosition or setSize will make the widget automatically update when the view of the gui changes
    auto windowWidth = tgui::bindWidth(gui);
    auto windowHeight = tgui::bindHeight(gui);

    // Create the background image (picture is of type tgui::Picture::Ptr or std::shared_widget<Picture>)
    auto picture = tgui::Picture::create("../xubuntu_bg_aluminium.jpg");
    picture->setSize(tgui::bindMaximum(800, windowWidth), tgui::bindMaximum(600, windowHeight));
    gui.add(picture);

    // Create the username edit box
    auto editBoxUsername = tgui::EditBox::create("../../widgets/Black.conf");
    editBoxUsername->setSize(windowWidth * 2/3, windowHeight / 8);
    editBoxUsername->setPosition(windowWidth / 6, windowHeight / 6);
    editBoxUsername->setDefaultText("Username");
    gui.add(editBoxUsername, "Username");

    // Create the password edit box (we will copy the previously created edit box)
    auto editBoxPassword = tgui::EditBox::copy(editBoxUsername);
    editBoxPassword->setPosition(windowWidth / 6, windowHeight * 5/12);
    editBoxPassword->setPasswordCharacter('*');
    editBoxPassword->setDefaultText("Password");
    gui.add(editBoxPassword, "Password");

    // Create the login button
    auto button = tgui::Button::create("../../widgets/Black.conf");
    button->setSize(windowWidth / 2, windowHeight / 6);
    button->setPosition(windowWidth / 4, windowHeight * 7/10);
    button->setText("Login");
    gui.add(button);

    // Call the login function when the button is pressed
    button->connect("pressed", login, editBoxUsername, editBoxPassword);
}

int main()
{
    // Create the window
    sf::RenderWindow window(sf::VideoMode(400, 300), "TGUI window");
    tgui::Gui gui(window);

    try
    {
        // Load the font
        gui.setGlobalFont("../../fonts/DejaVuSans.ttf");

        // Load the widgets
        loadWidgets(gui);
    }
    catch (const tgui::Exception& e)
    {
        std::cerr << "Failed to load TGUI widgets: " << e.what() << std::endl;
        return 1;
    }

    // Main loop
    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            // When the window is closed, the application ends
            if (event.type == sf::Event::Closed)
                window.close();

            // When the window is resized, the view is changed
            else if (event.type == sf::Event::Resized)
            {
                window.setView(sf::View(sf::FloatRect(0, 0, event.size.width, event.size.height)));
                gui.setView(window.getView());
            }

            // Pass the event to all the widgets
            gui.handleEvent(event);
        }

        window.clear();

        // Draw all created widgets
        gui.draw();

        window.display();
    }

    return EXIT_SUCCESS;
}

Here's the complete log ...

Those errors mean that you are using tgui 0.7-dev with the example code from 0.6.

Adding #include <SFML/Window.hpp> as mentionned in the example

What example? When using TGUI you don't have to include SFML manually since the tgui header will do that for you.

brings up an error #include <ostream> file not found

That sounds like something is seriously corrupted. The <ostream> header is part of the std library so you must have it on any working system.

I think there is something seriously wrong with your system, you might want to try removing and reinstalling gcc and clang and associated packages. You should be able to use tgui like:

Code Select Expand

clang++ -std=c++11 Scalable.cpp -ltgui -lsfml-graphics -lsfml-window -lsfml-system

And that was not even the full error message ... the rest gets clipped out by the terminal character limit

I'm actually going to need the first lines to help, because the lines you posted don't contain much information.

You should add something like "> output.txt" behind your command to redirect it to a file. That way you won't lose the top part of the error if it is too long.

It is not possible for checkbox, you would have to use a checkbox without text and put a Label next to it.

There is a Canvas widget which lets you draw sfml stuff inbetween tgui widgets. It works like a sf::RenderTexture.

So you would get something like this (code was not tested).

Code (cpp) Select Expand

Canvas::Ptr canvas(*panel); // Add canvas to the panel (before adding the labels, so that it is drawn behind the labels)

canvas->setSize(panel->getSize()); // Fill the entire panel so we can draw anywhere on it

// Before the gui.draw call you draw on the canvas
canvas->clear();
sf::RectangleShape labelBackground;
labelBackground.setSize(sf::Vector2f(maxX, getDataRowSize()));
labelBackground.setPosition(LabelList[i]->getPosition().x, LabelList[i]->getPosition().y);
labelBackground.setFillColor(sf::Color::Red);
canvas->draw(labelBackground);
canvas->display();

I would expect there to be a step 7: updateMaxAmount gets called for column 2 again and everything is correct again.

What about finding out which column has the most rows and set the maximum once with that value?

I guess you should just pick any method that works, even if it is a bit of a hack.

Ok, that explains why the callback gets created. But the behavior of the gui seems to be correct because the value really does change during the process.

But what exactly are you trying to solve here? The callback function is called because you first set the maximum too high and then you set it back. But for what situation are you putting it higher first?

Also it shouldn't be a problem that the callback function gets called again. If it is then there is probably some code in there that doesn't belong there. A function like the scrollRightPanelHorizontal in your example can be called multiple times without problems.

However if I then call the setMaximum, the callback function gets called as I assume the trigger of tgui::ScrollBar::ValueChanged gets hit when I update the maximum.

This should not happen in the first place. I just checked the code and although it tries to set the value to 0, the callback function will only be called if the value is actually changed, so when it wasn't 0 already. So calling just setMaximum should not trigger the callback function. So can you write a minimal code that reproduces it?

Is it so bad that the callback function gets called?
You could always compare scrollbar->getMaximum and scrollbar->getLowValue in the callback function and simply return from the function when you find the scrollbar is invisible.

Question is how do I get the callback function details?

In v0.6 it is not yet possible to unbind a specific function. Right now you can only unbind all callbacks connected to a certain trigger. But normally you don't have multiple callback connected to ValueChanged, so you can just do "scrollbar->unbindCallback(tgui::Scrollbar::ValueChanged);".

But I will make the bindCallback function return an id and add a unbindCallbackById function in v0.6.8 to have a bit more control.

How can I get the the bind function from the original scrollbar so that I can re-set it?

You can't but I will see if I can add a "retrieveCallback(id)" function as well.

vector<Widget::Ptr> widgetList = gui.getWidgets();

I was going to add that by doing the above you were copying that list and that you could take a reference to it instead and change the list directly. However I realize that although this is possible, it is a serious bug. If you do change the list directly then tgui might crash because just removing an element from that list is not enough to properly remove a widget. So I'll make a change soon that will prevent a reference and forces you to either copy the list like you do now, or take a constant reference "const vector<Widget::Ptr>& widgetList = ..." to avoid unnecessary copy.

I've written the below which I think will do it?

The code will not work for panels inside panels. In order to support that the function should be made recursive: remove labels and make a recursive call for each panel. Nevertheless it will probably work fine in your situation.

I tend to always just reload the whole screen when changing game state (possible create the screens up front and just swap the visible panel), but there is no right way to do it. You should probably do whatever is easier for your situations.

It seems like the documentation of WidgetType is indeed lacking.
It isn't a string, it's an enum: https://tgui.eu/documentation/v0.6/Global_8hpp_source.html#l00080

So the code should be

Code Select Expand

if (widgetList[i]->getWidgetType() == tgui::Type_Label)

The problem should be fixed now. I can't test it myself since even your code works here (even though it is clear that it accessed the 3th element from an array containing only 2 elements), it just won't crash on linux.

Thanks for taking the time to debug the issue and find the exact cause.

In order to use the new version, download it and build the libraries with cmake.

I'll have a look at this later today.

please note that it only happens with the "menu->moveToFront();", which was my attempt to make sure the top menu bar is always on-top of everything.

The list of the combo box is actually a separate widget which is always in front of all other widgets. So the combination with the open combo box and the moveToFront call probably mess some internal things up.

yes. this happens when the user select an item from a top bar and "switch" edit mode for say from editing tiles to editing objects, then I hide all the tiles-related windows and show all the objects-related windows.

Could you give me a bit more information about this? What type of widget do they click on and on which callback do you react (e.g. LeftMouseClicked)?

If you can get a minimal code that reproduce this then that would be nice.

Do you have a callback bound to the focus events on widgets? Do you run these show and hide calls inside a function callback from a tgui widget? Do you remove widgets somewhere or do you only hide and show them?

Sorry for replying so late, but for some reason I didn't get any notification for this topic.

getWidgetName is a function in Container, not Widget, so it is intended to be called on a parent widget. With that function you ask the panel for the name of one of the widgets that it contains. The panel doesn't contain itself so it returns false and doesn't set a name.

So you must call getWidgetName on the parent of the panel.

Code (cpp) Select Expand

gui.getWidgetName(PanelList.back(), test);

There are two mistakes with the bindCallbackEx call (both are details about how c++ works).

In order to reference to a function inside a class, you must pass "&ClassName::functionName".

The second mistake is really an internal detail of c++. I will quote from my v0.7 tutorial where I explained it better than in the v0.6 one (where I just briefly mention it).

Member functions are special. You must first understand a technical detail in c++ in order to bind them.

Suppose you have the following class:

class MyClass
{
    void function(int i);
}

That function takes one parameter, right? Wrong.
That function takes 2 parameters. Behind the scenes the function looks like this:

void function(MyClass* this, int i);

That is where your 'this' pointer is coming from.

So the function you want to call does not has 2 parameters, it has 3. You have to provide the "this" pointer which is a pointer to your class instance.

Which means that the line should be the following:

Code Select Expand

scrollbar->bindCallbackEx(std::bind(&scrollTest::scrollPanel, &scrollClass, panel, std::placeholders::_1), tgui::Scrollbar::ValueChanged);

Green bars are new, but I have seen image corruption on these places in the images before.
I suspect that it is related to the graphics driver, you should try updating it.

You can verify that the problem is not related to tgui by testing this code

Code Select Expand

// Load a small to medium sized texture, set it to repeat
sf::Texture texture;
texture.loadFromFile("Filename.jpg");
texture.setRepeated(true);

// Create the sprite and give it a texture rect that is several times larger than the size of the texture
sf::Sprite sprite;
sprite.setTexture(texture);
sprite.setTextureRect({0, 0, 800, 600});

// Draw the sprite and see if it displays without gaps between the repeated texture
window.draw(sprite);

If updating the graphics driver does not help and the above code also fails to display correctly then you will have to use v0.7-dev which by default relies on stretching images instead of texture repeating.

Which packet did you download? What compiler are you using?

Edit: I just looked up a bit more info on the error, are you by any chance trying to link to the dll file? You must link against the lib files and just copy the dll files next to the exe, don't put the dll in the linker options.

There is no way to disable it, but I don't think these warnings are really needed. So I just removed them.

You can download the new version on github. You will have to build the libraries yourself with cmake.

I assume that my previous message contained an empty quote for u too? It apparently contained an unknown character and no longer showed up here (unlike when that post was created half a year ago).

You should add the "-std=c++11" compiler flag (or "-std=c++0x" if you don't have that option) to your project.

It is because you have SFML 2.1 installed while TGUI 0.6.7 requires SFML 2.2.

Either install SFML 2.2 (by compiling it yourself like you do with TGUI) or install TGUI 0.6.6.

I will update the information on the dowload page as it still says that tgui compiles with any sfml 2.x version.

I have never compiled for 64bit before on windows, so I can't give you an exact guide, but it should be similar to compiling tgui normally. You must have made changes in your project to compile for x64, you just have to make the same changes when compiling tgui.

Follow the visual studio with cmake tutorial for how to build tgui.
In case you have different sfml versions on your pc: when cmake prints "Found SFML: SFML_Path/include", then check that SFML_Path/lib contains your 64-bit sfml libs.
When opening the VS project to compile tgui after running cmake, you have to somehow set the target to x64 before building.

I notice several x64 folders in the project. Are you by any chance building for 64-bit and using the 64-bit sfml libraries? Because the tgui libraries are compiled for 32-bit. If you are using the x64 target then you must recompile tgui in the same way.

If that is not the problem then I will have a more thorough look at these files tomorrow.

Your project indeed seems to be set up correctly.
You could test one thing though: changing the order of the libraries that you link. Although I doubt that it will make much of a difference because only the sfml libs are mentioned in the wrong order and it shouldn't really matter with dynamic linking.

I guess I will have to test it here myself.
Are you using the precompiled VS2013 libraries from both SFML and TGUI? (or did you compile one of them yourself?)
Could you perhaps upload your full project including the sfml and tgui libraries and header (the entire folders basically) somewhere (e.g. dropbox)? Then I can test with identical circumstances and swap libraries to see if it changes anything.

PS: It is already late here, I will have a look at it tomorrow.

That is the wrong file , I need the project file.