Messages

Could you send me your data/gui folder so that I can test loading the file here?
Also, how are you checking the memory exactly? Did you check if the memory drops again after calling gui.removeAllWidgets() (e.g. do this on a keypress).

It wasn't possible to freeze the child window position, but I have implemented that now. If you download the latest version from github and build the library yourself then you can use the new setPositionLocked function (it will prevent the user from dragging the window, you can still call setPosition afterwards).

Code (cpp) Select Expand

childWindow->setPositionLocked(true);

Inside the Renderer section you can add a "Scrollbar" section where the renderer properties for the scrollbar are placed.

It should look like this:

Code (ini) Select Expand

ScrollablePanel {
    ContentSize = (0, 0);
    Size = (&.size, &.size);

    Renderer {
        backgroundcolor = white;
        bordercolor = black;
   
        scrollbar {
            texturearrowdown = "TGUI/themes/Black.png" Part(163, 174, 20, 20) Middle(0, 1, 20, 19);
            texturearrowdownhover = "TGUI/themes/Black.png" Part(183, 174, 20, 20) Middle(0, 1, 20, 19);
            texturearrowup = "TGUI/themes/Black.png" Part(163, 154, 20, 20) Middle(0, 0, 20, 19);
            texturearrowuphover = "TGUI/themes/Black.png" Part(183, 154, 20, 20) Middle(0, 0, 20, 19);
            texturethumb = "TGUI/themes/Black.png" Part(143, 154, 20, 20);
            texturethumbhover = "TGUI/themes/Black.png" Part(143, 174, 20, 20);
            texturetrack = "TGUI/themes/Black.png" Part(123, 154, 20, 20);
            texturetrackhover = "TGUI/themes/Black.png" Part(123, 174, 20, 20);
        }
    }
}

I generated the above by just running the following:

Code (cpp) Select Expand

auto panel = tgui::ScrollablePanel::create();
tgui::Theme theme("TGUI/themes/Black.txt");
panel->getRenderer()->setScrollbar(theme.getRenderer("Scrollbar"));
gui.add(panel);
gui.saveWidgetsToFile("temp.txt");

So you want the panel to display the top 424 pixels of the picture when the scrollbar is on top, the bottom 424 pixels of the picture when the scrollbar is around 2/3th down and no picture at all when the scrollbar is at the bottom? (The 424 might have to be 448 here, I don't know exactly how the panel looks, but those pixels are the visible part of the panel).
Then set LowValue to 424 (same as scrollbar height) and set the Maximum to 1224 (800 + 424 = size of picture + visible area of panel).

I didn't understand your problem and what you were trying to do with the scrolbarValue and what the multiplication by 8 is for.

If you just want to scroll all widgets in the panel except for the scrollbar then you need something like this:

Code (cpp) Select Expand

scrollbar_ZonesPanel->connect("ValueChanged", [&]()
        {
            int scrolbarDiff = int(previousScrolbarValue) - int(scrollbar_ZonesPanel->getValue());
            for(auto& widget : panel_ZonesPanel->getWidgets())
            {
                if(widget != scrollbar_ZonesPanel)
                    widget->setPosition(widget->getPosition().x, widget->getPosition().y + scrolbarDiff);
            }
            previousScrolbarValue = scrollbar_ZonesPanel->getValue();
        });

If that is what you need then maybe you could also have a look at the ScrollablePanel widget where you don't have to implement scrolling yourself: a scrollbar will appear if widgets no longer fit inside the panel or when you manually set the content size (with setContentSize) larger than the panel size.
Edit: ScrollablePanel is only in TGUI 0.8, so you won't be able to use it if you are still using 0.7.

This turned out to be a bug in TGUI. The kind of bug that makes you wonder how it could possibly have worked on linux and in debug mode.

A ChildWindow** was basically casted to a void* which later got cast to a std::shared_ptr<ChildWindow>*. Accessing the pointer of the shared_ptr would still work because this is the first part of the shared_ptr class, but accessing the reference count would access memory that doesn't belong to the variable. My best guess as to why it works in debug mode is because the reference count part would have been NULL so that it just ignores it. In release mode it would contain garbage and crash when it tries to dereference it. That would also explain why a const reference fixed it: it wouldn't have to access the reference count in that situation.

Anyway, if you download the latest version from github then it should work.

Alright, I managed to reproduce it with the libraries you sent.
I already figured out that it doesn't crash if the lambda parameter takes a "const tgui::ChildWindow::Ptr &" as parameter (instead of "tgui::ChildWindow::Ptr").

I still have no clue on what the issue could be and I'm starting to run out of ideas on what to test.

There is only one thing remaining that I could check. Would it be possible for you to create a complete bundle of the project and dependencies? Zip all SFML, TGUI files and your project, including the libraries and dlls that you build so that I can execute the exact same thing (you don't have to move the SFML and TGUI folders into your own project, I can put them on the right place on my pc manually). If it just runs here then it must be something about your computer, but if it doesn't then I can start replacing files with working copies from my pc until it works to find out where it is going wrong.

I already told myself multiple times that I should make a list of event names, but I never find the time and motivation to do it. For now you can find them in the documentation under the "Public Attributes" (e.g. https://tgui.eu/documentation/0.8/classtgui_1_1Slider.html#pub-attribs for Slider).
You will find a line like this:

Code Select Expand

SignalFloat onValueChange = {"ValueChanged"}

Ignore the "onValueChange", I intend to deprecate accessing the variable in the future. The name of the signal is the one between quotes, "ValueChanged" in this case. The SignalFloat also shows that the function can take an optional float as parameter, but the exact parameters may not always be that easy to guess from the signal name. Hopefully the one line description ("Value of the slider changed. Optional parameter: new value." here) will be enough in these cases.

I didn't actually try the project yet (I am going to do so today), but I already noticed a mistake in debug mode. Are you only testing in release mode? I assumed that when you were talking about the -O2 and -g flags you were just talking about Debug/Release modes, but are you perhaps using the same mode and just messing with the flags?
In the debug settings you are linking to the static version of TGUI but to the dynamic version of SFML, they are not compatible. The '-std=c++14' option also seems lacking in debug mode. I noticed that even in release mode you use "libtgui" instead of just "tgui", but I guess that doesn't make a difference.

Are you doing anything special to build 64-bit, because mixing 32 and 64 bit could also create issues. And despite the name "MinGW-64", it still works 32-bits by default. I'm just checking since the TGUI and SFML folders end with a "_64" postfix. Although since you said you build SFML and TGUI yourself with the same compiler, it's unlikely that you would be mixing these versions.

Edit: I can't reproduce it with MinGW either (although I only tested with a different MinGW version so far). Just to double check: you did replace the dlls next to the exe after rebuilding SFML/TGUI, right?

I can't reproduce this.
Only having it in release mode might indicate trying to use invalid memory, but I checked with valgrind and there are no problems with memory access.

Does it happen in a minimal example, just a main function with the minimal code for TGUI and where you only create a ChildWindow which has an empty lambda as callback?
Whether it still happens then or not, you should provide a small sample code that I can just copy-paste and run here to test under as identical circumstances as possible.

What OS and compiler are you using?

Backspace key should work fine. Try adding something like this in front of "gui.handleEvent(event)":

Code (cpp) Select Expand

if ((event.type == sf::Event::KeyPressed) && (event.key.code == sf::Keyboard::BackSpace))
{
// Check if you pass here or not
}

If the code never reaches the body of that if statement then it isn't a problem inside TGUI.

Could you elaborate on what you mean with "invisible marker"? The cursor should be blinking when the edit box is focused and should become visible on any operation (e.g. when you press an arrow key several times in a row, it will remain visible during this time).

I've implemented it such that the thumb will never be smaller than the scrollbar width.
You can download the latest version from github.

That's something that has been on my todo list for a while, so I guess I should really give this another look. It's not easy to add because it changes all the internal calculations about where the thumb is located, which is the reason why is hasn't been done yet.

But I'm not sure if it is necessary to have a setThumbMinimumSize function, I would just go with a max thumb size that equals either 1x, 1.5x or 2x the width of the scrollbar (I'm not sure what is best, I should look up again which was most commonly used, I think it was 1x).

Both issues have been fixed.

1) An "AnimationFinished" signal was added to the Widget class. The following calls are all valid (the ShowAnimationType parameter is the same as passed to showWithEffect/hideWithEffect while the boolean will be true for showWithEffect and false for hideWithEffect)

Code (cpp) Select Expand

widget->connect("AnimationFinished", [](){});
widget->connect("AnimationFinished", [](tgui::ShowAnimationType type){});
widget->connect("AnimationFinished", [](bool visible){});
widget->connect("AnimationFinished", [](tgui::ShowAnimationType type, bool visible){});

2) Although nested scrollable panels is an unlikely scenario, the issue would also happen on any scrollable widget within a scrollable panel (e.g. list box, text box, chat box, ...). The scrollable panel simply handled the mouse wheel event without checking whether any child widget should get it instead.

New version can be downloaded from github.

The hideWithEffect issue is intended behavior. If I wouldn't reset the position and size after the animation then it wouldn't be possible to hide and show the widget again, you would have to manually specify the size again before showing (in your case this is probably simple, but I imagine that others may not like to have to store the size themselves just to be able to show their widget again).

The timer solution sounds tricky, I can imagine that in some exceptional case your timer might expire before the internal timer in TGUI. I'll see if I can add a AnimationFinished callback that gets triggered at the end of animations, that might be a better solution.
The real solution would be to have proper animation support, where you would be able to define both a begin and and end state (so that you can move a widget from one place to another or like in your case change the size from some value to another). When I originally looked into this I decided to just keep things simple and only add animation support for showing and hiding and I don't think that will change soon.

Not being able to scroll when the scrollbable panel is inside a panel sounds like a bug, I'll look into that tomorrow evening. The ignoreMouseEvents function only exists for Picture and Label so it isn't relevant here. Even if it existed for Panel, it would also mean that the events would never reach the ScrollablePanel but would instead be delivered to the widgets behind the Panel.

The code you showed doesn't actually do anything other than create a blank window. It initializes the gui but doesn't add anything to the gui to show. You still need to add a widget to the gui in order to have something drawn on top of the SFML window. But if that code runs then TGUI has been setup correctly.

Try running something like this to display a button on the screen:

Code (cpp) Select Expand

#include <TGUI/TGUI.hpp>
#include <iostream>

int main()
{
   sf::RenderWindow window{sf::VideoMode(1024, 760), "Window" };
   tgui::Gui gui(window);

   auto button = tgui::Button::create("Click me");
   button->connect("pressed", []{ std::cout << "Button was pressed" << std::endl; });
   gui.add(button);

   while (window.isOpen())
    {
      sf::Event event;
      while (window.pollEvent(event))
      {
         gui.handleEvent(event);
         if (event.type == sf::Event::Closed)
            window.close();
      }
      window.clear();
      gui.draw();
      window.display();
   }
}

The tooltip gets positioned in this part of code, which has no idea about the original widget to which the tooltip is connected (and it thus can't know that the widget is at the bottom).
The position is determined by 3 parts: the mouse position, a constant offset retrieved via ToolTip::getDistanceToMouse() and the position of the tooltip widget which is normally always (0,0). The first one can't be changed and the second one applies to all tooltips, so only the third one can be used to alter the position without changing the current design. If you know the widget is at the bottom then you can create the tooltip like this: (code hasn't been tested)

Code (cpp) Select Expand

auto tooltip = tgui::Label::create("Tooltip text");
tooltip->setPosition(0, -tgui::ToolTip::getDistanceToMouse().y - 20);
widget->setTooltip(tooltip);

But that is just a hack, you can't even rely on the label height (unless you call tooltip->setFont yourself first) because it will only receive a font when it becomes visible.
The only way to do it properly is to change the current design and rewrite how tooltips are created.

I couldn't actually reproduce what you said, when I tested the tooltip in a ScrollablePanel it didn't even show up when the panel was scrolled.
I've fixed this behavior, you should check if your problem is solved when you download the latest version from github (https://github.com/texus/TGUI).

This was a bug, it has been fixed in the version that you can download from github.
It's an interesting bug, it can't be solved easily and I'm going to have to fix this properly at some point, but for now I added in a small hack to make it work.

Panel is initialized with size {"100%, "100%"}, which will only be (0,0) if the parent of the panel has size (0,0).
My guess is that you haven't added the panel to its parent yet (by doing something like "gui.add(panel)") when you are calling getSize. If you don't call setSize then the panel will automatically change its size when you add it to its parent (since it detects a parent size change at that moment). When you call setSize(0,0) then you are giving it a fixed size instead of binding its parent size which is why it will remain (0,0) even after adding it to its parent.

Panels can't auto-size based on its content, you can't have its size depend on the widgets inside it, you can only make it depend on its parent (e.g. panel->setSize({50, "100%"}) will set a fixed width and variable height).

You can calculate the size needed by the panel by looping over all its widgets (accessible with panel->getWidgets()) and calculating the maximum value of "widget->getPosition() + widget->getFullSize()". (I use that calculation myself in ScrollbablePanel but just realized that this may be incorrect and you probably also have to add widget->getWidgetOffset() to be fully correct for all types of widgets). You would have to keep track of when you add/remove widgets to the panel yourself and update the size of the panel manually.

Is "Enable c++14" (or "Enable c++1y") checked in the compiler settings?
Make sure to use an SFML and TGUI version that match each other and the compiler. SFML 2.5 only provides a build for GCC 5.1, similar to the TGUI 0.8 alpha version. If you use GCC 4.9 (from codeblocks 16.04) then you not only have to use the SFML 2.4.2 package but also a TGUI version that was build with SFML 2.4.2 and GCC 4.9 (like the pre-alpha versions). If you can't find matching versions then you could always build SFML and TGUI yourself with whatever compiler you want to use.

I would suggest just getting CodeBlocks 17.12, SFML 2.5 and TGUI 0.8-alpha, all using TDM GCC 5.1 (SJLJ).

_Unwind_Resume indicates that the libraries were build for a different compiler version. Since SFML 2.4.2 had libraries build for TDM GCC 4.9 and the latest codeblocks uses TDM GCC 5.1 by default, that might be the issue.

The most important thing to check for these errors is under the "Linker settings" tab. Based on the errors I would guess you are linking to static SFML libraries (ending with -s but with dynamic TGUI libs, or the other way around). Make sure both SFML and TGUI have the same suffixes (combinations of "-s" and "-d") and that SFML_STATIC is defined under "Compiler settings" > "#defines" when linking to SFML and TGUI statically.

What does "tgui::getDoubleClickTime()" return?