Messages

That seems like a good way to implement it. This reminds me once again that I should look at existing libraries instead of just making random decisions.

I have added a getScrollbarWidth (and setScrollbarWidth) function now.
I couldn't decide earlier about whether I should go for a getScrollbarWidth function or for a method that simply disabled the horizontal scrollbar. I delayed the decision and apparently forgot about it afterwards. Currently ScrollablePanel implements a minimal API simply because I don't fully know how the widget will be used. So feel free to suggest other functionality that you feel is missing.

The clipping bug (that caused the text to be displayed outside the ScrollbablePanel) has now been fixed as well.
This weekend I will add the improvements to the ScrollablePanel class such that the order of the add calls will no longer matter.

Update: ScrollablePanel has been updated, the code from your first post now works.

Weird, I do get scrollbars with that code. Could you show a complete code, something that I can copy, paste and run so that I have the exact same code?
But the clipping is definately broken, seems like it only took 4 days for someone to find a bug in the new implementation.
The scrolling also seems a bit wrong, I either terribly messed something up in the new clipping code (which was just rewritten from scratch to work around and SFML issue) or there is some other issue in ScrollablePanel that I never noticed yet.
The widgets you are playing with are all relatively new or received quite some recent changes and are thus less tested, so you might hit a bit more issues with them than usual.

Writing something like that is probably not going to be easy, but maybe you can try with a VerticalLayout instead of a Grid. It requires you to manually specify the size, but you might be able to easily calculate it. The width would just be the size of the ScrollbablePanel (maybe minus the scrollbar width) while the height is the amount of items multiplied with the height of each row. You would have to change the height of the VerticalLayout every time you add or remove a row, but I think it might be the best solution.

There seem to be 2 unrelated issues. The first one was the bug I expected with Grid and has been fixed now.

The second "issue" is that ScrollbablePanel only checks the size and position of widgets when they are added to it. When "scrollPanel->add(grid);" is executed, the size of the Grid is still (0,0) since all the labels have size (0,0) since they don't have a font yet. When no font is set, the one from the parent is used. The widgets thus only get a size when "gui.add(scrollPanel);" is called but at that point the ScrollbablePanel no longer changes.

I'll soon look into how I will improve the ScrollbablePanel to automatically recalculate when one of its widgets is changed, but for now your code will work if you download the latest version again (to have the fix for the Grid) and swap the order of the "scrollPanel->add(grid);" and "gui.add(scrollPanel);" calls.

I don't have time to actually check it now, but I think the issue is with Grid. I think its size will be (0,0) when no size is given to it.
I'll have a look at this tonight as it looks like a bug that I must have introduced some weeks/months ago when I changed the way the size is handled in Grid. If the issue is as simple as I currently think it is then I should be able to have it fixed today once I get back from work.

Does it work when you use tgui::Theme::create("C:\Users\charles\TGUI\widgets\Black.txt") ?
Depending on how the executable is run, the file will be searched relative to the executable directory or the IDE project. The code you showed would only work when the executable is placed in "C:\Users\charles" and ran from there.

I don't know what was wrong, based on what I can find about the error it would usually occur when the exe is locked somehow (still running or some build process crashed while still having the file locked).

The Debug folder was created when I ran cMake, so I find it a little odd that it is there if it should not be

It's not CMake that is to blame here though, it's Visual Studio. With gcc I can just copy the build/lib folder next to the include folder but with VS I have to delete the Debug or Release folder inside it. The precompiled downloads don't have the subfolders.

The file should be directly in the lib folder, there should not be a Debug or Release folder inside the lib folder.

I don't know why you get the "cannot open file *\TGUI-test.exe" error though. Is that the only error you get? Are there no compile or linking errors?

I don't see any reason why it wouldn't find it, unless there is no tgui-d.lib in "C:\Users\charles\TGUI-0.8-dev\lib" or "C:\Users\charles\TGUI-0.8-dev\lib" does not exist.

Could you send the project file (vcxproj file)?

In case neither of us can figure out what's wrong, I think you could also just copy the lib file next to your project as a workaround.

Apparently the _fullpath function is only declared when passing -std=gnu++11 instead of -std=c++11 in your compiler. I have updated the 0.7 branch (https://github.com/texus/TGUI/tree/0.7), I will update the 0.8-dev code as well after checking that 0.7 still builds correctly on all compilers.

These undefined reference errors are just because the MinGW versions of the library and your compiler doesn't match, so that it not a bug in tgui. I though you meant you got compile errors.

So you have a compiler that neither has _fullpath nor realpath, I'm not sure what I can do about that. Could you send a link of where you downloaded the compiler exactly, so that I can have a look at the specific version you have?

I would expect the _fullpath function to exist in MinGW, otherwise I would have had errors when building for TDM-GCC 4.9 and MinGW-w64 6.1. If TDM-GCC 5.1 does not has the function then it will be difficult to determine whether I need to use the _fullpath or realpath function.
If all MinGW versions have an implementation for realpath then it might become easier. Could you check if it compiles when you replace the "#ifdef SFML_SYSTEM_WINDOWS" above the _fullpath call to "#ifded _MSC_VER"?

If you use the precompiled version then the MinGW version must match exactly with the prebuild one. But could you tell me which errors you were getting exactly?

The Visual Studio tutorial should be independent of the VS version. There are no VS2017 precompiled downloads because there are none for SFML yet. I have everything ready to build them, but I can't do so until SFML releases official VS2017 binaries in their download page. The VS2015 and VS2017 binaries should however be compatible, it should be possible to use VS2017 when downloading both the VS2015 binaries from SFML and TGUI, although I haven't tested that.

PictureRenderer has been added to 0.8-dev now.

Should not be very time-consuming

Things aren't always as simple as they seem. The Picture::setTexture function had an optional second parameter, setters in the renderer can't have a second parameter. So this had to be moved to the renderer as well but as a separate property. This property was a boolean however, no other renderer function takes a boolean. This means that a boolean type had to be added to ObjectConverter first. This messed up some implicit conversions so other functions had to be added, adapted and removed to deal with that. Every ObjectConverter type also has to be serializable so the Serializer and Deserializer code had to be adjusted too. WidgetLoader and WidgetSaver also needed a small tweak. Plus tests have to be written for all these different cases. It turned out that the behavior of when the Picture would change size when a texture is being set after another texture was already set isn't even compatible anymore with the fact that the texture is a renderer property, so that had to be fixed as well.

All in all it was only a couple of hours work and the extra things that I had to add were kinda planned anyway, but I just wanted to point out that I disagree about the "not be very time-consuming" statement

There is a third way to define the texture of picture: widget files. You can load widgets from a file (with gui.loadWidgetsFromFile) instead of having to hardcode them in c++. These widget files contain both the looks (theme) and the widget properties (including picture texture). Although I do admit that these widget files are still not extremely useful in the current state as all theme options have to be embedded inside the widget, the theme is not shared between widgets yet and you can't refer to an external file for the theme. Plus the gui builder is still missing so the only way to generate these files it so first create the widgets in c++ and then save them.

But I will add the PictureRenderer. I've always known that it was inconsistent, I just felt it would be easier to let it be a self-contained class as the original idea was to just encapsulate sf::Texture and sf::Sprite. The only reason why it inherited from the Widget class is to let the gui draw it with the rest of the widgets. When I introduced the renderers, the Picture class just remained unchanged as I didn't have a need for having it in the renderer.

It doesn't exist because I don't see a reason why they are necessary. I don't think mages belong in a theme file which defines how widgets look in general, not how every specific image on your screen looks.

The version 0.8 from the website works fine, but the latest github version is buggy

These versions are identical, the source code button is just a link to the github download. The VS2015 libs on the download page are however delayed 30 minutes (because they have to be build after the commit is made).

I did fix an issue yesterday where the layout did not work properly when the widget is added to a group, your code looks exactly like that issue. Maybe you downloaded the github version a bit before the fix? I would expect it to work if you try the github version again.

I figured out how to display the characters correctly. You can keep using std::fstream and std::string, but you have to explicitly inform SFML that the data you are giving it is not ANSI but UTF-8. This is done like this:

Code (cpp) Select Expand

textbox->addText("\n" + sf::String::fromUtf8(line.begin(), line.end()));

About the code you posted earlier, make sure gui.setFont occurs before gui.add. The widget will inherit the font of its parent (in this case the Gui) when it is added to it. Changing the font of the gui after the widgets have already been added to it will not change the font of these widgets. Only the font of widgets added after gui.setFont is called will get the new font.

[L]

The problem is not with the SFML rendering, it is with your loading. I didn't think of it until I was debugging the code, but the characters can't be stored in an std::string. If you do textbox->setText("à è ì ò ù") then it won't work, but it will display correctly when writing textbox->setText(L"à è ì ò ù").
I don't know exactly how to load wide chars from a file, but there seem to exist std::wfstream and std::wstring, so you should be able to figure it out by searching some more information about these types.

Edit: Actually std::string can store these characters, as std::cout prints them correctly. I guess the problem is with the way SFML converts the std::string to an sf::String then. But if you have an std::wstring then there shouldn't be any issues in the conversion to sf::String anymore.

TGUI just uses sf::Text internally, so if sf::Text doesn't display it then TGUI definitely won't.
But the Arial.ttf file you attached definitely does contain these characters, so I see no reason why it wouldn't work. Could you also try with the DejaVuSans.ttf file that can be found in the fonts folder inside the downloaded TGUI folder? If it still doesn't work then you can be certain that it is not an issue with the Arial.ttf file itself.
If even the DejaVuSans.ttf font doesn't work then you should show some minimal example code. Just a simple main function that creates the text and draws it to the window. Then I can be certain that you didn't make a mistake somewhere in setting the font.

I don't understand your code well enough to know what goes wrong exactly or how to solve it.
Accessing an object that is already deleted is undefined behavior, some things might work while others may not work. A crash is the most optimal scenario of things that can happen. Your code to create the buttons doesn't seem to access any members of the Settings class, only local variables and parameters, so no invalid memory is accessed. Maybe the code that creates the combo boxes does access something else. But a even if it doesn't, it is still wrong to access a reference to an object that no longer exists.

I don't know what you have in the Settings. If it doesn't need to store anything then its functions could be made static. Otherwise it could perhaps be a member variable of the MainMenu class instead of being a local variable in MainMenu::create, that way it will remain alive as long as the MainMenu exists. If it is a simple object that can be copied then the "&" in the lambda could also be replaced by a "=" to just copy it around.

Based on the way GuiFactory, Settings and Localization are created in those code snippets I would think static classes can be used there. But if the functions can be made static without any modification then of course there would be no reason for the crash you are experiencing.

Doesn't the debugger give some information about where the crash occurs? Getting a stacktrace when it crashes is extremely useful to figure out what goes wrong, otherwise I can only guess.

It is hard to say what goes wrong, but the following could be the issue:

Code (cpp) Select Expand

settingsbutton->connect("pressed", [&]() {
    settings.create(context);
});

You are passing the settings to the lambda by reference (because of the "&"), but settings is a local object. After the "menu.create(gui);" call, the settings object has been destroyed. When the button is pressed, you will be accessing an object that no longer exists.

y

t

x