Messages

Apparently my code doesn't compile in visual studio. I can't test nor fix it from my linux, so I will boot my windows later to look at this (and then I can immediately fix those conversion warnings as well).

For now you can change line 412 in TextBox.hpp from

Code Select Expand

std::vector<sf::String> m_lines = {""};
to

Code Select Expand

std::vector<sf::String> m_lines;

Obviously that may break the TextBox, but at least then you can continue with the rest of tgui.
Or you can wait a few hours until I have fixed this issue and then get the latest version again (I'll post here when it's done).

The second option will most likely be a little less work.
I'm also thinking about delaying the rewrite of the widget creation to v0.8 so that the current v0.7-dev code does not need a complete change later.

But note that v0.7-dev is still lacking a few features that were in v0.6, mainly loading widgets from a file.

It should be fixed now.

Apparently I was already storing the view and its viewport, I just didn't set it when drawing.

If you want to get it to work quickly, you should make the following change in the tgui code: https://github.com/texus/TGUI/commit/350a3b2fe6cfd71dc57230f2588e8ff021a28f9d

I reverted the change right after I pushed it because I realized that this will only work when the sfml and tgui views are identical. But if this is the case then you can make the change in your local tgui code while I try to find a better solution.

Thanks. You will have to wait another year though for a final v0.7 release.

The Texture class is where it is all implemented, but is for internal usage.

Every texture in a theme file has two optional parameters "Part" and "Middle". The part parameter specifies which part of the image to load, while the middle parameter specifies how that part is scaled and if 9-slice scaling is used.

Suppose the image is 200x50 (or at least the part that you load has that size), and middle is given as (10, 20, 180, 15). The rectangle is given as (left, top, width, height) so the result is:
- The left slice would have a width of 10 pixels.
- The top slice is 20 pixels heigh
- The right slice is 200-180-10 = 10 pixels width
- The bottom slice is 50-15-20 = 15 pixels height

9-slice scaling is nice, but most widgets don't use it. There are 2 others ways of scaling. One of them is simply "stretching" everything which is done by not providing a middle rect.
But the other one is HorizontalScaling (which I called split image in 0.6 since this was the only way).

The Button class in Black.conf uses HorizontalScaling for instance.

Code Select Expand

NormalImage = "Black.png" Part( 0, 64, 45, 50) Middle(10, 0, 25, 50)

The line for 9-slice scaling or HorizontalScaling (or even VerticalScaling) is exactly the same. The middle parameter will just detect the one that we want. Here the top and bottom slice are 0 pixels height, thus 9-slice scaling wouldn't be a good option. The image is only split in 3 parts, so the scaling will be done that way. The ratio of the left and right parts will remain the same and only the middle part will be "stretched" horizontally.

There is a reason why I have been writing "stretched" between quotes. In v0.7 you can choose whether you want these parts to be stretched or if the image should be repeated. This can be chosen by adding the word Stretch or Repeat behind the line in the theme file.

There is also a fallback mechanism so that if you try to use 9-slice scaling and the image you draw is too small to use 9-slice scaling then horizontal or normal scaling will be aplied instead to always keep the image on the size that your requested.

That was basically image scaling in v0.7 in a nutshell .

Its on the todo list for v0.7, but I haven't started with it yet.

But seeing how much work I'm going to get with my university projects, it will probably be for July next year. Most v0.7 progress will be delayed till next year since I simply don't have the time for it.

It depends.

There is still going to change a lot in v0.7. Any code you write with it might have to be rewritten in a few months if you decide to update the a newer v0.7-dev version.

So I wouldn't really recommend it for bigger projects, but if it is a small project that doesn't take many months to develop then it is ok.
At least there should be some need for one of its features. If it is just a program with a few buttons then there is no need to use v0.7-dev.

I am going to need a bit more information.

Could you send a minimal code to reproduce the problem? Or does it also look like that when you copy the example code?
Which TGUI version are u using?
Which compiler are u using?

It should be fixed now.

My post was still about the original issue, you should try that code on the place where the get function was crashing.

Is that what you thought I should get before?

Yeah. I forgot that I was still using my own smart pointer in v0.6. That assertion is indeed what you get with v0.6.

I can't debug it from here, that's why I need to have more information somehow.
Just try using this code:

Code Select Expand

std::cout << gui.get("WrongName").get() << std::endl; // the last get() may or may not be needed to print the pointer

If that prints something that looks like a null pointer, then I can't do anything and it works as expected.
If that crashes, then could you upload your entire project including sfml and tgui libraries somewhere (e.g. dropbox) and send me the link? Then I may be able to test things myself here.

this produces no callstack

If you crash in debug mode then the debugger should break somewhere and you should have a call stack. It might just not be a visible window by default. You should look up where the callstack is for your ide.

Error codes don't really say much, but if you print out the return value of the get call then I'm sure its going to be a nullptr. The code inside the get function itself can't really crash unless by a serious error on my side, but then everyone would have problems with it.

Your description is a bit vague. I don't see anything about the Tab class that should be crashing, so I assume you are talking about the get function from Gui in the tab example code?

The get function returns a pointer to the widget, or nullptr when the widget isn't found. If you try to call a function on a nullptr it will crash of course. The only thing I can do about that is throw an exception instead of returning a nullptr, but that might not always be wanted.

You should always be able to find a call stack somewhere when debugging. That usually gives enough information about where it happened. The last line might perhaps be in a tgui function with this=0x0 which can tell you that you called that function on a nullptr.

But if you weren't talking about the get function then you will have to be a bit more specific than "The function".

SFML_USE_STATIC_STD_LIBS and TGUI_USE_STATIC_STD_LIBS are only required to link statically to the system libraries as well, they are not required (and by default not used) for static linking. You can perfectly use sfml and tgui statically while not checking this option in cmake.

Anyway, first priority should probably be to get something working no matter how it is linked. Then you can still mess around and try to get static linking working if you want it.

Call from 0x7bc4c2c0 to unimplemented function sfml-graphics-2.dll._ZN2sf5ImageD1Ev, aborting

I have seen a similar error on linux before not so long ago, so this time I do know what is wrong.
The latest sfml version has a destructor in the Image class, while sfml 2.1 did not have this yet.
So it looks like your dll is still from sfml 2.1 while you (or the tgui libs) linked to a newer sfml version.

Edit: Did you compile tgui yourself?

Using TGUI_USE_STATIC_STD_LIBS has never really been tested, but I don't see a reason why it shouldn't work.

It is however a setting that has to be given when compiling the tgui libraries, not when compiling your own application. The precompiled libraries are compiled without this option, so if you want to use it then you must compile tgui yourself with CMake and enable the option there. Make sure that the sfml libraries that tgui finds during compilation are the same as you use in your project and where compiled with SFML_USE_STATIC_STD_LIBS.

Edit: You didn't use the precompiled libraries did you? Your compiler is incompatible with them anyway.

The Tooltip widget has been added to v0.7-dev.

When using the built-in white theme, you only need to set the text.

Code Select Expand

button->getTooltip()->setText("Hello world");

Otherwise you must load the theme file first.

Code Select Expand

button->setTooltip(tgui::Tooltip::create("Black.conf"));

Edit:
But the downside of this news is that v0.7 is still far away from being released, so using v0.7-dev is not a great option unless it is just for testing, and I will not port the Tooltip widget to v0.6.

You can add the following to the Button section in Black.conf

Code Select Expand

FocusedImage_L    = "Black.png" (  0, 175,  50, 50)
FocusedImage_M    = "Black.png" ( 50, 175, 100, 50)
FocusedImage_R    = "Black.png" (150, 175,  50, 50)

You can use the tab key in the program to change the focused widget (in case you have more buttons) and you may want to call button->focus() to have it focused when the program starts.
Just know that changing the focus with the tab key doesn't tend to work very well when stuff like child windows or panels are involved.

The ReturnKeyPressed callback is only triggered when the button is focused while you press the return key. This was done so that buttons can be "pressed" by selecting them and using space or return key instead of only when clicking on them with the mouse.

But the Black theme provides no focus state for the button (the image contains it, but it is not loaded by Black.conf) so this part does not work with the default Black theme. The Black theme is meant to only be used with a mouse (same for White and BabyBlue themes).

The focusing part isn't really advanced enough to be decently used, thats why it is disabled by default.

No, not yet. I will add them on my todo list for v0.7.

I guess I will end up implementing it like this:

Code Select Expand

auto tooltip = tgui::ToolTip::create("Black.conf");
tooltip->setText("Hello world");
picture->setToolTipText(tooltip);

For normal widgets the last line would have been gui.add(widget), but since tooltips are not supposed to be in the gui but connected to a widget I will have to give every widget such a setToolTipText function.


I always delayed tool tips for a different reason as well. Having custom tool tips is one thing, but having them integrate nicely with the gui is another. With just a simple setText function it would seem impossible to make the tooltip display e.g. the item of the listbox below your mouse.
But I learned some really cool c++11 stuff yesterday. So if I would add a function that returns the item below the mouse then you could type:

Code Select Expand

tooltip->setText(std::bind(&tgui::ListBox::getHoveredItem, listBox));

So that solves the limitation that I always thought I would have.

The v0.7-dev branch is now public here: https://github.com/texus/TGUI/tree/v0.7-dev

The TextBox is fully rewritten there.

Picture is actually an exception. Unlike other widgets it is loaded with just a single image.
So I have quickly added this to v0.6 for Picture instead of delaying this to v0.7 where it will be possible for all widgets.

You can download the latest TGUI v0.6 version from github (will be released as v0.6.6 in 3 weeks). Then you will be able to write the following code:

Code Select Expand

sf::Texture texture;
texture.loadFromFile("ThinkLinux.jpg");

tgui::Picture::Ptr picture(gui);
picture->loadFromTexture(texture);


There is currently no way to load widgets from memory.

This will be changed in v0.7. Picture will definitely support taking a reference to an existing sf::Texture.
The entire loading mechanism should probably be changed for loading the other widgets from memory: https://github.com/texus/TGUI/issues/27

But this is not something to be expected soon.

I think I understand what went wrong.

The SFML version provided in the precompiled TGUI libraries is newer (and more stable) than SFML 2.1.
Some changes have however been made to sfml concerning linking statically, which were made AFTER the release of sfml 2.1. When linking statically to the newer sfml versions you have to also link its dependencies.
More info: https://github.com/LaurentGomila/SFML/wiki/FAQ#build-link-static

Glad that you like it and got it working.

I do want to see if I can reproduce these opengl errors though. What is your compiler and sfml version?

Since the crash occurs in sfml, this is most likely a library incompatibility.

So make sure you check everything mentioned here: https://forum.tgui.eu/index.php/topic,216.msg1092.html#msg1092