Messages

Are you using the sfml libraries provided in the tgui download? Because the precompiled tgui libs will only work with that specific sfml version.

It is most likely because of an incompatibility, so make sure you are linking the correct libraries (in debug mode, both sfml and tgui need debug libs, in release they both need release libs, both have to be static or both dynamic).

In case you are sure everything is correct:
- Did you download v0.6.3 precompiled libraries, or did you compile yourself?
- Which compiler are u using?

Additional Library Directories: C:\SFML-2.1\lib; C:\TGUI-0.6.1\lib\TGUI; C:\TGUI-0.6.1\lib\SFML

I think you should try to remove "C:\SFML-2.1\lib" from that list. It probably first finds sfml 2.1 before the sfml version shipped with tgui.

C:\SFML-2.1\include

You should remove this  too. Although these files are probably still the same, you should take the ones that ship with tgui.

Like it says in the tutorial:

The screenshots are outdated. You only need one include directory "TGUI_Path/include". The library directories should be "TGUI_Path/lib/SFML" and "TGUI_Path/lib/TGUI".

On windows libraries simply aren't compatible between different versions, so you have to use the exact same sfml version in your project that I used to compile tgui. If you want to use a different version, then you should compile tgui yourself.

Once sfml 2.2 comes out, I won't have to ship a custom sfml version anymore. But since 2.1 has a bug in it that influences tgui, I am forced to do it this way.

Right after I made the change, I noticed a problem with the render texture. In order to use the system clipboard on windows, I need the window handle. Currently the system clipboard simply doesn't get used when you pass a RenderTarget instead of a RenderWindow. So I can't get rid of the setWindow function, unless I would add a new setWindowHandle function and force people to call it just to get the system clipboard working on windows.

I hope that sfml will at some point add a clipboard, so that I can remove that code and make the change you suggest.

It looks like a configuration mistake.

Did you download a precompiled libary? They also contain sfml libs which you must use with them.

Otherwise just make sure you are using the release libs in release mode and the debug libs in debug mode.

Don't you get a call stack pointing to where the unhandled exception occurred?

It might be because of an incompatibility, so make sure you are linking the correct libraries (in debug mode, both sfml and tgui need debug libs, in release they both need release libs, both have to be static or both dynamic).

Did you download v0.6.3 precompiled libraries, or did you compile yourself?
Which Visual Studio version do you have?

I really need a full code to test (minimized if possible), because the code you show seems perfectly fine. I just tested and the getText function works like it should.

The only thing that I can think of that could cause this behaviour is that you are copying the Gui instance somewhere. You would be using one to draw on the screen and handle events, while you are calling the get function on the different Gui instance.

Edit: Another thing is that you perhaps call upload_window twice and thus loadWidgetsFromFile is called twice? Try putting "gui.removeAllWidgets();" before the loadWidgetsFromFile call and see if that fixes it.

If it works for some edit boxes and not for that one then it can't really be a bug in tgui (at least not an obvious one like getText always returning an empty string). So I will need a minimal but complete example that reproduces the problem, since the lines you showed seem to be fine.

There is also "setPosition(float, float)", so technically that is the default and the sf::Vector2f is just the extra one . Even SFML still mixes these variants.
The one with the 2 floats has always been less limiting, you aren't forced to use a sf::Vector2f. But now with c++11 you could of course call the function like "setPosition({10, 10})" which makes the variant with floats unnecessary. So if I would redesign it then everything will indeed use sf::Vector2f. But this change will not be made in v0.6 because it breaks the api.

https://github.com/LaurentGomila/SFML/issues/5
You should just compile SFML with an extra flag, and then the crash with sf::String is fixed.
sf::String supports unicode while std::string doesn't, so I won't change it to std::string anyway.

There is another setGlobalFont function that takes a sf::Font as parameter.

I looked into it in more detail and it seems that I made a mistake in my previous post.
Your generalisation will work. I though the view was something from sf::Window, but apparently not.

I've made the change on github, so if you download and compile the latest code in the v0.6 branch then you will be able to render to a RenderTarget.

I'm afraid that it isn't possible.
That topic was about the fact that his render texure didn't display correctly anymore after using tgui, which was caused by badly linking the library. So you won't find much interesting in that topic.

Your generalisation will also not be possible due to the way the window is internally used (access to its view and the mapPixelToCoords function).

But depending on what you are trying to do, there are alternatives. If you only want to draw to a render texture in order to only use the gui on part of the screen, then you would be better of with setting a view for the gui.

So what is it that you are trying to accomplish exactly by rendering the gui to a render texture?

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.