Messages

Actually putting those variables in the header isn't a good solution (I'm not even sure why it would work).
When I told you to use "=", I wasn't really looking at your code. The EraserON and Hue values probably still need to be passed as references to the lambda, by using "=" instead of "&" you are making copies of them and you would be changing a local variable inside the lambda instead of the variable that you had outside. You might want to look up how lambdas work, but the "=" and "&" are just the defaults for the variables. To pass some variables by value and some by reference you would do something like

Code (cpp) Select Expand

slider->connect("ValueChanged", [&,slider]() { Hue = slider->getValue(); }); // All variables passed by reference except slider
or

Code (cpp) Select Expand

slider->connect("ValueChanged", [=,&Hue]() { Hue = slider->getValue(); }); // All variables passed by value except Hue

When you choose a tool then the button stays pressed.
When u choose another tool then this button stays pressed and the previous goes back to unpressed.
I dont know if BitmapButton is the right choice here.

You might want to use RadioButton widgets for this. The downside is that the RadioButton places its text next to the image, so if you need text on top of the button then you would have to add a Label in front of it manually on which you call isIgnoringMouseEvents() to make sure clicks on the label are passed to the button instead of absorbed by the label. I'm not sure if there are better options, but if you don't need any text then what you need definitely sounds like how radio buttons work.

Is the issue resolved when changing the "&" to "=" in the BBTN_Erase->connect line?
You are currently storing a reference in that lambda. If the BBTN_Erase variable goes out of scope (so at the end of the function that contains the code you showed) then this reference will become invalid. This would cause a crash when trying to use the variable when the lambda function is being executed.
The Widget::Ptr is a pointer, so it can be passed by value without having to worry about performance with copying it.

It is impossible for a program to know what variable name you used, the compiler just translates it to an address in memory, so you do need to pass the string yourself

Code (cpp) Select Expand

gui.add(BBTN_Erase, "BBTN_Erase");

Check if BBTN_Erase is a nullptr when calling BBTN_Erase->setImage. If it is then it means no widget was added to the gui with name "BTTN_Erase".
Are you passing that string as second argument to gui.add?

PDB files have been added in TGUI 0.8.6

The gui builder shouldn't have different behavior.
However, the widget files created by the gui builder embed the theme in them, so they don't read the theme file when loading them. Maybe you had a changed theme file at the moment you generated the widgets file with the gui builder or at the moment you opened the gui builder? You can check this by seeing if the form file contains the "Smooth" or not, it doesn't contain it by default (since the properties are copied from the theme files which don't have it).

Can you try adding "Smooth" behind the texture in the theme file?
So the lines in the Button section in BabyBlue.txt should look like this:

Code (ini) Select Expand

Texture = "BabyBlue.png" Part(269, 40, 90, 60) Middle(30, 0, 30, 60) Smooth;

I never really saw any difference between enabling smoothing on textures before so I just kept the default (which is false in sf::Texture).
Although I can't reproduce the way it looks for you, when zooming in on the button I can see a difference between non-smoothed and smoothed here, so this looks like it might solve your problem.

It gives the exception because you are missing a semi-colon behind "ShowTextOnTitleButtons = true".
The parser sees "true CloseButton=&Button" as the value of ShowTextOnTitleButtons, which it considers invalid since it contains an unquoted '=' sign.

So basically the question is what to do in setSelectedItems when setMultiSelect wasn't called yet (or when it was set to false again).

I wanted to look up how other libraries did it and I noticed that in .NET the selected items is a read-only property. Maybe we don't need to have a setSelectedItems at all?
If you do add the function then you can choose what it does, as long as the behavior is documented. When I said that the mode should not be changed automatically I wasn't thinking about a scenario like this, enabling multiselect when calling setSelectedItems with more than one item would be a valid solution. But unless someone has a need for the function maybe it would be better to just not have a setSelectedItems function.

1. For now we can just keep the deselectItem function. I'd have to review that in the future where I would probably rename it to "deselectItems" or just "deselect", but for now we can just keep the existing "deselectItem" function which will deselect all items.

2. I'm not sure what you mean. If multiselect is true, the user should be able to select multiple items (by having ctrl and/or shift pressed when clicking). If multiselect is false then the user can only select one item at a time and the ctrl and shift keys are ignored. The mode should never be changed automatically.

std::set seems like a better option, for the setSelectedItems/getSelectedItemIndices functions as well. Then you don't have to worry about sorting or having the same index twice.

It would be a nice addition, but you will have to implement this yourself too if you want it, I'm too busy playing video games right now

After briefly thinking about it, I guess for the API it should be enough to add the following 4 functions (with the MultiSelect boolean propery being false by default).

Code (cpp) Select Expand

void setSelectedItems(const std::vector<std::size_t>& indices);
std::vector<std::size_t> getSelectedItemIndices() const;
void setMultiSelect(bool multiSelect);
bool getMultiSelect() const;

The "tgui-git" package downloads directly from github, so updating that package always gives the latest github version.

I didn't test to make sure that it actually works, but I have added a setView function (and getters) to the Canvas class in the latest version on github.

It currently doesn't has a view. But I could add it as the class is a wrapper around sf::RenderTexture which does seem to have a view. What are you trying to do exactly?

When you add a widget to the gui, you can optionally pass it a name.

Code (cpp) Select Expand

gui.add(widget, "UniqueName");

Passing that name to the get function will return the widget:

Code (cpp) Select Expand

tgui::Widget::Ptr widget = gui.get("UniqueName");

The normal get function returns a pointer to the Widget class, which is the base class for all widgets. Often you need access to the functions of a derived type (e.g. for setting the text of a button), in which case you need to cast it:

Code (cpp) Select Expand

tgui::Button::Ptr button = widget->cast<tgui::Button>();

There is however also a get function that does both of these operations at once: it retrieves the widget by its name and casts it to the right type. It is called like this:

Code (cpp) Select Expand

tgui::Button::Ptr button = gui.get<tgui::Button>("UniqueName");

Obviously, the widget with name "UniqueName" has to be a Button, if it was e.g. an EditBox then it might fail.
(I'm not sure if I made any guarantees about what would happen. Right now I believe it will just return a nullptr, but it is possible that it could change to e.g. assert in the future. So just don't use the wrong type.)

The same holds for any container widget. If you have a Group, Panel, ChildWindow or any other widget that inherits from the Container class then you can use the get functions on them too, just replace the "gui." in the examples above with "container->"

I am aware that VS gives some warnings, this will often be the case. Occasionally I do fix those VS warnings (usually right before I release a new patch version), but because I work on linux with gcc I only see the warnings given by gcc. If a warning is serious then it is likely that gcc will also the warning, so the warnings that do occur are usually about int/float or signed/unsigned mismatches. I do care about these things, I wish that gcc showed them too in which case I would fix them immediately, but I'm not going to constantly check the windows logs just to see if there is any minor warning.

I also rely on unit tests to find code issues. I've had windows tests failing on multiple occasions while everything passed on linux, but I have never encountered any bug that got through those tests but would have been fixed if I had gotten these few extra warnings. This is why I consider them mostly harmless. That being said, I do prefer it if my projects build without any warnings at all on all compilers, even if the warnings aren't important, so I will probably fix them this weekend or so unless someone sends a PR before that time. (The one in CopiedPtr.hpp isn't going to be fixed, it is a false positive and it also isn't part of TGUI but part of the external Aurora library)

It has been longer than usual since the last patch release, which is also why it is longer than usual since I built with VS.

I don't do it because i don't want to complicate the code. It doesn't add much complexity, but I feel like the minimal examples should be as straightforward as possible: just a main function with the minimum required code in them. By adding classes you are adding stuff to the code that is irrelevant to the example.

I'm not against OOP for larger examples, but for the really simple examples I don't really feel that it is needed.

It might be a good idea to have at least one example with a class though, it could be useful to demonstrate how to initialize the gui in a class and how to connect member functions. These are cases that people likely face but are currently not covered in the examples.

Calling setTarget is one way to do it, but even in a class you can still use the constructor by using the initializer list:

Code (cpp) Select Expand

MyFrame::MyFrame(int argc, char* argv[]) :
    window(sf::VideoMode(800, 600), "TGUI window"),
    gui(window)
{

I made setItemColor virtual now.

Isn't making just setItemColor virtual enough, as the other will just call that function? Or do you have something that needs to be changed in these functions as well?

I'll look into it in the near future. The next TGUI build is likely to happen on a completely different PC anyway so I'll make the changes to copy the pdb files with the library then.

std::ref doesn't cause any issues, it is only with std::bind where you need to either change your code or update to the github version.

The code isn't really crashing, it is throwing a tgui::Exception that you don't catch which tells you that there is no "clicked" event in ListBox.

Also, these bound parameters might not do what you want it to do. You are getting the selected item at the time of calling the connect function, so when the callback happens these parameters will always be the same. You should just leave a parameter unbound if you want TGUI to fill it in with the actually selected item.

Code (cpp) Select Expand

void PlaylistClicked1(tgui::Gui& gui, int selectItem) { } // Only supported with version from github
void PlaylistClicked2(tgui::Gui& gui, sf::String str_ItemText) { }
void PlaylistClicked3(tgui::Gui& gui, sf::String str_ItemText, sf::String str_ItemId) { }
listBox->connect("ItemSelected", PlaylistClicked1, std::ref(gui));
listBox->connect("ItemSelected", PlaylistClicked2, std::ref(gui));
listBox->connect("ItemSelected", PlaylistClicked3, std::ref(gui));

In the github version you can replace "ItemSelected" with tgui::Signals::ListBox::ItemSelected. With autocomplete, this way you could get hints about what signals exist.

Th error mentions "std::_Binder", are you by any chance passing a parameter with std::bind to the connect function? TGUI 0.8.5 doesn't support that yet, so if you are using std::bind then that could be the cause for the error. The TGUI version on github does support std::bind.

Maybe you should try reinstalling the compiler and maybe even visual studio? Having the compiler crash isn't normal.
Instead of replacing the "= default" you could also try to remove the "TGUI_CONSTEXPR" from those lines.

Does it still give the error you just have an empty cpp file (that includes TGUI of course)? I really can't figure out why it won't work. I updated to VS v16.2.5 as well and downgraded TGUI to 0.8.5 and it just keeps working here. I didn't try changing the SDK version but that shouldn't be needed as it doesn't work with the windows 10 sdk for you either.

You should try my earlier suggestion of replacing "= default;" with "{}" in those 2 headers and let me know if that fixes it.