Messages

1) Try using the latest github version. What you are describing was the cause of the issue that you had with menu bar in vertical layout. I said back then that I had fixed it but I found out later that I made another mistake, so the real fix was made less than 2 weeks ago.

2) Radio buttons aren't supposed to be unchecked, they are for selecting one option out of several radio buttons. You need the CheckBox class for boxes that you can freely check and uncheck.

It doesn't crash here so maybe rebuilding is the best thing to do.
What compiler were you using btw? Where both SFML and TGUI downloaded for that exact compiler?

The make_shared function shouldn't crash, it just creates an object. It would mean that the following code would crash as well:

Code (cpp) Select Expand

tgui::Panel panel;

TGUI 0.7-dev stopped using the create function over a year ago already (while 0.7.0 was only released april this year) so you are updating from a rather old version. I actually reintroduced these create functions in 0.8-dev after I realized they were nicer to work with, but if you would start using that version then you would have similar kind of issues next year.

Is the example code itself crashing? If not, could you provide a minimal code example that does crash?

I overestimated the spare time that I would have and underestimated the amount of work that this would be. Apparently it requires more changes than just a few lines in the draw function.

Both this change and the addition of setCaretPosition in TextBox also require changes in part of the code that has changed from 0.7 to 0.8 which makes it even more work to implement.

I have added both things on the todo list but they, or any other new features, should not be expected anywhere soon.

Ok, that is a valid use case.
For edit box a setCaretPosition apparently already exists but without a corresponding getCaretPosition function.
For TextBox I would probably add a setCaretPosition function that take sf::Vector2<std::size_t> as parameter since that is what is being used internally as well.
I just realized that there might be a problem with specifying which line of the textbox to put the caret to though. Due to word-wrap the line in text box may not correspond with the amount of newlines in the text.

Since I don't have time to implement auto, left and right in the near future, I'm just going to add a boolean flag in 0.7 to add support for having it at the bottom. I will implement it like you suggested in 0.8 when I have more time.

[ListBox]

ListBox
The ListBox has been requested a few times already with various requirements.
Such a multi-column listbox / table hasn't been added yet because it is very hard to create. It also has to remain simple to use while still supporting all the features that people want (some want lines between the items, some want the items to still be selectable, ...).

I hope to have it in the future but I already have little time to work on the gui so such big widget is likely to keep getting delayed until someone else writes it.


TextBox
Could you clarify why you need to be able to set and get the caret position, and more importantly how you expect to be using these functions? I don't immediately see a use case for them because how would you know at which position you need the caret?

The getLinesCount function should be straightforward to add, but other than perhaps checking it the text box is full, is there a particular reason why you need such a function?


EditBox
There are no lines in edit box and for setCaretPos and getCaretPos I have the same question as for TextBox.

0) This should be fixed now in the latest version.
1) I'm going to leave this, it would be too complicated to change. These classes simply weren't made for this.

The MenuBar being partly behind the TextBox is a bit tricky to solve. The gui doesn't discriminate between widgets, the last widget added (or the last one that explicitly called the moveToFront function) is always the one on top. I could work around this by calling the function myself on a mouse click (like I do for child windows), but it will mean that you won't be able to intentionally put widgets on top of it (e.g. having a button on the right side of the bar). Making the list a separate widget and solve the problem like I did with ComboBox is not an option right now because ListBox doesn't support textures for each item yet and it would make it harder to expand the menu bar to have submenus in the future. So I'm going to leave it as it is for now.

2) Not really an issue since EditBox doesn't support multi-line text
3) This could be seen as a missing feature. The MenuBar assumes that it is on top, maybe a flag could be added in the future about whether the menus should be below or above the bar.
4) I didn't get the difference between this and #3?
5) Same remark as in #2, not considered an issue

I'll add the boolean flag for #3 on my todo list. It should be a simple addition, maybe if I have more time today I'll add it but otherwise it might take a while before it gets added.

I'll have a look at these things, but here is a quick reply on the things you mentioned (I haven't looked at the video or code yet)
0) Holding LMB shouldn't be needed, this sounds like a bug
1) HorizontalLayout and VerticalLayout weren't created by me and may not work for everything, but they are meant for e.g. placing buttons next or below each other, not for complex widgets like a menu bar
2) I'll have a look at it
3) MenuBar widget assumes that it is always on top of the window
4) Probably same remark as 3
5) EditBox is single line and doesn't support newlines. TextBox is for multiple lines of text.

Thanks for such a detailed bug report btw.

I can't reproduce this (with the DejaVuSans font).
Could you write minimal code (a main function that I can just copy-paste and run) and attach the font you are using?

Changing the text alignment of a button is currently not possibe.

The Label class however supports text alignment, so depending on what you need you could use a Label for it.

Only one of the 2 should do "255-value" while the other should still set "value". Otherwise you are endlessly inverting the values.

TGUI 0.6 and 0.7 are not compatible.
If you have code written in 0.6 then you should keep using 0.6 unless you want to rewrite the tgui related code.
If you are starting a new project then you should use 0.7.

Why would you need a combo box with so many items?
I can't imagine it to be practical if a user has to select something from such a long list.

The ListBox is indeed not optimized for many items (and ComboBox uses the ListBox internally). I could try to optimize it if necessary.

Could you send me the .vcxproj file of your project (e.g. attach it to your forum post)?

Perhaps you are still linking to the release libraries of SFML or TGUI?

You shouldn't have to draw them manually.
If you add them to the gui with gui.add then they will be drawn automatically when calling gui.draw().

With your current code the m_gui.getWidgets()[ i ] is of type Widget::Ptr so you will need to cast it to a ProgressBar::Ptr to call functions of the progress bar. Since these types are just a typedefs for std::shared_ptr, you can use std::dynamic_pointer_cast to cast them:

Code (cpp) Select Expand

std::dynamic_pointer_cast<tgui::ProgressBar>(m_gui.getWidgets()[i])->setValue(...));

The code that you show might give some problems later on though. The code only functions as long as m_gui.getWidgets() and m_eRPG->m_lavie.size() have the same size which means that if you want to use anything from the gui other than health bars for the characters then you get into trouble.

I would suggest that you store the progress bars yourself. The first way would be to have a ProgressBar::Ptr member in m_eRPG->m_lavie. That way you can loop over the the m_eRPG->m_lavie every frame and just do m_eRPG->m_lavie[ i ]->progressBar->setPosition(...). This may however not be good design if you want to keep the gui seperate from your entities. So a second way would simply to hold a std::vector<tgui::ProgressBar::Ptr> somewhere. In the first code snippet you would add progressBarVector.push_back(progressBar) while in the second code snippet you would loop over this progressBarVector instead of over all widgets which allows you to even call setValue directly (as you don't have to cast).

Edit: I just noticed that you are already using the gui for other things than progress bars. Are you using multiple Gui objects perhaps?

This is indeed an SFML bug, fullscreen windows in SFML seems to be pretty broken on linux.
https://en.sfml-dev.org/forums/index.php?topic=20482
https://github.com/SFML/SFML/issues/921

Replacing line 504 in src/SFML/Window/Unix/WindowImplX11.cpp from "if ((!m_fullscreen || (windowManagerName == "Openbox")) && !(style & Style::Resize))" to "if (!(style & Style::Resize))" seems to fix the issue for me, you should check if it fixes it for you as well.

It seems like all the functions from which the close button is used can be overridden, so it would be possible to do it with a new widget that inherits from it. However you would have to copy the implementation of many functions so you might just as well edit ChildWindow directly.

Everywhere where you find the m_closeButton in the code you probable have to change some code for the new button. I think the hardest part may be setPosition, but if you know that the text is always going to be centered then you will only have to implement one of the three title alignments.

Feel free to send me the modified code after you implemented it, I could use it to officially add support for a minimize button later.

No, unfortunately there is currently no way to make a disabled widget look different.
You will have to workaround by either having 2 widgets (one shown when disabled, the other for normal use) or by changing the colors inside the code when the widget gets disabled or enabled.

Adding options for colors and images for the disabled state shouldn't be a problem for future tgui version, it is just a lot of work (because there would have to be functions for changing background colors, text colors, background images and maybe even border colors for this extra state). But it will probably be added in 0.8-dev because the change is too big (the 0.7 branch and my private 0.8-dev branches are not compatible thus any change made in 0.7 has to be manually be made in 0.8-dev as well which would double the amount of work).

TGUI is indeed also licensed under the zlib/libpng license, like SFML.

Edit: the license doesn't even require you to mention it btw, although mentioning is appreciated.

You typically don't have to do that with codeblock's default compiler unless you are using the "MinGW Makefiles" generator instead of "CodeBlocks - MinGW Makefiles", but I'm glad to hear that you found a solution to the problem.

You could try putting TGUI in a folder which does not contain spaces (e.g. "D:/SFML/TGUI-Build/") or putting it on the C drive to see if it changes anything.

If that doesn't work then it looks like either the compiler or cmake is broken.
All commits that I push to github are automatically tested on different platforms so it is unlikely that there is a fix that I can make, it looks like something specific to your pc.

What error exactly?

If you ran cmake before in that folder then you could try deleting the cache (in cmake menu bar: File > Delete Cache).

(edit: I didn't see your image when I wrote this because my browser I was using blocked the HTTP request)