Messages

Ideally you would just not include TGUI and windows.h in the same files. But you can just add this after including windows.h:

Code (cpp) Select Expand

#undef MessageBox

There isn't much that I could do to prevent this, this is exactly the reason why people should use namespaces and never put defines of common words in a header file.

Could you add some sfml rendering to it and see where it renders? Just load an sf::Texture and draw the corresponding sf::Sprite between gui.draw and window.display. Is it shifted as well? If it is also shifted, then try creating a simple example with only sfml and see if it still occurs.

TGUI currently does not support that.

You will have to do it manually in your code. When you receive an sf::Event::MouseWheelMoved then you should check whether the mouse is on top of the panel and not on top of the scrollbar. The mouse coordinates are in event.mouseWheel and you can get the areas of the panel and scrollbar using their getAbsolutePosition() and getSize() functions. When the mouse is located there, call scrollbar->mouseWheelMoved(event.mouseWheel.delta, 0, 0);

There is logo that someone created in this topic of which I have been using several variants. Feel free to pick any one or even edit it yourself:









Edit: The background was chosen based on my old forum theme and was never changed afterwards, there is no real reason to keep the grey background.

Even after you convince me that such a callback is a good idea, I may not be able to add it soon, so here is a workaround: (just copy findHoverItem in your code and use it like in the main function below)

Code (cpp) Select Expand

int findHoverItem(tgui::Gui& gui, tgui::ListBox::Ptr listBox, int x, int y)
{
    x = gui.getWindow()->mapPixelToCoords({x, y}, gui.getView()).x;
    y = gui.getWindow()->mapPixelToCoords({x, y}, gui.getView()).y;

    tgui::Padding padding = listBox->getRenderer()->getPadding();
    if ((x >= listBox->getAbsolutePosition().x + padding.left) && (x < listBox->getAbsolutePosition().x + listBox->getSize().x - padding.right)
     && (y >= listBox->getAbsolutePosition().y + padding.top) && (y < listBox->getAbsolutePosition().y + listBox->getSize().y - padding.bottom))
    {
        x = x - (listBox->getAbsolutePosition().x - listBox->getPosition().x);
        y = y - (listBox->getAbsolutePosition().y - listBox->getPosition().y) - padding.top;

        if (listBox->getScrollbar()->mouseOnWidget(x, y))
            return -1;
        else
        {
            if (listBox->getScrollbar()->getLowValue() < listBox->getScrollbar()->getMaximum())
            {
                // Check if the mouse is on the first (perhaps partially) visible item
                if (y - listBox->getPosition().y <= (listBox->getItemHeight() - (listBox->getScrollbar()->getValue() % listBox->getItemHeight())))
                {
                    return static_cast<int>(listBox->getScrollbar()->getValue() / listBox->getItemHeight());
                }
                else // The mouse is not on the first visible item
                {
                    // Calculate on what item the mouse is standing
                    if ((listBox->getScrollbar()->getValue() % listBox->getItemHeight()) == 0)
                        return static_cast<int>((y - listBox->getPosition().y) / listBox->getItemHeight() + (listBox->getScrollbar()->getValue() / listBox->getItemHeight()));
                    else
                        return static_cast<int>((((y - listBox->getPosition().y) - (listBox->getItemHeight() - (listBox->getScrollbar()->getValue() % listBox->getItemHeight())))
                                                 / listBox->getItemHeight()) + (listBox->getScrollbar()->getValue() / listBox->getItemHeight()) + 1);
                }
            }
            else // The scrollbar is not displayed
            {
                // Calculate on which item the mouse is standing
                int hoveringItem = static_cast<int>((y - listBox->getPosition().y) / listBox->getItemHeight());

                // Check if the mouse is behind the last item
                if (hoveringItem > static_cast<int>(listBox->getItems().size())-1)
                    return -1;
                else
                    return hoveringItem;
            }
        }
    }
    else // Mouse not on list box
        return -1;
}

Code (cpp) Select Expand


int main()
{
    int hoveringItem = -1;

    sf::RenderWindow window{{800, 600}, "TGUI"};
    tgui::Gui gui{window};

    tgui::ListBox::Ptr listBox = std::make_shared<tgui::ListBox>();
    listBox->addItem("Test 1");
    listBox->addItem("Test 2");
    listBox->addItem("Test 3");
    listBox->addItem("Test 4");
    gui.add(listBox);

    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
            else if (event.type == sf::Event::MouseMoved)
            {
                int newHoveringItem = findHoverItem(gui, listBox, event.mouseMove.x, event.mouseMove.y);

                if (hoveringItem != newHoveringItem)
                {
                    std::cout << "Play sound" << std::endl;
                }

                hoveringItem = newHoveringItem;
            }

            gui.handleEvent(event);
        }

        window.clear(sf::Color::White);
        gui.draw();
        window.display();
    }
}

There is currently no way of getting a callback when you are just hovering over a widget. MouseEntered is only when the mouse enters the ListBox and not per item.
I could add it, but don't you think that the sounds will come too fast after each other to play? I never added a signal for it because I didn't see a use case for it, but this use case sounds weird because I can't imagine that it would work well. Can you give an example of where they do this?

For 64-bit builds there is a "Visual Studio 14 2015 Win64" generator.
Using that one should fix the issue.

Based on the msdn website that error means that you are mixing 32-bit and 64-bit.

Are you certain that the sfml dlls are 64-bit?
What generator did you select in CMake?

Luckily it was easy to fix. But you will have to download the latest tgui version from github and build it yourself to get the fix.

Wow, you just discovered an issue in my signal code. I'll see if I can fix it easily somehow.

Could you show some code that I can test here? (ideally a simple main function that only creates the necessary objects to reproduce the issue)

The theme files only allow changing the look of the widget, not e.g. the text of a label. That is outside the scope of the Theme class.

If you really need to read a specific property from such a file then you can use the tgui::DataIO::parse class directly. You would have to read the file yourself, convert it to a stringstream, pass this to DataIO::parse and the returned value will be a tree of nodes containing all widgets and their properties.

But since you want to load the label text from a file I don't think reading a property from a style file is what you really need. There exist two kinds of files that can be loaded: theme files (which only contain the look and thus can't access properties in Label) and widget files (which save and load entire widgets to text files). These widget files can be loaded with gui.loadWidgetsFromFile and this is probably what you need. The file would contain the entire Label, both its look and other properties like its text. Since there are still no tutorials for this or any documentation for which properties the file can contain, you should just create a Label in c++, call gui.saveWidgetsToFile and then edit that output to what you want to load.

It is a good idea, but I'll look into the exact implementation when the time comes (e.g. maybe go for one parameter so that you don't have to write "Middle" twice and have e.g. "TopLeft" for others).
But one thing that bothers me a bit is that it will probably never be used. I can come up with use cases for having the origin as the center of the widget, but I don't think the other options would be used. I might just as well just have a function that takes a boolean which determines whether it is top left of centered.

TGUI currently does not support scaling and rotating widgets, so there is little reason for setting an origin.

Instead of the following

Code (cpp) Select Expand

setOrigin(widget->getSize() / 2.f);
setPosition(x, y);

you will just have to do set the position like this:

Code (cpp) Select Expand

setPosition(x - widget->getSize().x / 2.f, y - widget->getSize().y / 2.f);

I will consider a setOrigin function for v0.8 where I plan to add scaling, but don't expect it to be added in v0.7.

There wasn't really an easy way, so I added borders to the Panel widget in the tgui version on github.

From now on if any widget would need borders I can just tell people to put it inside a Panel.

TGUI isn't thread-safe (and neither is sfml), so accessing a widget from 2 threads at the same time is undefined behavior.

I suggest that you find some concurrent queue class (or use the queue from the std library but with locking yourself) and inside your thread you add the strings to the queue while in the main thread you read from that queue and you add the strings to the chatbox. That way only the main thread uses TGUI and nothing can go wrong.

it identifies them from gui.add(editBoxUsername, "Username"); this right?

Yep

does the RichTextLabel support vertical scrollbar?

No, it is just a wrapper around some class that was written for sfml. The RichTextLabel would have to be completely rewritten to be really useful.

It would be really cool to use that as a chat box or similar

You could also check out the ChatBox class for that . That class does have a scrollbar.

Just to give you yet another option: you can use gui.get to retrieve these edit boxes so that you don't have to store them anywhere in your code. The login function only needs access to gui and then you can do this:

Code (cpp) Select Expand

_window.setTitle(_gui.get<tgui::EditBox>("Username")->getText() + " : " + _gui.get<tgui::EditBox>("Password")->getText());

In this case the login function was part of the class that contains the gui so you could access it directly, but in case it would be a free function or part of a different class you can solve it by passing the gui as reference parameter:

Code (cpp) Select Expand

void ConnectionScreen::login(tgui::Gui& gui);
button->connect("pressed", &ConnectionScreen::login, &screen, std::ref(gui));

But in this case just passing the edit boxes directly is probably the most convenient way.

That didn't seem to work for me... compiler error.

Wasn't that compiler error just because you were missing a parameter to the connect function? Or are you talking about a different compile error?

Now if I could just find a way to pass the current text.

What about just passing the edit boxes themselves as parameter like the original example code did?

how will I set the theme (after), is that a problem?

I'm not sure what you mean with "after", depending on what you mean there might be problems though. In the code that I am developing for v0.8 there will be an easy way to reload the theme of the widget after its creation but I don't think there is an easy way in the v0.7 renderer system without manually copying the renderer properties.
If you put "tgui::EditBox::Ptr editBoxUsername;" in the class and then in the constructor (or anywhere before you use the edit box) call "editBoxUsername = theme->load(...)" then there will be no problems. But you can't first connect it and then run theme->load afterward because then you replace the edit box (and it would be a nullptr when calling connect as well).

I went back to trying    button->connect("pressed", &ConnectionScreen::login, this, editBoxUsername->getText(), editBoxPassword->getText()); and it actually works fine!

I was apparently a little bit too quickly to say that it was invalid code. You are right, it is perfectly valid code, it just doesn't do what you might expect.
If you pass "editBoxUsername->getText()" then the compiler will call that getText fuction (before calling your connect function) and store this string. When the callback function is called then the parameters are always the value of the edit box at the moment you called the connect function instead of containing the value of the edit box at the moment the callback itself occurs. The std::bind variant will not call the function immediately but really pass the function pointer itself. In this case when the callback occurs the getText function is called and its return value is passed as parameter to the callback function. So the parameters are only up-to-date when the function is bound (or when passing a reference but that is not possible since you want to use a return value of a function).

I have an unrelated problem. I'm not getting keyboard input in the EditBoxes.

That is indeed strange. Could you show the full code so that I can just copy-paste and try it here?

It seems to work here (I didn't test it when I wrote it but I tested it now).

Maybe the compiler doesn't like the parameter conversion (editBox->getText() returns sf::String and your parameters are std::string), you could try making the parameters sf::String. Another thing that might be an issue is that the edit boxes are smart pointers instead of normal pointers, so you could also try writing "editBoxUsername.get()" instead of "editBoxUsername" (and the same for editBoxPassword). But if that doesn't work then I don't know why it doesn't work, it could of course just be something that isn't supported in VS2013.

It took me a while to figure it out but I think I know what is going wrong (the compile error isn't very helpful).

You are not passing enough parameters to the connect function. Since the function is a class member, there is a hidden "this" parameter that has to be provided. Check the "connecting member functions" part of the signal tutorial.
Your code should have been like this:

Code (cpp) Select Expand

ConnectionScreen screen;
button->connect("pressed", &ConnectionScreen::login, &screen, "test", "test");

The correct form for the one with the getText calls would be the following (manual std::bind is required as there have to be 2 bind calls of which tgui only performs one).

Code (cpp) Select Expand

button->connect("pressed", &ConnectionScreen::login, &screen, std::bind(&tgui::EditBox::getText, editBoxUsername), std::bind(&tgui::EditBox::getText, editBoxPassword));

But the original code should have worked if you would have pass the hidden "this" pointer to the connect function as well. There isn't anything that I can do it TGUI to make it easier, it is a c++ detail that you have to know when passing function pointers.

I wrongly assumed that this was the same issue as the one reported last week as they looked similar on first sight (both about the online examples with VS2013), but this is apparently a different issue.

I just checked and realized that the scalable login screen example doesn't use unbound parameters.

From your last post the second connect call is not valid c++ but lets focus on the first call for now because it should work (just like the original code). The error you showed is normal for when the parameters are gone, but if I understood you correctly you also get "C2064: term does not evaluate to a function taking 2 arguments" when passing these "test" strings? Could you show the full compiler output?

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.