Messages

setSize is implemented in Button while isMouseDown is implemented in the Widget base class. If the first one crashes while the other does not then it may imply that the object is a Widget but not really a Button.
Since your code works here, I'm starting to wonder if there might be some library incompatibility that causes the Button class in your code to be different from the Button class in TGUI code.

Did you compile SFML and TGUI yourself or did you download precompiled versions from the websites? Which visual studio compiler are you using exactly? Are you certain you aren't linking to Debug libraries while in Release mode, or vice versa?
I noticed you mentioning debug mode but also mentioning tgui.dll, which is the release dll. Make sure to use the library with "-d" postfix in debug mode (for both SFML and TGUI).

What is the contents of startMenu.txt? Are you certain it contains a button with the name "loadFromFile" or "a"?
The access violation happens on a nullptr, which is what the get() function returns when no widget exists with that name.

The behavior in TGUI 0.8 was too surprising for a lot of people so it was changed to a new system.

When the close button is pressed, onClosing event is triggered which has a boolean as parameter that you can set to true to prevent the window from being closed.
If there are no signals connected to onClosing or none of them set the abort parameter then the onClose event is triggered. After this event the window will be "destroyed" (i.e. removed from the parent with parentGroup->remove(childWindow)).

Instead of toggling the visibility you could just call group->add(childWindow) again when you need to show the window again.

Alternatively, you can prevent the window from being closed in the onClosing event and change the visibility there:

Code Select Expand

childWindow->onClosing([=](bool* abort){
    *abort = true;
    childWindow->setVisible(false);
});

That function was never intended to be used directly in previous versions of tgui.
If your group is part of the gui then gui.handleEvent should pass the event to the correct group.
In what scenario do you think you need to pass the event to the group directly?

removeItem apparently shouldn't throw out_of_range even when a wrong index is provided, but I did notice something else in the code that could go wrong.

removeItem() will remove the selected item and thus cause the selection to change. The onItemSelect is triggered halfway through the removeItem() call, so your updateGui is called while removing the item. I'm guessing the updateGui function probably does something with the list view which causes the error.

What is the value of listView->getSelectedItemIndex() inside the onMousePress function? Is there any chance that it is -1 when it throws (which is the case when no item is selected)?

Understanding std::function and lambdas is useful for the signals in TGUI (since examples often use lambdas to keep the code shorter).
Understanding smart pointers (e.g. shared_ptr) is useful to work with TGUI widgets (since Widget::Ptr is just an alias for std::shared_ptr<Widget>).
Other than that, a basic understanding of c++ is required, but you might be able to learn it as you go.

The tutorials (https://tgui.eu/tutorials/0.9/) and example codes (https://tgui.eu/examples/0.9/) provide some useful information.

menu->connectMenuItem("File","Exit",[&]{ window.close(); }); should work fine. Do you have a case where it doesn't work?

I'm not sure what the best fix would be for this case.

The height of the grid is set to 20% of the panel, which fills the window (which has a height of 400 pixels), thus the grid only has a height of 80 pixels.

You are adding 25px padding above the labels and between label and edit box.
With a character size of 20, the label has a height of 27px and the edit box of 22px.
The total height of both rows is thus 99px.

The hover only looks at the top 80px because it considers everything else to be outside the grid, while the rendering doesn't perform any clipping and thus renders the last 19px as well even though they lie outside the grid.
The most correct solution based on the current code would actually be to add clipping to the rendering and not draw the bottom part of the edit boxes.

Yeah, the precompiled TGUI libraries from the website are only compatible with the SFML 2.5.1 release. When using an SFML snapshot then you must build TGUI yourself from the source code.

Where did you download SFML and TGUI?

I'm guessing that TGUI was build with a different SFML version than the one you are using in your project.

I didn't know about the DOXYGEN define, that might come in handy some day.

Once the new backend system is released I'll see whether it will be easier to put all backends in the PREDEFINED field or change the code to check DOXYGEN everywhere.

For now I was going to build only the documentation of the SFML backend (since this is what almost everyone used) by just adding the TGUI_HAS_BACKEND_SFML to the Doxyfile.
I just realized that it isn't enough those, the Gui class isn't missing because it is behind an ifdef like the Canvas class, it is missing because the directory containing the heading isn't part of INPUT. So I might wait until after 0.9.3 to determine which files need to be in the documentation (all of them probably, once I'm done reorganizing).

This will define these both only for Doxygen, so you can leave your compile settings as they are

This reminds me that I should probably check other defines as well instead of leaving them to whatever the settings were on the last build. The TGUI_COMPILED_WITH_CPP_VER for example should probably be set when building the documentation so that any functionality with the latest c++ standard is always shown (e.g. for string_view conversion functions in String class).

this method won't include the code within both an #ifdef and any associated bare #else

I don't think that will be an issue, such cases shouldn't exist for the TGUI_HAS_BACKEND_XXX defines (and the few cases where they do exist are probably all inside the source code and not inside headers).

I think I might even be talking about a different issue, I though the problem was that the horizontal scrollbar appeared and your 50% width wasn't working correctly.

The vertical scrollbar isn't going to work when you set the grid size to 100%. The size of the grid should depend on its contents or be a chosen size, you shouldn't limit it to the viewable area of the scrollable panel (which is what 100% does). You'll want the grid size to be larger than 100%, because otherwise there will never be anything to scroll to. If you don't call m_grid->setSize then you will see that the vertical scrollbar works as intended (the columns in the grid need to be given a different width in that case though as auto-sizing puts the columns too close to each other). If you call "m_grid->setSize({ "50%","150%" });" for example then the vertical scrollbar can scroll to all contents (but you would have to set the policy of the horizontal scrollbar to Never to not overlap with the last edit box due to the issue I described in my previous post). There is no space below the last widget in the grid, but this could be solved by either specifying a bottom margin when adding it to the grid or manually setting the content size to something larger than the grid size (maybe setting a padding in the scrollable panel might also work, I haven't checked).

Issues like this really expose how TGUI started with having everything at fixed coordinates and where relative positions/sizes are just hacked on top of that instead of the library being designed with dynamic sizes in mind.

This is because the inner size of the ScrollablePanel never changes when scrollbars are visible or not.
I agree that this isn't ideal and it should probably be changed, but right now it is the expected behavior.

Implementing this properly is a bit tricky: whether scrollbars are shown could depends on the widgets inside the panel, but the size of those widgets would depend on whether there are scrollbars.
So when writing the ScrollablePanel widget I decided to just keep it simple and ignored this case.

Edit: Maybe I could change the inner size when Policy::Always is specified and leave the more difficult case for later.

Thanks for letting me know. I guess I should enable the TGUI_HAS_BACKEND_SFML define next time I build the documentation.

For TGUI 0.9.3 I'm planning to rewrite the backends anyway, so I'll add a note that I have to look at improving the documentation (to make Gui classes from all backends show up).

The TGUI version from github now places the tool tip so that it doesn't fall (partially) outside the window.

It's currently not possible.
I might have a look at implementing this in the next few days. It doesn't look that difficult, I think this line just has to check if the position plus size of the tooltip is larger than the size of m_view.

I can't help you with that IDE. The only thing I know is how the command that is passed to the linker should look like: for dylibs it should be "-lXXX.dylib" while for frameworks it should be "-framework XXX".

To find a different SFML version you have to change the SFML_DIR option. The value has to be the directory that contains a file called SFMLConfig.hpp. I can't tell you which folder this is, as it depends on your SFML installation, but suppose SFML is installed to /usr/local then the folder would most likely be /usr/local/lib/cmake/SFML.

Alternatively you could always install SFML and TGUI using homebrew.

It seems like TGUI links to the frameworks then.

I don't think there is an easy way to choose whether TGUI links to dylibs or frameworks in CMake, it probably uses the first one it finds (unless you either set SFML_DIR manually or show the advanced options and manually change the paths of the SFML libraries).

So the solution is probably to either link to the SFML frameworks in your project, or to rebuild TGUI after removing the files from that Library/Frameworks folder (because TGUI will then find the SFML dylib files instead of the frameworks).
Edit: After thinking about it, TGUI might fail to find SFML when the frameworks are removed (when attempting to build TGUI with cmake again). There is an SFMLConfig.cmake file which TGUI finds and that one probably still points to the framework. So you would have to delete that file as well, or set SFML_DIR to a different location. Just keeping TGUI unchanged and linking to the SFML frameworks in your project thus sounds like the easier solution.

The error about SFViewController means that your project is linking to both the SFML framework and the dylib file, while you should only link to one of them.

The opengl error is probably caused because one SFML version gets initialized properly while the second one isn't initialized and believes it has no opengl support.

In your project you are probably only linking to one of these versions, but TGUI will be linking to the other one. You need to make certain to use the same SFML version in your project and when building TGUI. So how did you install TGUI exactly?

TGUI is probably not the best option for such case. The FileDialog widget was added in cases where you basically wouldn't want to have an external window.

You might be better of using something like https://sourceforge.net/projects/tinyfiledialogs/ or https://github.com/samhocevar/portable-file-dialogs

They keyboard could be a Panel widget with a lot of buttons then. To show the keyboard you call gui.add(panel) and when you want to hide it you call gui.remove(panel).

I would implement it similar to what I describe below. Note that I didn't test any of this code or think about it for long, there might be other/better ways to do it (e.g. I know that the keyboardShown boolean could be replaced by querying the gui for whether it contains the panel).

Code (cpp) Select Expand

void EditBoxOrTextAreaFocused(tgui::Widget::Ptr widget, const tgui::String& /*signalName*/)
{
    focusedTextField = widget;
    if (!keyboardShown)
    {
        keyboardShown = true;
        gui.add(keyboardPanel);
    }
}

Code (cpp) Select Expand

void EditBoxOrTextAreaUnfocused()
{
    focusedTextField = nullptr;
    if (keyboardShown)
    {
        keyboardShown = false;
        gui.remove(keyboardPanel);
    }
}

Code (cpp) Select Expand

editBoxOrTextArea->onFocus.connectEx(&EditBoxOrTextAreaFocused);
editBoxOrTextArea->onUnfocus(&EditBoxOrTextAreaUnfocused);

I'm using connectEx on onFocus instead of a normal connect in this example so that the callback function gets the widget as parameter without you having to pass it yourself. Otherwise you would need something like `editBoxOrTextArea->onFocus(&EditBoxOrTextAreaFocused, editBoxOrTextArea)` in which copy-paste errors are more likely to happen as you always need to pass the same argument as the widget on which you call onFocus.

For each button on the keyboard you could do something like this:

Code (cpp) Select Expand

void VirtualKeyboardKeyPressed(char32_t key)
{
    assert(focusedTextField != nullptr);

    focusedTextField->setFocus(true);

    tgui::Event event;
    event.type = tgui::Event::Type::TextEntered;
    event.text.unicode = key;
    gui.handleEvent(event);
}

Code (cpp) Select Expand

buttonKeyA->onPress(&VirtualKeyboardKeyPressed, 'a');

Backspace and other special keys need a separate function. You can use a KeyEvent instead of TextEvent to pass a backspace to TGUI.

EDIT: After typing this I just realized that unfocus is going to be a bit more difficult. In this code the EditBoxOrTextAreaUnfocused would be called and hide the keyboard each time you press a keyboard key.

It depends on what you want to do.
If you just want some virtual keyboard to be displayed then you might be better of with calling some OS-specific function.
If you want to create a window with a virtual keyboard yourself then you could use TGUI for it, each key is simply a button.
If you want the virtual keyboard in the same window as your application then it might cause some issues: pressing a key on the keyboard will move the focus to that button, so the edit box that you had selected to type in will lose focus.

especially since I'm attempting to use OS-exclusive renderers where I can (i.e. Metal for macOS and Direct3D11 for Windows)

TGUI has to use the same renderer as your code, so if you were to use these renderers in your code directly then you would have to write a TGUI backend for each platform to do so.

You can rely on SDL_Renderer to abstract the backends so that you only need to use SDL_Renderer and don't have to bother with whether it uses metal or directx internally, but SDL_Renderer has its limits (it can't even draw a simple filled triangle or circle). When I started porting TGUI from SFML to SDL I started with the SDL_Renderer, until I encountered things that I simply couldn't do with it and learned that many projects don't use SDL_Renderer and instead use their own rendering code (which makes it very difficult to have the same rendering code in TGUI as in user code, hence why I skipped adding the Canvas class).

Using OS-exclusive renderers isn't always the best approach either. According to https://stackoverflow.com/a/59725539, the Metal backend used by SDL_Renderer is even slower than the OpenGL backend on macOS (unless that changed within the last year).

If you wouldn't care about OS-exclusive renderers then perhaps I could consider creating a Canvas widget where you can render simple text and images to (via functions on the Canvas object, e.g. it would have a drawText function). Then you would use TGUI for rendering them instead of accessing SDL directly. It would be a very limited interface and it would require using OpenGL on all platforms though.

Technically TGUI could be made compatible with SDL_Renderer (by adding a new backend for it), but it would have to result to software rendering for drawing triangles, which would make it very slow.

So depending on what you need, TGUI might not work for you.

I think I understand what you are trying to do, and you would need a Canvas if you don't want to manually keep track of gui widgets coordinates.

The problem is that what you are describing technically can't work correctly as far as I know. Are you already rendering with SDL while also drawing with TGUI or is this something you plan on doing? From what I read, you can't use an SDL_Renderer and OpenGL context on the same window without messing up the rendering (and TGUI requires an OpenGL context on the window). So even without the Canvas widget, manually drawing stuff with SDL leads to undefined behavior (such as rectangles being drawn instead of text characters).

The only way you would be able to manually draw with SDL_Renderer without causing a rendering conflict is if TGUI's SDL backend would use an SDL_Renderer instead of OpenGL for drawing (but I can't do that because SDL_Renderer can't render triangles).

What kind of things do you need to draw on the canvas?

What is the proper way, with the SDL backend, to reserve an area of the GUI window for directly rendering, say, SDL_Textures to?

This is currently unsupported in the SDL backend. The canvas code is behind and ifdef guard because it didn't get ported.

The main problem that I had was not knowing how people were going to use it.
The SDL/OpenGL backend doesn't use SDL_Texture, so that couldn't really be used. The canvas would have to use opengl code, but I don't have enough experience with it to assure that your own opengl code wouldn't conflict with the TGUI code.

The only workaround that I know if performance isn't an issue is to somehow get what you want to render into an image. You can create a tgui::Texture and call loadFromPixelData and then set that texture in a tgui::Picture widget.

The SDL renderer itself was too limited to port TGUI to, which is why I had to use opengl. But that probably also means that your code can't use SDL_CreateRenderer and simple SDL rendering functions.
So I'm not sure how to best solve this situation either.