Messages

I'm not sure what the problem is, it works here on VS2019 v16.2.3
Are you using the v142 platform toolset (can be seen in project properties)?

The warning in to_string.hpp is harmless.

Edit: I've found a bug report for VS, but it should have been fixed in VS2017 already (https://developercommunity.visualstudio.com/content/problem/203575/constexpr-default-constructor.html)

You could store the colors in a separate list instead of trying to reuse the existing items list, but you would still have to replace all functions that add, remove or changes any of the items.
I'm not sure what the best way to add the functionality would be either.

Making every row or cell a widget is going to be a huge performance issue. There is a reason why I now have a Text class to display texts instead of using the Label widget everywhere like it used to be.

The "simple and dirty way" is probably what I would end up doing if I needed it, but I don't really feel like this is a good addition. The functionality is very niche and it complicates the code more than I would like.

Maybe you should just inherit from ListView and make the modifications in your inherited class. If changes are needed to ListView to make it easier to implement your custom widget on top of it then I'm willing to look into that, but getting the code you want into the TGUI ListView class is probably not going to happen.

with older drivers the program is working

If the same code is working with an older driver then it would appear to be an issue with the newer driver, but then it should also crash when using sf::Texture and sf::Sprite directly.
With such a weird crash, the only thing really comes to mind if it doesn't happen in SFML is some incompatibility between SFML and TGUI, i.e. TGUI not being compiled with the SFML version that you use in your project.

opengl is downgrading to 2.1. ( i set 3.0)

This is probably due to the driver, but unless you want to use opengl directly it won't make a difference.

no windows updates, no drivers updates since 2015.

It might help to install windows updates if they are available, I've had some weird issues with SFML magically go in the past away after updating the old windows pc.

much older sfml and tgui version (2017 era) was working just fine.

TGUI still supports these older SFML versions. So perhaps you could try building TGUI with an older SFML version. If that works then you know it is due to the newer SFML version, if it doesn't work then it might still be something about the newer TGUI version.

I'm not sure what you are referring to, there is no function called RemoveWidget.
To remove a widget from the gui, you just call gui.remove(widget).

And a side note: someone need to add more tutorials.

Feel free to contribute some

I've though about it in the past, but I never got around to actually do it.
It would add even more duplication than there already is in the gui as it must have most functions from both EditBox and SpinButton.

Writing it would also be so much easier if a widget could consist of subwidgets. Right now you either have to manually deal with all events yourself of make the widget inherit from Group which adds several functions to the API that you wouldn't want in your widget. I think I'm going to look into this issue in the near feature. I'm not going to be adding the SpinCtrl widget soon, but at least I'm going to try to make it easier to add in the future.

I'm not going to be adding it anywhere soon.
The ListView was created to satisfy most requests for list views and tables. It took me a long time to finally write it and it is now the most complex widget in the gui, so I'm not looking forward on writing another similar widget right now. I guess it could be implemented in the ListView itself even though it doesn't really belong there, but as with most feature requests that are being made recently, I won't be doing it soon.

I've recently used VS2019 without any issues. It looks to me that you don't have the command line compiler of VS2019 installed. Did you choose to install the build tools for c++ when installing VS2019?
Does it work with other libraries, e.g. SFML?

Edit: maybe you need to select the Win64 generator instead? I think they defaulted to 64bit compilers on 64bit Windows with VS2019.

Is it possible to bind to the underlying up/down button presses?

No, value changed signal is send for every kind of change, no matter whether a an up/down button is pressed, the mouse wheel is scrolled, the track is clicked or the thumb is dragged.

I actually added a way to temporarily disable a signal some time ago just for this kind of situation.

Code (cpp) Select Expand

scrollbar->onValueChange.setEnabled(false);
scrollbar->setValue(...);
scrollbar->onValueChange.setEnabled(true);

setVerticalScroll has been added again to Slider, Scrollbar and SpinButton

I'm not sure where to best document it.
Maybe we just need to add setVerticalScroll back, but still keeping the automatic detection based on size. So all existing code would still work, but you would also be able to call setVerticalScroll which would swap width and height values if they don't correspond to the requested direction. That way it might be more intuitive to use.

I currently don't have any plans for it. I implemented the clicking signal because I believe it is a necessity for sorting columns. Other things like different colors, showing a small arrow inside the column header or even supporting sorting in the widget itself are extras that I am at this moment not going to spend my time on. I would love to see these things supported too, but I can't do everything at the same time.

Btw, if you use ListBox or ComboBox widgets then you may want to download and rebuild TGUI again. Together with the change to ListView I also pushed another change online which had a bug that could lead to a crash when using ListBox or ComboBox. The issue has been fixed by now. It slipped through my linux test that I ran before making the code public, but luckily it was caught by my windows tests afterwards (which actually runs the exact same code as the passing linux test).

I've added a HeaderClicked signal. Your callback function can have an int parameter which will contain the index of the clicked column.

The ListView has a "ItemSelected" signal that gets called when an item is highlighted and a "DoubleClicked" for when double clicking an item. If the Open_file function has an int parameter then it will contain the index of the selected item.

I'll look into adding a signal for a click on the header soon.

And yes, pointers and reference variables still have my mind in a flip-flop. On the surface they're simple, but they get complex very fast it seems.

Yeah, you can explain how to use them in a couple minutes, but the only way to really understand them is by actually using them in a few small programs.
Luckily you typically don't need the more complicated stuff like using pointers to an array of pointers or doing pointer arithmetic. Although pointer arithmetic could still be interesting to learn about if you want to understand how looping over a vector with iterators works (as std::vector<T>::iterator is just a T*).

RightMousePressed, RightMouseReleased and RightClicked signals have been added to ClickableWidget and Panel widgets.

The ability to right click came up once or twice in the past, so I guess it wouldn't hurt to add callbacks to ClickableWidget and Panel. I'll do that soon.

Kvaz1r is correct, all you need is a simple std::function<void()> to store the callback function.

Without adding extra code around it, you can only store free functions that have no arguments, but even in complex cases std::function<void()> is what you store it in eventually (unless you e.g. always have the widget as argument in which case you put that type between the brackets). If you strip away all the complex signal handling code in TGUI then you find a simple map that stores all the callback functions and their unique id.

Code (cpp) Select Expand

std::map<unsigned int, std::function<void()>> m_handlers;

You might want to look at some tutorial on references and pointers, as it is important to fully understand how memory is managed in order to avoid a lot of issues. Learning about std::shared_ptr is also going to be important when working with TGUI widgets, as Widget::Ptr is just a typedef for std::shared_ptr<Widget>.

Normally you have something like this. Both the window and gui are values stored on the stack. The tgui::Gui constructor takes a reference to the window as parameter, so although the code would be identical if it were to copy the window, nothing is copied when creating the gui.

Code (cpp) Select Expand

sf::RenderWindow window(...);
tgui::Gui gui(window);

"&window" gives you a pointer to the window. This is not what the Gui constructor expects so you can't pass that. Although references are most likely implemented as pointers behind the scenes, references still act like objects in the code instead of as pointers. Pointers should actually be avoided when possible. The general rule is to use pointers when an object can be a nullptr (so for optional objects) and use references otherwise (or just copy them by value instead of referencing to the original object if it is something small like an int).

If your window is stored as a pointer then you need to dereference it. Notice the '*' in front of 'window'.

Code (cpp) Select Expand

sf::RenderWindow &window;
tgui::Gui gui(*window);

So in your case, it would look like this:

Code (cpp) Select Expand

tgui::Gui gui(*this->window);

I would actually advice against using a pointer for the window, the window is always going to be created with your Game, it is not something that can optionally exist. You will have to learn how to use the initializer list of the constructor (not to be confused with the completely unrelated std::initializer_list) in order to construct your window without using a pointer though.
Also, using "new" and "delete" is discouraged in modern c++. Smart pointers like std::unique_ptr and std::shared_ptr are the preferred way if you want to dynamically create objects.

Code (cpp) Select Expand

void Game::initializeWindow()

In c++, using RAII is recommended over custom initialization functions. With your code, the Game object is in an invalid state between the moment it is constructed and the moment initializeWindow() is called. The principle of RAII is to put the code you have inside initializeWindow into the constructor of the Game object, so that it is in a valid state as soon as it is created and remains in a valid state for as long as the Game object exists (by not having a custom destroy function but putting cleanup code into the destructor).

It's a lot to process, but c++ isn't the most simple language to learn. And since TGUI quite heavily relies on modern c++, you might need to learn quite some things in order to properly use TGUI.

This is unrelated to TGUI, this is something that SFML deals with. I've seen such questions pop up a few time on the SFML forum, so I'm sure you will find some information there. I have no experience with retina displays and only very limited experience with mac, so I can't help with this.

No, such widget doesn't exist yet. It is currently probably the most requested widget, but it is a lot of work to implement it, so it shouldn't be expected soon (unless someone else decides to write it).

Would it be possible to let the background image scale, but leave all the other widgets alone?

It is possible. When you don't call gui.setView when resizing then you don't have any control about how it stretches when the window becomes larger. But if you change the view while resizing, you have full control over the size of widgets. What you want is to give the background picture the same size as the window no matter what size the window is. So instead of specifying a size in pixels, you should just set a relative size.

Code (cpp) Select Expand

auto pic = tgui::Picture::create("../RedBackground.jpg");
pic->setSize("100%", "100%");
gui.add(pic);

is there a way to clear the window WHILE resizing, so we don't see the widgets temporarily stretch before snapping back into aspect?

This would be difficult (doable, but tricky). You should first understand why it stretches while resizing and only corrects itself when you stop resizing. On windows (and NOT on linux, probably also not on mac), there will always be a resize event in the event queue while resizing. This means that the window.pollEvent function will never return false during a resize. With typical code that first handles all events and then does the drawing, the window is never drawn during the resize and windows just stretches the last drawn frame. How the window looks between the moment you resize it and the moment you redraw it also depends on the OS, on windows it just seems to stretch the image.
If you run the same code on linux, it wouldn't stretch during a resize as the draw code is regularly executed while resizing and the view is thus correctly updated the whole time. So not only would fixing it on windows require some hacky method that involves rendering the screen while there are still unprocessed events, you would also have to take care not to break the code on other platforms (if you would care about running it on a non-windows machine).
Of course if you only want to clear the screen and not actually draw contents during the resize AND it only needs to run on windows, you could get away with a much more simple hack. Every time you pass through the draw code, set a boolean to true. When you receive a resize event and the boolean is true, set it to false and call both window.clear() and window.display(). That should ensure that the window is empty during the resize.

There currently is no easy way.
I could perhaps add RightMousePressed, RightMouseReleased and RightClicked callbacks to ClickableWidget though.