Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - texus

Pages: 1 [2] 3 4 ... 99
Help requests / Re: Using canvas
« on: 28 September 2019, 10:35:50 »
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?

Help requests / Re: Get a widget
« on: 25 September 2019, 22:28:49 »
When you add a widget to the gui, you can optionally pass it a name.
gui.add(widget, "UniqueName");

Passing that name to the get function will return the widget:
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:
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:
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->"

Feature requests / Re: Visual Studio warnings
« on: 19 September 2019, 19:19:08 »
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.

Help requests / Re: OOP and TGUI
« on: 17 September 2019, 22:35:28 »
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:
MyFrame::MyFrame(int argc, char* argv[]) :
    window(sf::VideoMode(800, 600), "TGUI window"),

Feature requests / Re: Add table widget
« on: 16 September 2019, 19:49:19 »
I made setItemColor virtual now.

Feature requests / Re: Add table widget
« on: 16 September 2019, 19:13:15 »
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?

Feature requests / Re: Missing .pdb files
« on: 16 September 2019, 19:09:30 »
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.

Help requests / Re: Converting TGUI 0.6 project to TGUI 0.8.5
« on: 16 September 2019, 08:26:15 »
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.
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.

Help requests / Re: Converting TGUI 0.6 project to TGUI 0.8.5
« on: 15 September 2019, 19:54:31 »
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.

Help requests / Re: Converting TGUI 0.6 project to TGUI 0.8.5
« on: 15 September 2019, 18:06:16 »
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.

Help requests / Re: Converting TGUI 0.6 project to TGUI 0.8.5
« on: 15 September 2019, 16:30:39 »
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.

Help requests / Re: Converting TGUI 0.6 project to TGUI 0.8.5
« on: 15 September 2019, 15:41:03 »
How do you change the target platform? Maybe I can try that here too. Although I don't think it should make a difference.

Could you send me the vcxproj file so that I can check if the settings match mine?

You could check if the errors are gone if you replace "= default;" with "{}"

Help requests / Re: Converting TGUI 0.6 project to TGUI 0.8.5
« on: 15 September 2019, 15:15:54 »
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 (

Feature requests / Re: Add table widget
« on: 14 September 2019, 19:51:27 »
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.

Feature requests / Re: Add table widget
« on: 14 September 2019, 19:03:32 »
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.

Pages: 1 [2] 3 4 ... 99