Messages

Vertical alignment was already on the todo list, I'll have a look whether it can be implemented easily or not.

Do you think it would be better to have setHorizontalAlignment and setVerticalAlignment functions each with their own enum (left, center, right) and (top, center, bottom) or would it be better to have one setAlignment function that takes an enum like the one in Grid?

Since neither sfml nor tgui 0.6 uses exceptions, I think there will be something wrong with the libraries you are linking to. Make sure that both sfml and tgui are linked either both dynamically or both statically and that you link to the release libraries in release mode and the debug libraries in debug mode. Making a mistake in one of these settings can cause random crashes like unhandled exceptions.

If you checked these settings again and you are certain that they are right then answer the following questions:
- What sfml version are you using? (not just the version number but also whether you downloaded it from sfml website or compiled yourself)
- What tgui version are you using?
- Could you attach your .vcxproj file?

The first part "[a-zA-Z]" matches with any letter, the second part "[a-zA-Z0-9]" matches with any letter or number. The "*" means that the second part can occur 0 or multiple times. So this matches any string that has letters and numbers but has no number as first character. Technically an empty string is not valid, but the editbox always accepts an empty string.
It isn't really practical, it just shows what you can do with the function.

The windows build is fine now, so you can download the latest version and build it to be able to use EditBox::Validator::Int.
At moments like these I am glad to have a CI set up for multiple operating systems so that I know relatively fast that I screwed up with a change.

I forgot to mark the validators to be exported in windows dlls. Latest github version should work now.

The square brackets define a set of valid inputs, so "[0-9]" means any character with ascii code between '0' and '9' (thus all numbers), "[a-zA-Z]" would mean all letters.

Edit: build on windows failed, I must have still done something wrong

My point is that there is no simple solution with your current code structure. If you have a short and simple code without classes and you have a problem then I can help and tell you what to change, but I can't say exactly which lines to change in such code as this.
I know solutions that could help you, but I think it would be better if you change the design now than to fix this issue and just end up with other issues later on.

Unless you have a really good reason to do so (e.g. the animated picture is to be drawn inside a tgui child window), you should NOT use tgui to draw it. You should only use tgui for what it is meant to be used: as a user interface. The rest of your code should just use sfml like you would when you aren't using tgui.

I'm not even sure where to start with correcting this, the code obviously doesn't do what you need it to.
You create an animation object, load its frames, then draw the first frame and then the function ends and the animation object is destroyed. Just like you need to do in the sfml code, you have to keep the animation object and draw it every frame.

If you can provide a simple example code inside a main function then I can correct if for you, but this code depends too much on your existing other code (e.g. the Widgets class).

But maybe you are making it way too difficult for yourself. Why even use a tgui canvas? Just use identical code as you have with sfml and have the rendering loop look like this:

Code (cpp) Select Expand

window.clear();
gui.draw();
window.draw(animatedSprite);
window.display();

What you are saying doesn't make much sense. There hasn't been such a thing as a "tgui window" since 0.5 and I doubt you are using such old version. TGUI just draws on top of the SFML window just like you would do yourself, so there is no reason why it wouldn't work.

So you probably just made a small mistake in the code, but I can only help you with that if you show the code where you use both TGUI and the AnimatedSprite.

All widgets can be created like this and it should thus be the default option when you hesitate:

Code (cpp) Select Expand

tgui::Button::Ptr button = std::make_shared<tgui::Button>();

The few widgets which don't work with themes (e.g. Picture and Panel) can also be created like that, but may provide shortcuts to make it easier (but which you don't need to know to use the widget).

Code (cpp) Select Expand

auto pic = std::make_shared<tgui::Picture>("Image.png"); // Parameters are shortcut for extra setTexture call
auto panel = std::make_shared<tgui::Panel>(400, 300); // Parameters are shortcut for extra setSize call

Only when you don't want to use the default white skin you have to create a theme and use tgui::Theme::load(). The reason some widgets can't be loaded with a theme is just because it doesn't make sense to have different skins. Panel is just a collection of widgets so having a skin doesn't has much meaning (although I might have implemented it anyway for its background color). But a widget like Picture definately wouldn't make sense to be loaded from a theme.

You forgot to pass the events to tgui. Inside the pollEvent loop you need to add this line:

Code (cpp) Select Expand

gui.handleEvent(Event);

The setInputValidator function has been added in the latest version on github.

I'll go with setInputValidator. When I add options for validation other than regexes then I can remain backwards compatible instead of having to rename the function.

The implementation is already done, I just need to write tests for it, so it should be pushed online later today.

I find setInputRule better than setTextRule, but no matter if it contains regex in the name or not you will still need to know regular expressions to use it (unless you only use the predefined regexes).
What about setValidator? Qt uses that name although the parameter is a QValidator class and not a string like here.

So currently this would be how it looks:

Code (cpp) Select Expand

//////////////////////////////////////////////////////////////////////////////////////////
/// @brief Define how the text input should look
///
/// @param regex  Valid regular expression for std::regex to match on text changes
///
/// When the regex does not match when calling the setText function then the edit box
/// contents will be cleared. When it does not match when the user types a character in the edit box,
/// then the input character is rejected.
///
//////////////////////////////////////////////////////////////////////////////////////////
void setInputRule(const std::string& regex = ".*");

You could call it like:

Code (cpp) Select Expand

editBox->setInputRule(tgui::EditBox::InputRule::Int); // using pre-defined regex
editBox->setInputRule("[-+]?[0-9]*"); // using custom regex

These regexes are a lot easier than writing check functions. For checking floating point numbers I needed to loop over all characters making sure that they could only be numbers or a dot, but there could not be more than one dot and the first character also needed an extra check because it could be + or -. With a regex I just have to provide "[-+]?[0-9]*\\.[0-9]*" as input (the only tricky thing is escaping the dot which matches any character when not escaped).

I decided to go with a string representing a regex as parameter to set how the text in the edit box should look because they can be saved and loaded from text files unlike the text rule functions.

Do you have any preference for a name of such function: setTextRule, setTextFormat, setTextRegex or do you have a better idea?

The updateWidgetPosition will only be called when widgets are changed, which isn't that frequent. I only care about performance when something is called almost every frame, but this function is only called a lot while creating the table (while adding the rows). The setPosition and setSize functions of widgets will become very light operations in the near future so the function won't be that heavy.

The Table class on my bitbucket looks finished at first sight. So you don't really have to resolve anything unless you find things that are still missing. It juststill has to be extensively tested.

Did you already found some time to look at my version?

Alignment has been added to the label class.

Code (cpp) Select Expand

label->setAlignment(tgui::Label::Alignment::Center);

I looked into the caret issue and it isn't as simple as I hoped.

Number 4 was not really an oversight, the CaretWidth was deliberately missing because it was a property of the editbox itself and not of the renderer. But when thinking about it, it makes sense to put it in the renderer. So in the latest version you can use that propery. This however means that the editBox->setCaretWidth(x) will become deprecated and will eventually be removed so that you would have to call editBox->getRenderer()->setCaretWidth(x) instead.

The conclusion from number 3 was unfortunately wrong. Just try to set the caret width to a rediculous high value like 20 or even higher and you will immediately see what the problem is: the text is placed against the right side of the editbox (minus the reserved padding space), there is no more space for the right half of the caret. I also can't disable the clipping for the caret because if it is too width then part of it could be be drawn outside of the edit box. Maybe the text of the caret should still be placed one or two extra pixels to the left to be absolutely correct but I will look into that when rewriting the renderers.

I once started writing this but I never finished it. It is planned to be added in the future, but nowhere soon.
If you only need it on windows then you can simply use some windows api calls, but if your program has to be cross-platform then it is going to be more complicated. Using wxWidgets might be possible, but it might not work out of the box together with sfml. Using it with tgui won't be a problem once you have it working with sfml.

I always take my time, it's not like I'm going to skip studying. But when I work on tgui small tasks are given priority, so whenever some small changes like these are requested they will always be done soon. If you would ask something like this during the holidays then it is probably finished on the same day.

The project indeed seems to make heavy use of tgui.

When replacing the edit boxes by labels in that scenario you have fixed-size labels (with size of current edit box) which indeed require the alignment to be inside the label class itself.
All 5 points in your original post will be fixed/added somewhere this month, but since I have exams until the 21st it is hard to say if it will be done during the next few days or by the end of the month.

This can be done with layouts like this:

Code (cpp) Select Expand

label->setPosition(tgui::bindLeft(editBox) + (tgui::bindWidth(editBox) - tgui::bindWidth(label)) / 2.f, top);

The bind functions will cause the expression to be recalculating when the value they contain changes. So if you change the x position of the edit box or the width of the edit box or label then the layout system will automatically call label->setPosition with the new value. So changing the text of the label will cause it to be repositioned like you want.

Maybe you can just add a function to the tgui::TextBox:
void setTextRule(std::unique_ptr<TextRule> rule)
The TextRule class would have a virtual bool check(std::string textEntered) function

I'd probably just let you pass a function like this:

Code (cpp) Select Expand

void setTextRule(std::function<bool(const std::string&)> checkFunction)

But I think the rules only make sense for an EditBox, do you really need it for the multi-line TextBox?

I'll consider this at the end of the month, after my exams.

and why not too a description of the expected value (used for the tooltip)? ...And the possibility to put a messageBox with this description when the user enter a bad value.

These things are becoming too specific to a specific application and will most likely not be added. It isn't even possible for the text box to know what the expected value is. And they are easy to add in user code (e.g. open message box inside the check function).

1-4 shouldn't be that hard to solve. I'll look into them when I have some time.
The 5th one requires me to render each lines seperately in label because the entire text is currently drawn with a single sf::Text object. But my word wrap algorithm can remain the same, so this won't be that much work.

I am assuming that the label has a fixed width. If you are auto-sizing (size of label determined by the text in it which is what you have when you don't call setSize), then alignment makes no sense in my code because the entire width is always filled. It is however easily solved in your code in this situation with layouts. If you want to align a single line of text to the right then you can use the following code (I'm also positioning the label direct above the edit box with 2 pixels in between).

Code (cpp) Select Expand

label->setPosition(tgui::bindRight(editBox) - tgui::bindWidth(label), tgui::bindTop(editBox) - tgui::bindHeight(label) - 2);

They are in the documentation, they are just spread over multiple places and are a bit hard to find.
The detailed description of the widget always tells you which signals are available in that class, but you would have to go check the base classes as well.
So in the description of Button you find a link to ClickableWidget of which the detailed description contains more signals and a link to the Widget class which contains the signals that all widgets share.

You are using SFML 2.3.2 procompiled libraries from the sfml website, right?
Then I have no more ideas on why it wouldn't work for you.

You could still try to remove everything of tgui from your pc (including the dlls in your project if you are linking dynamically), download the source code and build it yourself with cmake.

The only other thing you could do is start using v0.7-dev which is so different that the same issue can't happen. But that means that you have to rewrite the code that you already have.