Messages

The 'this' parameter has to be a pointer to the class instance (the value that 'this' would have when using 'this' inside the callback function itself). So you have to pass something else when the connect call is not being called from inside the PanelClient class.

Code (cpp) Select Expand

PanelClient client;
button->connect("pressed", &PanelClient::windowChooseKey, &client, "txtWindowShowKey" );

Edit: If that isn't the problem then could you show the build output? I just googled C2075 and it seems like it has nothing to do with this line itself. Are you using VS2015 update 2 or higher?

The code works fine when I change printf to cout like this:

Code (cpp) Select Expand

picture->connect("DoubleClicked", []() { std::cout << "Pressed" << std::endl; });

The std::endl flushes the output stream immediately while printf doesn't, so I guess it was working but you just weren't seeing the output (as it was still buffered).

Edit: Adding "\n" at the end of the printf string also works.

The 'this' parameter is always the first one of a member function, so the line should be

Code (cpp) Select Expand

button->connect("pressed", &PanelClient::windowChooseKey, this, "txtWindowShowHideKey");

You don't actually have to set the grid size. If you call grid->setSize then you let the gui calculate the offsets to fill the size, while you want to manually set offsets. The addWidget function takes 5 parameters in total, the 4th one being a border to place around the widget (I guess this should probably be renamed to "padding" instead of "border"). So the following will add a button with 2 pixels on each side:

Code (cpp) Select Expand

grid->addWidget(button, i, j, tgui::Padding(2));

You might want to choose the padding differently, because like this you get 4 pixels between each widget (since each has a 2 pixel padding around it). Also the Padding constructor takes more parameters if not all sides need to have the same border width.

No, but I wouldn't be surprised if 0.8 was slower than 0.7 in some parts. Performance has never been an important factor so I don't measure it when making changes.
The performance difference I talk about with labels was about some widgets being completely unusable. Like how adding 500 lines to a ListBox required creating 500 labels (and creating widgets is rather slow), making it completely unusable. Most of these cases (like ListBox) where already solved in 0.7 though, but in 0.8 I unified the code in a Text class instead of having duplicate code in all these places where I stopped using labels.

Just to clarify, lines in labels in 0.8 version keep center align accordingly to each line chars?

Yes, each line will be centered individually.

Labels already supports this, if they are given a size (via setSize) then you can use "label->setHorizontalAlignment(Label::HorizontalAlignment::Center)" to center the text. Widgets don't use labels internally anymore for performance reasons, the needed functionality was moved to a Text class (which Label also uses). But this text class if only meant to contain one line, the multi-line text and alignment are implemented directly in Label.

Buttons weren't supposed to have multiple lines of text on them.
At least it is already possible to create an empty button, put a label in front of it and call label->ignoreMouseEvents() to let clicks on the label reach the button.

This is the problem with developing on linux, it just runs no matter what happens . My pc happily continues running without issues even after invalid memory was accessed like in this code. Although I couldn't reproduce it here, I think I know what the issue was and it should be fixed in the latest version.

It should be fixed in the latest version now: https://github.com/texus/TGUI/archive/0.8-dev.zip

It's badly documented, but the ItemSelected trigger has 1 or 2 strings as optional parameters. So you can just add an sf::String (or std::string, with or without const&) parameter to the callback function then it will be called with the selected item. If items in the list box aren't unique then the extra string parameter will contain the id (optional second parameter passed to addItem).

Code (cpp) Select Expand


void f1() { std::cout << "Item selected" << std::endl; }
void f2(const sf::String& item) { std::cout << "Item selected: " << item.toAnsiString() << std::endl; }
void f3(std::string item, std::string id) { std::cout << "Item selected: " << item << " with id: " << id << std::endl; }
listBox->connect("ItemSelected", &f1);
listBox->connect("ItemSelected", &f2);
listBox->connect("ItemSelected", &f3);

I managed to reproduce it (the code can even be simplified further, the sfml window and main loop can be removed and it still occurs), but I haven't figured out yet what could be causing it. But it is definitely a problem inside TGUI.

1)
Yes, just create an empty project and add a new file to it (e.g. using File > New > Empty File in the menu bar).
Then go into the settings (Project > "Build Options..." in menu bar) and configure it to find SFML and TGUI as described in https://www.sfml-dev.org/tutorials/2.5/start-cb.php and the link I gave earlier.

2)
The link is for either. For TGUI the only difference is the "-s" behind the filename. For SFML (see link in previous part of this post) it makes a bigger difference, but that tutorial also explains what you must do. If you link statically (no dlls) then you must also add the SFML dependencies (list is in the tutorial) to the linker options. When linking dynamically (with dlls) you must copy the sfml and tgui dlls next to the executable in order to run it.

It might not be so easy to reproduce (it doesn't give any errors here and valgrind doesn't show anything useful). So I'm going to need to get a similar setup as yours:
What compiler are you using? Are you linking statically or dynamically? Release or debug mode?

Looks like something isn't being destroyed before the end of the main function. SFML textures (which are also used inside a font) can't exist in global scope. If a reference to the menu bar still exists at the end of the program then you could get issues like this.
If neither the font, gui or menu bar are static variables then you should try reducing the code to a simple example that still crashes.

But i can't build my project using tgui.

You should provide more details about what isn't working exactly. If the problem is with setting up codeblocks then have a look at the following tutorial: https://tgui.eu/tutorials/v0.7/codeblocks-precompiled/

In case you have problems with building the library:
SFML 2.5 was just released and comes with a precompiled library for TDM GCC 5.1 (which is the compiler that Code::Blocks 17.12 uses by default). There should be a corresponding precompiled TGUI library on my download page later today, but for now you can download it directly from this link: TGUI-0.7.7-mingw-5.1.0-tdm-32bit-for-SFML-2.5.0.zip

Loading from a stream is currently not directly supported.

I did however change the design in 0.8 a bit to potentially allow it. You can create your own ThemeLoader class (inheriting from BaseThemeLoader and based on what the DefaultThemeLoader does) and set it with Theme::setThemeLoader.
The theme file currently contain a filename of the font which is then passed to the Deserializer class. If you want to load it from a stream then you would have to overwrite the deserializer via "Deserializer::setFunction(ObjectConverter::Type::Font, func)". The string inside the theme file is passed as parameter to the func.
The same might work for textures, although Texture::setImageLoader might be needed as well.

So if you really want you could add support for it yourself. If someone adds support and shares the code then I'd gladly have a look if it can be merged into TGUI. But it is unlikely that I will write the code myself in the near future.

The code itself looks fine.
You should try to minimize the code and show a complete example code.

There is only one reason that I know that could cause weird crashes: using incompatible libraries and compiler versions (which is why I asked which versions you were using). If you didn't make a typo and are using GCC 6.3.0 then I suggest you try building TGUI yourself or switch to GCC 6.1.0 in the hope that it fixes the issue. Also make sure you aren't mixing debug and release libs.
Did you try with a different theme (e.g. BabyBlue.txt)?

Edit: if none of this works then I can't do much. You could give 0.8 a try though, it works in a different way and may work.

I can't immediately think of a reason why it wouldn't work.

tgui::Theme::create doesn't actually do anything, so even if the file doesn't exist it won't fail until the first load call. Did you try creating it with an absolute path?
Did you try to catch a tgui::Exception? Did you also try with a "catch (...)" block?
What compiler are you using? Did you download the precompiled libraries for SFML and TGUI for that compiler or did you build them yourself?

Even the FullExample.cpp won't compile.

Won't compile? If it really doesn't compile then you should show the compile errors.

This is a bug in my cmake script, the file no longer exists. The install command near the bottom of the CMakeLists.txt in the root dir should be removed. I'll do that tomorrow.

After SFML 2.5 is released, I'll release the new pre-alpha (which is basically Just the version you now already find on github). The alpha version should follow soon. Only then will I start looking at what to do in the beta version, so we are still far away from the final release.

Which branch are you using exactly, 0.7 or 0.8-dev (there isn't a master branch)?

With the recent changes to the SFML cmake script I had to adapt my own cmake scripts and it is possible some bug slipped in.

How did cmake find SFML before? Didn't you already have to set SFML_ROOT manually? If you are setting SFML_ROOT and it isn't finding SFML then it means something is broken with my new way of setting CMAKE_MODULE_PATH, you could try to manually set it to the TGUI/cmake/Modules folder and check if that solves the problem.
But for finding the latest SFML version it is recommended to just keep SFML_ROOT and CMAKE_MODULE_PATH empty and set the SFML_DIR to the SFML build directory (or the location where it was installed).

A setTabEnabled function was added in 0.8-dev (can be downloaded from github).

The first parameter is the index of the tab, the second parameter is whether or not the tab should be enabled.

Code (cpp) Select Expand

tabs->setTabEnabled(2, false);

The "wrong" mouse events are probably a "feature" in windows. I imagine that things like this could happen if part of the WS_OVERLAPPEDWINDOW number happens to be e.g. WS_EX_LAYOUTRTL.

That is likely a TGUI bug then. I misinterpreted your explanation as the left mouse button event being send when the right mouse button is clicked and vice versa.

That is indeed really weird.

if i use the above lines then when i hit the left button the signal goes to the right button and vice versa.

How did you test that the signal goes to the wrong place?
Did you try printing event.mouseButton.button inside your window.pollEvent loop when event.type == MouseButtonPressed?

You should try removing TGUI related code from the test project. If you still get the wrong events with just SFML then you know it is a problem with SFML and you should ask on the SFML forum. Otherwise I will have a look at this tomorrow (I can't test it right now, I'm not on windows).