Messages

The order of the parameters is wrong.

Code Select Expand

double popupMenuCallback1(tgui::String item, double& speed)
should be

Code Select Expand

double popupMenuCallback1(double& speed, tgui::String item)
(because TGUI always passes your bound parameters first before the optional parameters such as the item)

If you want to change the speed variable inside your callback then you also have to use std::ref, to prevent the speed from being copied by TGUI:

Code Select Expand

popupMenu->onItemSelect(&popupMenuCallback1, std::ref(speed));

This behavior for the context menu is a completely different story. If TGUI would support context menus then it would be good if it automatically moved the menu, but TGUI currently doesn't even support context menus at all.

From TGUI's perspective, you are just creating a regular ListBox, and it won't automatically change positions for ordinary widgets like that.

So you would have to do this yourself by adding the following code at the end of rightClickCallback (after calling gui.add).

Code (cpp) Select Expand

if (popupMenu->getPosition().x + popupMenu->getSize().x > popupMenu->getParent()->getSize().x)
    popupMenu->setPosition(popupMenu->getParent()->getSize().x - popupMenu->getSize().x, popupMenu->getPosition().y);
if (popupMenu->getPosition().y + popupMenu->getSize().y > popupMenu->getParent()->getSize().y)
    popupMenu->setPosition(popupMenu->getPosition().x, popupMenu->getParent()->getSize().y - popupMenu->getSize().y);

Can you show how you create the tool tip? Because that behavior would be a bug.

For testing I just tried the following on a button near the right side of the window and it did work as intended:

Code Select Expand

button->setToolTip(tgui::Label::create("Testing with some long string"));

Just an idea moving position of tooltip up/left by difference between bounding box of last entry in relation to videomode.

I'm not sure what you mean. It should already be moving the tool tip if it would be outside the window. Isn't it behaving like that for you?

Depending on which CodeBlocks binary you install, it will use a bundled 8.1 from C:\Program Files\CodeBlocks\MinGW
You can change that in Settings > Compiler... from the menu bar and then writing a different path under the "Toolchain executables" tab.

If you set it to a directory containing MinGW 7.1 then everything should be compatible when you are using the SFML 2.5.1 downloaded from the SFML website.

Since the SFML code is unlikely to be broken, and neither TGUI or your project is making OpenGL calls that could interfere with SFML, this does sound like some library incompatibility.
So you will indeed either need to learn how to compile SFML and TGUI, or alternatively learn how to change the compiler in CodeBlocks and downgrade the GCC version.

tgui::GuiSFML was from TGUI 0.9, in TGUI 0.10 you can just use tgui::Gui.

Edit: Popup example seems to be the only one still using GuiSFML, I'll fix that line too. (The "GuiBase" has been updated on the website in the meantime, but the old version is still in some caches).

It looks like the 0.10 examples are a bit outdated, the class was renamed to BackendGui.
I'll fix it ASAP in all the examples.

Those errors look related to SFML. When you link SFML statically, you also have to link to its dependencies. The linking errors suggest that you aren't linking to the following SFML dependencies:

freetype
opengl32
winmm
gdi32

If you are linking to them, then maybe the order of linking is wrong. When you specify the libraries to link, do you have tgui at the end? Perhaps try putting tgui-s-d at the top of the list instead. When statically linking, libraries need to be ordered based on what they depend on (and for GCC the order is first TGUI, then SFML, then SFML's dependencies).


The MinGW compiler version usually has to match exactly between your project and what was used to build SFML and TGUI.
While the errors you showed don't look related to this, I don't think you can mix GCC 8.1 from CodeBlocks with the 7.3 that was used to compile TGUI without getting other issues (linker errors or crashes). If you use GCC 8.1 then you will most likely have to compile TGUI yourself. There is no precompiled TGUI library for GCC 8.1 because there is no stable SFML library for that compiler. So unless you are using an SFML snapshot instead of SFML 2.5.1, I would expect that you would have to compile SFML yourself as well (or switch your compiler to MinGW-w64 7.3.0 x86_64‑posix‑seh for which both SFML and TGUI provide libraries).
You can try keeping your current setup, maybe it will just work, but I won't be fully surprised if the program crashes on rendering once you resolved the linking errors.

You can find some information about custom signals at https://tgui.eu/tutorials/0.10/custom-widgets/#adding-signals

Your Task class would have a "tgui::Signal onStateChange = {"StateChanged"};" member and TaskStateChanged would call "tasks[index]->onStateChange.emit(this);".

Do you want to save the form file with modified values?
I think you want something like this: (code is untested, there might be typos)

Code (cpp) Select Expand

auto group = tgui::Group::create();
group->loadWidgetsFromFile("form.txt");
for (const tgui::Widget::Ptr& widget : group->getWidgets())
{
    auto button = widget->cast<tgui::Button>();
    if (button)  // If widget isn't a Button then 'button' will be nullptr
    {
        button->getRenderer()->setBackgroundColor(tgui::Color::Blue);
    }
}
group->saveWidgetsToFile("modified_form.txt");

TGUI unfortunately doesn't work like that, widgets can't automatically size based on their children. If there is only a single child then you can use the hack that I suggested for the child window, but if you want a parent to get the size of 5 buttons then you will have to calculate it manually.

HorizontalWrap also doesn't even come close to what you want to do. It has to be given a width, and when the widgets that are placed next to each other no longer fit inside this width, a new row will be added.
HorizontalLayout might be a better choice, but even then you still have to specify a fixed width, as HorizontalLayout will divide its width to its children (i.e. the buttons will get a size based on the layout size, not the other way around).

Are you setting a size for the HorizontalWrap?
By default the layout will fill the parent (i.e. the child window or panel), but you are setting the parent size to equal the HorizontalWrap.
You have to explicitly specify a size for either the panel or the layout.

Yes, that would work. I was originally going to mention that you had to do something like that to prevent an endless loop, but while writing the reply I realized that it wouldn't result in an endless loop.

The onScroll signal has been added to both TGUI 0.10 and 0.9 in the versions on github (https://github.com/texus/TGUI)

Can you show the full cmake output? For 0.10 I would expect there to be 2 warnings about not finding SFML (because it tries to find both SFML 3 and SFML 2).

There are 3 reasons that I can think of where cmake might find SFML but chooses not to accept it:
- There is a version mismatch. For example: TGUI 0.9 will fail to load the in-development SFML 3 version, it only accepts SFML 2
- Some dependency is missing. For example: somewhere in the output it might say that the SFML libraries were found but it couldn't find FreeType
- Incompatible libraries for the compiler. For example: building the project in 64-bit but finding 32-bit SFML libs, or mixing MinGW and Visual Studio libraries