Messages

The ".." assumes that you are running cmake from a build folder, to avoid that a lot of cmake cache files are created inside the tgui folder.
I didn't care about this in the tutorial since it doesn't matter for the tgui users, but I'm used to using a build folder to avoid these cmake files showing up in git.

everything went perfectly

I hope it stays that way. Because that error indicates that a function is missing from libsfml-graphics.so. But if it wouldn't be linking to it at all then you would get tons of these undefined reference errors.

You could possibly check if the file really misses the function or not.
Running this in the terminal should give a small list of functions and _ZN2sf5ImageD1Ev and _ZN2sf5ImageD2Ev should be in that list (with a T in front of them).

Code Select Expand

nm /usr/local/lib/libsfml-graphics.so | grep sf5Image

I have never encountered this problem before.
I even just tried with the latest tgui version and with both the latest sfml and with sfml 2.1 and I don't get this error.

Anything you might have done special (running something else than "cmake .." or having a different sfml version)?
Can you draw something on the screen with just sfml?

The library seems to build fine, so if you run "cmake -DTGUI_BUILD_FORM_BUILDER=FALSE .." instead then it will work, you just won't have the form builder (but you can run the provided exe with wine instead of compiling the native one if really necessary). I just fear that you are going to run into similar problems when using tgui in your project.

Perhaps you could also try re-installing sfml, it looks like a very strange error.

Yes and no.

Actually any sfml 2.x version will do. You just have to make sure that the sfml version used to compile tgui is the same as the one used in your project.

But since there is a bug in sfml 2.1 that influences tgui, and sfml 2.0 is even less stable, you are actually adviced to use the github version of sfml.

This was a small bug in tgui.

If you download and compile the latest version then the button should no longer remain in hover state.

The bugs should be fixed in the latest version now: https://github.com/texus/TGUI.

You will have to recompile the form builder yourself though, I don't feel like booting up my windows to compile the distributed executable right now.

Thanks for reporting, I have been able to reproduce it so it will be fixed soon.

I'll try to keep the form builder working for v0.6, but I haven't even decided yet if future versions will still have a form builder. With all the changes in v0.7 I would have to completely rewrite it, which is not something that I'm looking forward to.

I can clearly see that the texture repeat is broken, but I tested the download from my site two days ago with your previous question and the login example ran fine on my pc.

So in order to be certain that its not a problem with your graphics driver, you should try testing a small sfml program.

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 that would display correctly then I have a serious problem, if it is broken too then it is only on your pc.

Edit: I just tested the FullExample with v0.6.4 and I cannot reproduce the problem. So there is nothing that I can fix, I can only tell how to get around this problem in case you can't solve it.

I would expect the same error then when you try to run your own code.

This error isn't necessarily a problem. If you are lucky it is just a caching problem, otherwise your linker isn't searching in the right folder. See if "sudo ldconfig" solves it.

You didn't change any line from the example code? There are no errors printed in the terminal?

The form builder is just a program that links agains the just build libraries, which means that the libraries have to be build correctly.

The first thing you can try is this:
- open the terminal in the folder TGUI_Path/examples/LoginScreen
- type "g++ LoginScreen.cpp -std=c++11 -ltgui -lsfml-graphics -lsfml-window -lsfml-system"
- run "./a.out"

Does it display a black screen too? If it doesn't, then something is wrong with your code (e.g. a wrong pathname for loading the widgets).

[Linux: error while loading shared libraries]

Linux: error while loading shared libraries

Don't post about the following error, just follow the steps below.
"/pathname/of/program: error while loading shared libraries: libtgui.so: cannot open shared object file: no such file or directory"

First try to run "sudo ldconfig", just to be sure that it isn't a caching problem.

Unfortunately a lot of linux distros install to /usr/local/lib by default, but do not have this folder in the linker seach path.
You could edit "/etc/ld.so.conf" and just add a line that contains "/usr/local/lib/" to it. Then run "sudo ldconfig".

[Windows: unhandled exception or access violoation]

Windows: unhandled exception or access violoation

If you are experiencing an unhandled exception or access violoation with tgui, then make sure you check these things before posting.

Windows is very unforgiving, the smallest mistake can lead to very strange behaviour.

Make sure you downloaded the right version
If you downloaded the precompiled library, then the compiler version has to match with your compiler (e.g. VS2012 libs are NOT compatible with VS2013). If there is no package for your exact compiler version, then you have to build tgui yourself.

Make sure that you are linking tgui correctly.
- If you are in release mode, both the tgui and sfml libraries have to be the release versions
- If you are in debug mode, both tgui and sfml libraries have to be the debug versions (-d suffix)
- Either both tgui and sfml have to be linked dynamically, or they both have to be linked statically (-s suffix)

The precompiled tgui libraries require a specific sfml version
If you download tgui libraries, then you cannot choose which sfml version to use. Which sfml version you need is mentioned on the download page. Make sure you use these sfml libraries and not another version. If you need a different sfml version for some reason, you will have to build tgui yourself.

Provide enough detail
If you checked all the obove things, then you can make a topic about it. But PLEASE make sure you checked these things, I don't like if they end up being the reason. If you don't want to have such a hard time installing a library, then you should use a decent OS.
Try to provide the following information so that I can help you more efficiently.
- What compiler version are you using?
- Did you download the precompiled libraries, or did you build from source?
- Are you linking statically, or dynamically?
- If needed/possible, provide a complete but minimal example that I can test.

[Seach before posting]

Seach before posting

Read this topic, have a look at the tutorials and documentations, seach on the forum and use a search engine.
The problem you have might have been solved in the past already. It will also save you time because you don't have to wait for the solution until I get online.

This topic will provide some general rules to follow when posting, and small guides on how to solve some common mistakes.

Please read through this topic before posting.

I still believe that there is something wrong with your setup then.

I can't immediately help, I don't get on windows often anymore, for now you can link dynamically.
If you can't find anything that you did wrong in setting up the static version, then you could perhaps upload your project including the sfml and tgui libraries somewhere (e.g. dropbox). I can then have a look at it, but not today. I do want this solved though, even though the chance is small, if the tgui libs would really be currupted then I need to fix it.

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?