Messages

The path variable has the exact same problem as explorer has, that is why I said it wasn't a proper solution. The Filesystem class object has already been destructed by the time the callback occurs, so accessing any member from it causes undefined behavior.

The real problematic code is not inside the Filesystem class, but in Menubar. The code immediately destructs the Filesystem after creating it.

Code (cpp) Select Expand

{
    Filesystem fs(true);
}

Your Filesystem object is destroyed immediately after it gets created in the MenuBar class. The lambda that is called on button press accesses "explorer" which is equivalent of writing "this->explorer" in this case, but your "this" object has already been destroyed.

It isn't a proper fix (you should keep your Filesystem class alive), but the code below does work because it no longer uses "this" and instead uses a copy of the listbox.

Code (cpp) Select Expand

openDirButton -> connect("pressed", [e=explorer](){
  std::cout << e -> getSelectedItem().toAnsiString() << std::endl;
});

I received the PM and have been able to reproduce it. I was accidentally using 0.8 earlier which is probably why I couldn't reproduce it before you sent the project.

Sure, if its not too hard to build it.

I can't reproduce this. It prints the selected item in the terminal for me. Could you try and make a minimal code that I can just copy-paste and run so that I'm certain that we are testing the exact same code?

Could you show the code that you use to create the ListBox?

It means the image is not at the location where it is searching. To check that there is no problem with the image, you can try loading it from an absolute path (e.g. "C:\Users\...\image.png" instead of just "image.png" (although if there is something wrong with the image itself you would get another error).

Depending on the IDE, the image is searched next to your executable or next to your project file. I think CodeBlocks searches next to the project file. So if you load "image.png" then it will search in the project folder when running the program from CodeBlocks, while it searches next to the exe when executing the exe directly. So make sure the image is located in the right folder.

Could you describe the problem in more detail? What are you trying to do exactly? What isn't working? What instructions are you following?

What exactly are you asking for? I don't see what a GuiManager class could do that you couldn't easily do yourself by just putting them in a list or map.
All you need to do to create multiple scenes is create a Group (or Panel) widget for each and only show one Group at a time. When switching scenes you just hide one group and show the other.

I assume the gui elements are on top of your game, because if all gui widgets were in a bar at a side of the screen then it would be a simple as just checking whether the mouse is on top of this sidebar.
You would have to check every widget if you really need to know whether the mouse is on top of the gui or not. But first you should ask yourself the question whether you really must check this. Why would you need continuous mouse events that interfere with the gui? If for camera movement, should the camera stop moving just because you hover over a widget but start moving again once you move the mouse next to it? I can't give you a better alternative to looping over the widgets if I don't know what the real situation is.

But at least there is a simpler way than connecting MouseEntered and MouseLeft signals, so looping over the widgets isn't actually that bad:

Code (cpp) Select Expand

bool mouseOnWidget = false;
for (const auto& widget : gui.getWidgets())
{
    if (widget->mouseOnWidget(currentMousePosition))
    {
        mouseOnWidget = true;
        break;
    }
}

Or if you prefer a one-liner:

Code (cpp) Select Expand

bool mouseOnWidget = std::any_of(gui.getWidgets().begin(), gui.getWidgets().end(), [=](const auto& w){ return w->mouseOnWidget(currentMousePosition); });

After that you simply don't execute your code if mouseOnWidget is true.

The handleEvent function returns a boolean which contains whether the gui responded to the event. So you should first call gui.handleEvent(event) and check the return value, only handle the event in your own code when handleEvent returned false.

The fix has now been merged into the SFML master branch and added to the TGUI.Net download.

I have added a BitmapButton widget to 0.8-dev.
The image can be set with the setImage function and will by default have the size of the texture itself and independent of the button size. If the image size has to depend on the button size, call the setImageScaling function with a number between 0 and 1. The height of the image will be the size of the button multiplied with that number (the width will be changed as well of course to maintain the ratio of the image).

Example:

Code (cpp) Select Expand

auto button = tgui::BitmapButton::create();
button->setText("Text");
button->setImage("image.png");
button->setImageScaling(0.8f);
gui.add(button);

Such a widget is currently not supported.
You could write it yourself by inheriting from the Button class and changing the draw function.
Alternatively (at least in 0.8-dev, I don't know about 0.7) you could display a picture and a label in front of your button and call ignoreMouseEvents(true) on these widgets so that a click on them occurs on the button behind them. But this means you would have to create 3 widgets for each such button you want to create.

This has been requested before and I'm just finishing up on the stuff I was working on without any concrete plans yet for the next thing to work on, so I'll probably have a look whether I can add such a button in TGUI somewhere this week. If everything goes well it might already be available before the end of the weekend, but I won't guarantees that it will be ready so soon.

Since Rect is a template class, it shouldn't even be possible to have it defined twice, so the error makes little sense to me.
Since this is a linking error, could you try not linking to tgui? That will of course give a lot of undefined reference linking errors, but the question is whether this error remains or is gone. If the error disappears then maybe the SFML libraries you are using don't match the ones that were used to build TGUI.

Edit: The tgui::FloatRect class might be the reason why it can be defined twice (because it inherits from sf::Rect). I'm guessing you are linking dynamically? You could also try editing the TGUI/include/TGUI/FloatRect.hpp file and remove the TGUI_API on top (so change "class TGUI_API FloatRect" to "class FloatRect"). You don't have to recompile TGUI to test whether this worked, although I can't guarantee that you don't get other linking errors about this class if TGUI isn't recompiled.

Although technically the functionality exists inside TGUI, it doesn't seem to be possible. In TGUI 0.7 the Picture simply doesn't allow accessing the internal texture and in TGUI 0.8-dev where it does provide access to it, the class was redesigned and it simply isn't possible anymore.
So the only option that I see would be to use the Canvas class. It is basically a wrapper around sf::RenderTexture, but since it acts like a widget, it is drawn between the other widgets.

Code (cpp) Select Expand

auto canvas = tgui::Canvas::create({400, 300});
gui.add(canvas);

canvas->clear();
canvas->draw(...);
canvas->display();

You don't need to do the clear/draw/display every frame, only when the contents of the canvas has to be changed.

I think this issue has been fixed already, could you try with putting this in the file: https://github.com/texus/TGUI/blob/0.7/widgets/TransparentGrey.txt (that is the contents in the upcoming 0.7.6 release)

No wonder I couldn't figure out the issue, it isn't in my code at all.
It's a bug in SFML, I reported it on their forum: https://en.sfml-dev.org/forums/index.php?topic=22787

I haven't been able to figure the upside down issue out yet, I'll have another look tomorrow. It definitely seems to be an issue in my code somewhere. I managed to reproduce it in CTGUI (the layer between TGUI and TGUI.Net) now, so at least I will be able to print text in the terminal when debugging tomorrow.

Update: Although I still don't know what the exact issue is, it seems to happen when using the TGUI version shipped with TGUI.Net but not with the latest TGUI version. So I guess I fixed it somewhere in the last 6 weeks without even knowing there was an issue. I'll update TGUI.Net soon, but this can take a few days at least.

SFML.Net seems to implement the Transformable class entirely in C#. This is great for people using just .Net since there is no overhead from calling the C functions, but it means that the c++ code has no idea about the transformable at all. SFML.Net was clearly only written for building C# code on top of it and not for other libraries that hook into the underlying c++ code (although I already figured that out quite some time ago). I managed to fix it though by letting the Canvas in C# apply the transformation on the RenderStates before passing them to c++.

That limitation is coming from the c++ API actually. In C# where every object is similar to a smart pointer in c++, ownership of objects isn't an issue. But in my c++ code it complicates a lot. All textures are owned by the widget itself, but by using an existing texture I would have to use a pointer to a texture. In order to support that I would have to start manually allocating and destroying the textures owned by widget and keep track of whether the widget can delete it or whether the texture is external and has to be kept alive.
It would also fail to work if implemented naively because C# may destroy the texture before the picture is destroyed (since C# doesn't know about the c++ pointer), but I think I just realized why the Sprite class from SFML also stores the texture in C# as well. I would have to do the same thing everywhere textures are used.
I think you will just have to call "picture.Renderer.Texture = intermediate;" every time you update the RenderTexture.

I'll look into the scaling issue later.

TGUI.Net doesn't have all the features that exist in TGUI because the C interface used to communicate to TGUI can't do everything. There are some things that are possible but which I just decided not to spend time on them until someone requests them though. But the things you request seems to have technical limitations.

The Canvas.Draw method seems to be difficult. I can't pass a drawable through C due to the way CSFML defines the Drawable class (it actually doesn't even have a Drawable class). I also don't think I can use the trick that SFML.Net uses in RenderWindow. The RenderWindow.Draw(Drawable) function simply calls the Drawable.Draw function which works because it hardcodes that there are only 2 different type of RenderTargets: RenderWindow and RenderTexture. Canvas is neither nor does it have a RenderTarget in the C# code.

I'm also curious as to why this is preferred over something like just supplying a RenderTexture to a Widget, similar to the way you would wrap a RenderTexture in a Sprite. This would avoid the confusing "Draw" - some object into Canvas vs "Draw" - canvas into some RenderTarget. Is there a way I could do this instead?

I didn't fully understand what you meant by this. Could you elaborate a bit on this, perhaps with some pseudocode of how you want it to work?

General advice on extending the Widget system in .net would be really appreciated as well

I'm not sure if custom widgets are possible on top of TGUI.Net due to its strong relationship with the c++ code. If you inherit from an existing widget and just add some C# code on top then MAYBE you would be able to have a custom widget. But a widget written entirely in C# is probably not going to work at all.

After spending some time debugging this, it seems to be an issue with SFML. Luckily they made some changes in the related code 4 weeks ago (while the SFML version shipped with TGUI.Net was 5 weeks old) which seem to have fixed the problem. I have updated the SFML version now, if you download TGUI.Net again and use the new files then the crash should be fixed.

I'll try to look into this tonight. Thanks for the detailed description.
Just in case I wouldn't be able to reproduce it: what compiler are you using?

I've added a scrollbar policy in the latest version so alternatively to subtracting the scrollbar width you can now remove the horizontal scrollbar like this:

Code (cpp) Select Expand

panel->setHorizontalScrollbarPolicy(tgui::ScrollablePanel::ScrollbarPolicy::Never);