Messages

0xc000012f seems to mean that the "Microsoft Visual C++ Redistributable" isn't installed, which is a bit weird in this case. To run any software that was build with Visual Studio, you need to have the redistributable installed for that Visual Studio version. It raises a question though: what code is built with Visual C++? You are building with MinGW, the precompiled SFML libraries were build with MinGW, and TGUI is being build together with your project and also with the MinGW compiler.

Is the bin directory of your MinGW compiler in your PATH environment variable?
Just to be safe, can you copy libgcc_s_seh-1.dll, libstdc++-6.dll and libwinpthread-1.dll from "C:\mingw64\bin\" and place them next to your exe?

Somewhere inside your "c:/Users/luka-/OneDrive/Desktop/AutoBackupScript2/build" folder. Probably inside the "TGUI/lib/Debug" subdirectory.

There is a way to let CMake automatically copy the dll when building. Try adding the following to your cmake script: (I didn't test this so it might not work as-is)

Code (cmake) Select Expand

add_custom_command(
    TARGET AutoBackupScript POST_BUILD
    COMMAND ${CMAKE_COMMAND} -E copy "$<TARGET_FILE:tgui>" "."
    VERBATIM)

Could I be overlooking something, such as copying .dll files or a similar requirement?

It's possible, but it's hard to say if you don't actually get an error message. Are the sfml and dll files placed next to the exe?

I don't really know VS Code. Do you have some process output somewhere? If the program crashes then it usually sets a return value other than 0. If you find some output with something similar to "program exited with code ..." then you can usually search online for that code to determine whether it ended due to a missing dll, an access violation or an uncaught exception.

There are 2 things you can test:
1) Run the exe from file explorer instead of from the IDE. If it won't run due to a missing dll, you will get an error when attempting to run the exe like that.
2) If something goes wrong in TGUI (e.g. a file can't be loaded), then it will throw an exception. If you don't catch this exception then the program terminates.

Do something like this in the main function to print something to the command line when an exception occurs, so that you can see what went wrong. I'm not sure if you will be able to see the text printed somewhere, but you might also be able to e.g. put a breakpoint in the catch code to test if it passes there. The "e.what()" value is a string that contains the TGUI error message.

Code (cpp) Select Expand

int main()
{
    try
    {
        // <Put your existing code here>
        return 0;
    }
    catch (const tgui::Exception& e)
    {
        std::cerr << "TGUI exception: " << e.what() << std::endl;
        return 1;
    }
}

is that something I should consider in general or is it more something for debugging?

It's only for debugging.
The higher the number, the faster the project will build (as the number indicates how many source files can be compiled simultaneously). At least as long as the number doesn't exceed the amount of CPU threads your processor has (a higher number will work but won't make it faster) and as long as you have sufficient RAM (which becomes important for very high values).
Setting it to 1 means that all operations are done sequentially and nothing is done in parallel. This makes building much slower, but then the logs will properly show you which step is being executed when the error happens.

I now have an issue with the example for the SFML backend, encountering an undefined reference to the bool runExample(tgui::BackendGui& gui) function.

The TGUI examples found in the "examples" folder are split into 2 parts. The first part contains just the main() function and shows how to initialize the window and gui (using backend-specific code, in this case using SFML Graphics). The second part is the "runExample" function that contains the code that is backend-independent and which is thus the same no matter whether you are using SFML, SDL or GLFW. The second part is found inside either the "scalable_login_screen" or "many_different_widgets" subfolder.

I'm guessing you only have a declaration like "bool runExample(tgui::BackendGui& gui);" in your current code. You can replace it with the following to have an example that compiles:

Code (cpp) Select Expand

bool runExample(tgui::BackendGui& gui)
{
    return true;
}
The website contains some more example codes: https://tgui.eu/examples/latest-stable/

The error isn't with the gui builder. If you set TGUI_BUILD_GUI_BUILDER to OFF then you would get the same error.

The library name passed to "target_link_libraries" should be either "TGUI::TGUI" (recommended) or "tgui" (deprecated), but "TGUI" is wrong.

The cmake command that is being executed has "-j 6" in it. Is this something you can change yourself? The log output would have been more clear if you ran it with "-j 1" (which you should only do when investigating an issue, as usually you do want to build with more threads). Now it builds your project and the gui builder at the same time so it prints both outputs interleaved and it isn't clear that the error is about your project and not the gui builder.

You can just create a new font object:

Code (cpp) Select Expand

tgui::Font font;
font = tgui::Font("font.ttf");
There is practically no performance cost in copying the Font object, as it is a lightweight object that will just share its internal resources between the different font objects.

Note that unlike Texture objects, creating multiple Font objects with the same filename will cause the file to be loaded multiple time. So to keep memory usage minimal, you should only call the tgui::Font("font.ttf") constructor once in your code and then just copy that font object to anywhere that you need it.

Now the log output looks more normal.
You need to move the set(SFML_DIR "c:/SFML/lib/cmake/SFML") line in your script to ABOVE the "add_subdirectory(TGUI)" line.

Also, your code should either contain "add_subdirectory(TGUI)" or "set(TGUI_DIR ...)\n find_package(TGUI 1 REQUIRED)", but not both of these.

I'm a bit confused about how the project is being build.

The log contained the following line:

[proc] Executing command: "C:\Program Files\CMake\bin\cmake.EXE" --no-warn-unused-cli -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_C_COMPILER:FILEPATH=C:\mingw64\bin\gcc.exe -DCMAKE_CXX_COMPILER:FILEPATH=C:\mingw64\bin\g++.exe -SC:/Users/luka-/OneDrive/Desktop/AutoBackupScript2/TGUI -Bc:/Users/luka-/OneDrive/Desktop/AutoBackupScript2/build -G "MinGW Makefiles"

The source directory is being set to the "TGUI" subdirectory, but the build directory is the one from your project? That would mean that it is trying to build TGUI and your own cmake script isn't even being executed.

If that command where to contain "-DSFML_DIR=c:/SFML/lib/cmake/SFML" then it would probably build TGUI successfully. However that would only build TGUI and not your project, so you probably want to change the source directory instead.

The set(SFML_DIR "c:/SFML/lib/cmake/SFML") should be sufficient when placed before the find_package or add_subdirectory line.

TGUI tries to find SFML with "find_package(SFML 2 CONFIG COMPONENTS graphics REQUIRED)".

- Which files does c:/SFML/lib/cmake/SFML contain?
- Which SFML version is located in c:/SFML?
- Did you build SFML yourself or download a precompiled version from their website?
- Which MinGW version are you using?

Is the Scene class perhaps being destructed after the main() function has finished executing?
SFML and TGUI objects need to be destroyed before the end of the main function and shouldn't be part of a static global object.

Edit: Also, all TGUI widgets need to be destroyed before the Gui object is destroyed.

Actually I think this issue was fixed already recently.
The "Texture::operator==" contained a bug where it considered two images with the same filename but a different part rect to be identical to each other.
So calling setTexture would do nothing because the code thought that you were just setting the same texture again.

I just uploaded TGUI 1.2.0 to the website (if it still shows 1.1 on the download page then refresh the page with ctrl+F5). If you use that version then this and the earlier reported bug should be fixed.

It's probably best to put it in a new topic.

Definitely a bug. Two bugs even.

This has now been fixed in the last TGUI 1.x-dev version.
Just in time for the TGUI 1.2 release that is coming later today.

You will need the touch events that you get directly from SFML in your main loop for this.

I could maybe add a new event, something like a PinchZoom event, which works similarly to mouse wheel scrolling (i.e. has one + or - parameter with a relative value since the last position). I'm however uncertain how to properly detect a pinch zoom, and I'm not sure what the value should even be. As soon as you put 2 fingers down, TGUI will currently already think that you are scrolling with two fingers (which is an assumption I could only make because no other gestures were supported). So adding the event (which I'd be willing to do), is the least amount of work. Getting both zooming and scrolling with two fingers to behave well would be a lot harder (and not something that I'm currently willing to do).