Messages

Although that quote was about the C# code itself, it is indeed because I never took the effort to support it and nobody asked for it until now.

Is there a reason why you need to use 32-bit? I guess there are still too many people with old computers out there who are using it, but I would think almost anyone who would be interested in running new software would have a 64-bit pc.

Although there is no technical limitation for 32-bit, you will have to change a few files to get it working because I hardcoded the x64 value to keep things simple.
You will have to start by checking out the TGUI.Net project with git (i.e. "git clone https://github.com/texus/TGUI.Net").
Open extlibs/build.bat and change the 3 occurrences of "vcvars64.bat" to "vcvars32.bat". There are also 3 occurrences of "x64" in that file, leave the "...Tools.x86.x64" on top alone, but change the ones in the cmake and msbuild lines to "x86".
Go back to the root folder and open build/TGUI.Net.sln with a text editor. Replace all occurrences of "x64" with "x86".

That should be enough to get 32-bit working. If you update the submodules and run the build.bat file in the build directory as described in the readme then it should build 32-bit libraries (this will take several minutes). Let me know if it works or not. If it works then I'll try to come up with a way to let you choose 32 or 64 bit without having to change the scripts manually.

I can see the usefulness and it's easy to implement so... consider it done. Literally.
You can already download the version where you can set a text style in ChatBox from https://github.com/texus/TGUI but you will have to compile it yourself with cmake. It will be included in 0.8.2 which will be released in a month or so.

I have recreated the 0.8.1 precompiled libraries. They now have the correct folder structure.

The shipped TGUISharedTargets-debug (and the ones for release and static libs) have only recently been added (in 0.8.1), but it was never tested that they work when shipped with my precompiled libraries (since they can contain hardcoded paths). It seems that due to a misconfiguration in the build server they aren't even included in all downloads on the website.

The error is that the files try to get the dll files from a bin folder (which is how things normally get installed when running cmake), but I ship my dlls in a lib folder. So creating the bin folder yourself and copying the dll fildes from the lib folder there is the correct solution.

I'll make sure to place the files in the bin folder next time I create the downloadable libraries.

You can get the exact error by surrounding the code with a try-catch block:

Code (cpp) Select Expand

try {
    // contents from main() function
} catch (const tgui::Exception& e) {
    std::cerr << e.what() << "\n";
}

If the error is that it can't find the file then make sure the theme file is located in the same folder as your executable.

I can't reproduce this here, so it might be related to your graphics driver. Which SFML version are you using? Make sure try the latest SFML version (2.5.1) as the render texture code has had several changes in the last few versions.

To rule out the possibility that this is a bug in TGUI, what happens if you use the following code?

Code (cpp) Select Expand

// Create the RenderTexture and Sprite which the Canvas created for you
sf::RenderTexture rt;
sf::Sprite sprite;

// This code is executed only if gui.add is placed before setSize
rt.create(800, 600);
sprite.setTexture(rt.getTexture(), true);
rt.clear();
rt.display();

// This code is executed when calling setSize
rt.create(100, 100);
sprite.setTexture(rt.getTexture(), true);
rt.clear();
rt.display();

// This was your clear and display call
rt.clear({100,100,100});
rt.display();

You will also need to put the following in your draw loop for it to show up in the top left corner:

Code (cpp) Select Expand

window.draw(sprite);

If it doesn't show and removing the first part where rt.create is called does work, then it is clearly an error in SFML or your graphics driver. If the code does work however, then it may still be an issue in TGUI and then I'll try to investigate further.

I'm a year late, but the Canvas now works as suggested in the first post.
Experimental support for custom widgets has also been added. It's not possible to inherit from existing widgets, but a completely new widget (which could contain existing widgets as member variables) can be written in C# (the new Canvas class is an example of a widget written in C#).

The class is called "TextBox", not "Textbox" (capital B).

These errors aren't related to TGUI. If you link SFML statically, you must also link to its dependencies.

You also need to link to the following libraries:

Code Select Expand


opengl32.lib
freetype.lib
opengl32.lib
winmm.lib
gdi32.lib
winmm.lib

More information can be found in the SFML tutorial: https://www.sfml-dev.org/tutorials/2.5/start-vc.php

Based on the errors it looks like you aren't defining SFML_STATIC.

What is the exact error you get? What compiler and/or IDE are you using?

For future reference, the example has now been updated to use gradle.
It worked for me without changing AndroidManifest.xml, but I did have to change Android.mk to get it working.

Do other widgets work? If not then you forgot to call gui.handleEvent.
If other widgets do work then you should show some example code of what you are doing.

The AndroidManifest.xml change looks weird to me. When the program starts, it loads what is in "android.app.lib_name", which is "sfml-activity-d". When sfml-activity is finished, it loads what is in "sfml.app.lib_name". This should be the tgui-activity, otherwise my activity would never be loaded. When my activity finishes it jumps to "tgui.app.lib_name", which would cause an infinite loop according to that manifest. The only purpose of tgui-activity is to load the tgui library, so I have no idea how TGUI could work like that.

I did notice that your Android.mk file also contains "LOCAL_SHARED_LIBRARIES += sfml-activity-d". Looking at the SFML example, it seems like this was added when they changed to gradle. Maybe loading the SFML or TGUI activity there affects what has to be placed in the manifest?

I'm not sure why you had to change to gradle, I tested the example with NDK 17b, I would be surprised if they removed stuff in 17c. If it is deprecated then it should still be possible to use it. What exactly is the error when running "android update project --name TGUI --path . --target android-23"?
If you just run "android" without any parameters, the SDK manager should open. Is the "SDK Platform" installed for "Android 6.0 (API 23)"?

I'll have a look at updating to gradle though, I have to do it at some point. Building SFML for android is left in a bit of a WIP state and I was hoping that they would fix these issues first, but I can't keep waiting forever. I don't know much about gradle either (other than the things I pieced together when I updated the android tutorial on the SFML wiki) so I was also just going to copy it from SFML. But I want to have the issue with AndroidManifest.xml sorted out before I publish the new example, I need to at least understand how and where my library gets loaded.

It has to use the android libraries. Based on the output it is using the windows libraries of SFML which is why it isn't working.
The original problem already occurs when running cmake where it prints "Found SFML 2.5.0 in C:/SFML/lib/cmake/SFML". The path that gets printed should be inside the NDK directory.

I never actually tried compiling for android on windows (only on linux), but my cmake script should try to find SFML in "${CMAKE_ANDROID_NDK}/sources/third_party/sfml/lib/${CMAKE_ANDROID_ARCH_ABI}/cmake/SFML". If you copy the exact path "/ndk/sources/third_party/sfml/lib/armeabi-v7a/cmake/SFML" in explorer, does it open the folder containing *.cmake files?

You can manually specify the SFML version by adding the following to your cmake command:

Code Select Expand

-DSFML_DIR=/ndk/sources/third_party/sfml/lib/armeabi-v7a/cmake/SFML

But I do like to find out why it isn't automatically finding that SFML version. If the folder is correct and specifying SFML_DIR fixes the problem then it means I will have to find a way to improve my cmake script.

A lot has changed since that answer.
To keep all widgets consistent, there is now a global text size that widgets use by default, instead of each widget having a slightly different text size. All widgets now do have a setTextSize function to use something other than the global value.

How are you scaling the list box? At some point you would be calling setItemHeight, I think you could just call setTextSize there as well with a value that is 0.8 times what you passed to setItemHeight.
Alternatively you can still make the text scale automatically in ListBox by calling listBox->setTextSize(0), which will result in the old behavior of the text being scaled automatically. But personally I would just call setTextSize each time you call setItemHeight, then you can choose the factor "0.8" yourself based on what text size you want and not rely on the exact number that TGUI used internally.

I've created the missing cmake files, they are attached to this post.dr

The cmake folder contained in the zip file has to be placed inside "TGUI/lib" and then you should be able to use the cmake script from my first post without needing the "build" folder. I haven't been able to actually test the attached files myself, so let me know if you get any other errors.

Are you sure your libraries are compatible for your compiler? What is the exact compiler you are using? Which libraries did you download?

Copying the libraries you had to build/lib should have worked. Did you also copy the tgui dll next to your exe?

You could try to build the libraries yourself instead of copying the existing libraries, that would guarantee that they are compatible with your compiler. Check that the compiler which cmake finds is the one you are using (can be seen in the cmake gui at CMAKE_CXX_COMPILER after checking the Advanced checkbox). After you pressed configure and generate, cmake would have created a makefile. (The tutorial I linked showed choosing "CodeBlocks - MinGW makefiles" which aren't the ones you need, so if you chose that in the beginning then you may need to delete the build folder and try again, this time selecting just "MinGW Makefiles"). You can run this makefile from the command line by running "mingw32-make" while in the build folder. When it finished it should have created libraries in the build/lib folder.

It appears that the downloads on my website don't contain these files, my build system doesn't copy them. I actually have 2 to 4 variants for each compiler, so I will have to figure out if they are the same and whether I can just copy them or not. I won't be able to provide these files immediately. This issue probably went unnoticed because others aren't using cmake in their own project.

So you will have to build TGUI yourself. Create a "build" folder inside the root TGUI directory. If using the command line, from inside the build folder just run

Code Select Expand

cmake -DSFML_DIR="D:/Andrew/Resources/SFML/lib/cmake/SFML" ..
(you can add "-DCMAKE_BUILD_TYPE=Debug" for debug libraries or "-DTGUI_SHARED_LIBS=FALSE" for static libraries)

If using the cmake gui, just follow the cmake section of the https://tgui.eu/tutorials/0.8/codeblocks/ tutorial. Basically you just enter the root TGUI directory, the build folder and then when it asks you fill in SFML_DIR. You might also want to select whether you want Release or Debug libraries (if you want both then you need to create 2 build directories and do everything two times) and whether you want shared libraries (with dlls) or static libraries. The other things can be ignored.

When building yourself, the FindTGUI.cmake file will be created in the build folder (you can't copy the file, you must keep it there). So in your own project, TGUI_DIR would then have to become "D:/Andrew/Resources/TGUI/build".

Can you also show what is inside the "lib" folder? Doesn't the "lib" folder also contain a "cmake" folder?

TGUI 0.8 no longer uses TGUI_ROOT, CMAKE_MODULE_PATH or FindTGUI.cmake (and if you are using SFML 2.5 then SFML isn't using such stuff either).

If find_package can't find TGUI by itself (which is normal on windows since it doesn't have default locations to put libraries) then you must set the TGUI_DIR directory to "D:/Andrew/Resources/TGUI/lib/cmake/TGUI" (the folder containing TGUIConfig.cmake).

After find_package you just need "target_link_libraries(testSFML PRIVATE tgui sfml-graphics)" (you only need sfml-window and sfml-system if you are still using the old way of finding SFML). Calling include_directories is also no longer needed with the new method.

Since you are using REQUIRED, you can also drop the checks for SFML_FOUND and TGUI_FOUND, since cmake won't go past the find_package call until they are found.

So a cmake file for SFML 2.5 and  TGUI would look like this:

Code (cmake) Select Expand

cmake_minimum_required(VERSION 3.12)
project(testSFML)

set(CMAKE_CXX_STANDARD 14)

add_executable(testSFML main.cpp)

set(SFML_DIR "D:/Andrew/Resources/SFML/lib/cmake/SFML")
set(TGUI_DIR "D:/Andrew/Resources/TGUI/lib/cmake/TGUI")

find_package(SFML REQUIRED COMPONENTS system window graphics network audio)
find_package(TGUI REQUIRED)

target_link_libraries(testSFML PRIVATE tgui sfml-graphics)

Note that SFML_DIR and TGUI_DIR shouldn't actually be set in your cmake file, it makes your cmake file only work for you. They are supposed to be set in the cmake gui or passed to cmake on the command line. But if it is just a personal project that you only run on one computer then you can just keep the _DIR entries there for simplicity.

Indeed, setToolTip will automatically be called when loading the button from that text file.
So you just need to do the cast to tgui::Label if you want to change its text after loading it.

The tooltip can be anything, not just a label. You have to create the label yourself and pass it to setToolTip.
See https://tgui.eu/tutorials/v0.7/tool-tips/ (it's a tutorial for 0.7 but I don't think I made any changes to this in 0.8, I'll copy the tutorial to the 0.8 tutorial page on my website later today).

If you must change the text later (i.e. if the text is variable) then you first have to cast the widget to the right type:

Code (cpp) Select Expand

button->getToolTip()->cast<tgui::Label>()->setText("Hello world");

But doing that before calling setToolTip will result in a crash as getToolTip would return a nullptr.

It depends a bit on what information you need exactly in the callback handler. But if you e.g. need to know the index of the button then you can just pass it as a constant to the connect function:

Code (cpp) Select Expand

void buttonPressed(int index)
{
    std::cout << "The " << index << "th button was pressed" << std::endl;
}

// The following goes in the for loop that you showed
b->connect("pressed", &buttonPressed, i);

The exact parameters are badly documented (or not at all if you consider that it doesn't mention the parameter type anywhere). For a SignalVector2f, the parameter type is just sf::Vector2f, so a callback function would look like this:

Code (cpp) Select Expand

void canvasClicked(sf::Vector2f mousePos) // mousePos is relative to canvas position
{
}

canvas->connect("MousePressed", canvasClicked);