Messages

Since it contains all the info you are asking for I'll just link to this existing answer: https://forum.tgui.eu/index.php?topic=424.msg2282#msg2282

In short: the connect function does function, just not a specific use case of it. You could even bind the parameters yourself but that requires knownledge on std::bind. But without binding parameters manually you can still get data back from the widget with connectEx.

The issue is that VS2013 does not support expression SFINAE yet while the online examples are already using it. Any GCC compiler since 2013 can compile that code but Visual Studio only added support for it 2 months ago with VS2015 Update 2. The example code on the website uses the unbound parameters feature of the connect function which is not supported in VS2013.

Of course removing these two parameters in the connect call is giving you the other error because you are then calling a function with less parameters than it needs.

Since you are the second person to mention something like this I will change my online examples tomorrow (or somewhere this week) to make it work with VS2013 as well. In the meantime you can check the "examples" folder in the TGUI folder that you downloaded, they do compile on VS2013.

The latest version (which you can download on github) now no longer overwrites these RGB values. So your code will work if you download and build that version.

The fix isn't perfect and the alpha value will remain unchangeable in v0.7 but I'm already solving the problem in a better way in v0.8-dev so that it will even be possible to have normal and hover textures with different alpha values. But what you want to do at least already work now.

It seems like I overwrite the color to set the transparency, the setHoverTexture contains the following line:

Code (cpp) Select Expand

m_textureHover.setColor({255, 255, 255, static_cast<sf::Uint8>(m_button->getOpacity() * 255)});

So you could remove that line from TGUI/src/Widgets/Button.cpp and rebuild tgui.

I'll probably update the code later today to set the alpha in that color without overwriting the RGB values. But I will immediately do that for all widgets.

Ah you are using the example on the website, I though you were trying to compile the ones in the examples folder the comes with tgui (which I have just tested and build successfully).

Apparently I have used unbound parameters in the online examples. This feature relies on expression SFINAE which is already supported since 2013 in gcc, but Visual Studio has only added enough support for it less than 2 months ago in VS2015.

What basically doesn't work in VS2013 is this:

Code (cpp) Select Expand

void func(std::string s);
widget->connect("pressed", func); // value for s is not provided anywhere!

It only works when binding the value yourself:

Code (cpp) Select Expand

void func(std::string s);
widget->connect("pressed", func, "ValueOfParameter");

You should check the connectEx function if you need to get e.g. the value of the button as parameter to the function in VS2013.

Could you show the line in your main function where it goes wrong?
In the error it says "main.cpp(21)" which I assume contains a call to the "connect" function. From the error it would seem that you are passing a function with an std::string parameter which is not supported in VS2013 (unbound parameters require VS2015 Update 2).

But since you are saying that it also occurs in the examples there might be something else wrong. Could you show the errors that you get when you compile e.g. the "scalable" example?

EditBox is a single line, TextBox is multi-line (including word-wrap and a vertical scrollbar).

That is also an android bug: see here.
You could try to change this in sfml manually: https://github.com/gordonmcshane/SFML/commit/c89d1a987bc8358ea87c56c5aac5f25e4fec8e2d

The commit before they broke sRGB seems to be c4956857faed4b42487f893042116b9745fb9e98 from March 7th, so if you use git to download sfml (using "git clone") then you can do "git checkout c4956857faed4b42487f893042116b9745fb9e98" to get that version.

The issue was fixed in SFML on March 1 (while SFML 2.3.2 already dates back from August 2015), so if you compile SFML from github and then rebuild TGUI with that SFML version installed then everything should work.

Are you using the latest SFML version (the master branch from github)? There was a bug in SFML 2.3.2 which caused such a crash, although the crash occured before the keyboard even opened here.

If you add the scrollbar to the container with container->add then its position is relative to the container, so "scrollbar->setPosition(container->getPosition() + sf::Vector2f(container->getSize().x, 0));" should be "scrollbar->setPosition(sf::Vector2f(container->getSize().x - scrollbar->getSize().x, 0));" to avoid it from being outside the visible part of the container.

If you copy the table into your own code you shouldn't keep it in a "tgui" namespace of course. Otherwise the linker finds tgui::Table twice.

It I would have enough time I would write it myself, but I'm very busy until the beginning of June.

TableRow apparently inherit from Panel, so you can connect to the "clicked" event.
But you would have to call the connect function on every row.

Alternatively the following could be added to the Table class and then you can get a callback with the index of the clicked row as parameter:
- Add `addSignal<int>("RowClicked");` in Table constructor
- Add `row->connect("Clicked", &Table::rowClicked, this, row);` right before the return in Table::insert
- Add a Table::rowClicked function like this:

Code (cpp) Select Expand

void Table::rowClicked(tgui::Widget::Ptr widgetOnWhichYouClicked)
{
    for (unsigned int i = 0; i < m_widgets.size(); ++i)
    {
        if (m_widgets[i] == widgetOnWhichYouClicked)
        {
            m_callback.index = i;
            sendSignal("RowClicked", i);
        }
    }
}
- You will now be able to connect a callback function to the table for when a row is clicked, e.g. `table->connect("RowClicked", [](int i){ /* row i was clicked */ });`

I don't think there is a clean solution for it, but it might not be too hard hack some working code together. You will have to edit the table class though (you might even better just copy the Table class in your own code).

1) Create the scrollbars inside the child window and place them next to the table (so not part of the table itself as this might cause problems with passing events to it)
2) Add a setVisibleSize function to Table in which you store the size that you want it to have on your screen
3) Add functions to the Table class (e.g. setHorizontalScrollbar) to pass a pointer to the scrollbar to it.
4) Change Tabel::draw to something like this (first two lines depend on the variables that you should create for step 2 and 3):

Code (cpp) Select Expand

// Set the position (Note: everything above and to the left of getPosition() will be clipped by the other code in this function)
states.transform.translate(getPosition() - sf::Vector2f(m_horizontalScrollbar->getValue(), m_verticalScrollbar->getValue()));

// Set the wanted size
sf::Vector2f visibleSize = m_visibleSize;

// Clipping magic
const sf::View& view = target.getView();
float scaleViewX = target.getSize().x / view.getSize().x;
float scaleViewY = target.getSize().y / view.getSize().y;
sf::Vector2f topLeftPosition = {((getAbsolutePosition().x - view.getCenter().x + (view.getSize().x / 2.f)) * view.getViewport().width) + (view.getSize().x * view.getViewport().left),
                                ((getAbsolutePosition().y - view.getCenter().y + (view.getSize().y / 2.f)) * view.getViewport().height) + (view.getSize().y * view.getViewport().top)};
sf::Vector2f bottomRightPosition = {(getAbsolutePosition().x + visibleSize.x - view.getCenter().x + (view.getSize().x / 2.f)) * view.getViewport().width + (view.getSize().x * view.getViewport().left),
                                    (getAbsolutePosition().y + visibleSize.y - view.getCenter().y + (view.getSize().y / 2.f)) * view.getViewport().height + (view.getSize().y * view.getViewport().top)};
GLint scissor[4];
glGetIntegerv(GL_SCISSOR_BOX, scissor);
GLint scissorLeft = std::max(static_cast<GLint>(topLeftPosition.x * scaleViewX), scissor[0]);
GLint scissorTop = std::max(static_cast<GLint>(topLeftPosition.y * scaleViewY), static_cast<GLint>(target.getSize().y) - scissor[1] - scissor[3]);
GLint scissorRight = std::min(static_cast<GLint>(bottomRightPosition.x * scaleViewX), scissor[0] + scissor[2]);
GLint scissorBottom = std::min(static_cast<GLint>(bottomRightPosition.y * scaleViewY), static_cast<GLint>(target.getSize().y) - scissor[1]);
if (scissorRight < scissorLeft)
    scissorRight = scissorLeft;
else if (scissorBottom < scissorTop)
    scissorTop = scissorBottom;
glScissor(scissorLeft, target.getSize().y - scissorBottom, scissorRight - scissorLeft, scissorBottom - scissorTop);

// Draw the background
if (m_backgroundColor != sf::Color::Transparent)
{
    sf::RectangleShape background(getSize());
    background.setFillColor(m_backgroundColor);
    target.draw(background, states);
}

// Draw the widgets
target.draw(*m_header, states);
drawWidgetContainer(&target, states);

for (std::size_t i = 0; i < m_columnsDelimitators.size(); ++i)
    target.draw(m_columnsDelimitators[i], states);

// Reset the old clipping area
glScissor(scissor[0], scissor[1], scissor[2], scissor[3]);


No it hasn't been implemented yet, everything planned for 0.7-beta and 0.7-RC was delayed to 0.8.
You can try using the (not entirely finished) Table widget if that comes close enough to what you need. There is an example in the "examples/table-devel" folder.

Since every commit that is pushed to github is tested with VS2013 and VS2015 there must be something different between the compiler on the test server and the one that you have.

Do you have the latest update of VS2013 installed?
VS2013 Update 4 should definately be enough, I don't know about earlier version.

It is so long ago that I used tgui 0.6 myself that I completely forgot how the view worked in that version.

If you decide to stay with 0.6 then instead of calling gui.setView you have to pass "false" as extra parameter to both gui.draw in gui.handleEvents to fix your problem.

If you have to change a lot of code then you could perhaps better stay with v0.6 because you will have to rewrite practically everything to move to v0.7.

The closest equivalent to bindCallbackEx would be the connectEx function, but that function only exists because the normal connect function requires a good compiler for complex bindings. If you want to learn how the new callback system works you can start by reading the introduction tutorial.

The gui has its own view, theResizedWindow.setView will only affect your own sfml drawing.
You have to call gui.setView(recalculatedDefaultView) is you want tgui to take the new view into account as well.

If you don't update tgui they you could still clip the texture yourself before passing it to Picture:

Code (cpp) Select Expand

sf::Texture texture;
texture.loadFromImage(largeTexture.copyToImage(), intRect);
auto picture = std::make_shared<tgui::Picture>(texture);

Whatever you pass tp setText will be displayed inside the bar, so everytime you change the value you can do something like this:

Code (cpp) Select Expand

hp->setText(std::to_string(hp->getValue()));

Or if you want the total to be visible as well:

Code (cpp) Select Expand

hp->setText(std::to_string(hp->getValue()) + " / " + std::to_string(hp->getMaximum()));

The last part shouldn't really be necessary unless you initialized the button earlier. The text is always empty by default and there is nothing to disconnect (other than perhaps internal things when a relative position or size is set) when it is just set up.
The disable call could help if you are planning on having signals connected which you don't want to activate yet, but when there is no hover or down image or signals, an enabled button will do exactly the same. Although calling disable would tell the button to ignore mouse events which could lead to a very small performance improvement with many buttons so that call still makes some sense.

I am thinking for right now to create a customer button widget where the hover, normal and down images/rgb are all the same. Also I won't connect any signal function to it....that essentially will just leave an unclickable button.

Then it isn't really a button anymore . Unless you intend to add the other textures later then you can just as well create a Picture.
If you don't set the hove or down images they will automatically fall back to the normal image btw.

The problems start because you draw tgui with a single gui.draw() call: this means that you can only draw sfml stuff behind everything or before everything. So the only way to have sfml inside a child window and thus between tgui draw calls is to render it upfront to an off-screen texture.

It is that off-screen texture (which is created through sf::RenderTexture) where things go wrong in some graphics card drivers. So it doesn't matter whether I let you draw to a Canvas or whether I create the RenderTexture directly in the child windows, the same problem remains.

As why I chose to use a Canvas: it allows sfml rendering anywhere inbetween tgui rendering, not only at the back of a panel or child window.

In TGUI the Tab class only defines the tabs itself on which you click, not different views that you might show when you click on them. So although it is not possible for the tabs to contain buttons, I don't think that is what you want. If I understood correctly you want to show a set of buttons when the "Attack" tab is selected while showing different widgets when one of the other tabs is selected?

The following example code might help:

Code (cpp) Select Expand

#include <TGUI/TGUI.hpp>

void onTabSelected(tgui::Gui& gui, std::string selectedTab)
{
    // Show the correct panel
    if (selectedTab == "First")
    {
        gui.get("FirstPanel")->show();
        gui.get("SecondPanel")->hide();
    }
    else if (selectedTab == "Second")
    {
        gui.get("FirstPanel")->hide();
        gui.get("SecondPanel")->show();
    }
}

int main()
{
    sf::RenderWindow window(sf::VideoMode(800, 600), "TGUI Tabs Example");
    tgui::Gui gui{window};

    // The panels will have a different background
    tgui::Picture::Ptr background1 = std::make_shared<tgui::Picture>("xubuntu_bg_aluminium.jpg");
    tgui::Picture::Ptr background2 = std::make_shared<tgui::Picture>("Linux.jpg");

    tgui::Tab::Ptr tabs = std::make_shared<tgui::Tab>();
    tabs->add("First");
    tabs->add("Second");
    tabs->setPosition(20, 20);
    gui.add(tabs);

    // Create the first panel
    tgui::Panel::Ptr panel1 = std::make_shared<tgui::Panel>();
    panel1->setSize(400, 300);
    panel1->setPosition(tabs->getPosition().x, tabs->getPosition().y + tabs->getTabHeight());
    gui.add(panel1, "FirstPanel");

    // Create the second panel (by copying of first one)
    tgui::Panel::Ptr panel2 = tgui::Panel::copy(panel1);
    gui.add(panel2, "SecondPanel");

    // Add the widgets to the panels
    panel1->add(background1);
    panel2->add(background2);

    // Enable callback when another tab is selected (pass reference to the gui as first parameter)
    tabs->connect("TabSelected", onTabSelected, std::ref(gui));

    // Select the first tab and only show the first panel
    tabs->select("First");
    panel1->show();
    panel2->hide();

    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();

            gui.handleEvent(event);
        }

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

In the above code 2 panels are created and a Tab widget which has two tabs. Depending on which tab is selected, one panel will be shown. This panel contains whatever you want to show when that tab is selected (in this case just an image, but in your case that would be the buttons).

The callback with onTabSelected is just an example of how it can be done. If the code is better designed then the callback function might be part of a class and might not need access to the gui. But you should check the tutorials about signals to fully understand how to call such functions. The "tabs->connect" call in the example will not even compile in Visual Studio unless you have the very recently released VS2015 Update 2.