Messages

The bug is now fixed, knowing that it happened at the end of a paragraph was enough to reproduce it here and thus quickly find the issue.

Inside tgui only '\n' is used so this was not related to windows. The problem happened because the contents of the line contains '\n' at the end. While you see e.g. 5 characters on the screen, the line will contain 6 characters because it also contains the newline. The caret is at position 5 and when pressing the right arrow key the code just checked if it was at the end of the line (which it isn't technically) and move it forward. The problem was solved by skipping the '\n' at the end of the line.

When caret stays in the last position of the current line, and when I press Right Cursor key, the caret moves to the first position of the same CURRENT line, but NOT of the NEXT line (as it needs).

Could you show some code that reproduces this issue? It may be specific to the combination of your text and textbox size because I can't reproduce this.

I understood from docs I am free to try to correct the source code of Tgui's TextBox for my app?

Sure, you can perfectly inherit from it and override some functions.
You are even allowed to make changes in the tgui source directly, but that would make it harder to ship the program or to update tgui of course.

Changing the protected members directly can indeed cause the text box to malfunction, you would basically have to know how things work internally and things might break on future changes. Public functions should be used as much as possible because they have a guarantee to work correctly (if they don't then the code is badly designed or it is a bug in tgui).

But you can also read the variables without problems so it should be possible to implement the changes. When inheriting from TextBox there are only a few members that you need to access. The m_lines variable contains the lines of text in the text box, m_selStart and m_selEnd are (x,y) pairs containing the amount of letters on the line before the caret and the line nr. The m_topLine and m_visibleLines can be used to find out which part is visible. You would only have to set the m_selStart and m_selEnd to the place where you want the caret to be and then call either rearrangeText or updateSelectionTexts to let my code fix the other variables. But you might have to experiment a bit because even I don't know exactly what every function or variable does.

The rearrangeText and updateSelectionTexts are still private, but by the time you read this I will have made them protected so if you update the the latest v0.7-dev version then you should be able to call these functions from a derived class.

Except for the double-click and the furl the changes should be relatively easy. The furl is actually already partly implemented in the code. There are two blocks commented out, the one at line 1276 being the problematic part. I doubt that you would be willing to rewrite the rearrangeText, but technically that is the place where the change has to be made to support it.

If you implement the things that you want then feel free to send me the code so that I can perhaps add it to tgui. I simply don't have the time to write everything myself anymore.

The TextBox that is in tgui 0.6 hasn't changed a lot since it was first written in 0.4 so it has a lot of limitations. You should consider upgrading to v0.7-dev where the text box has been completely rewritten. The performance was improved drastically and it has word wrap. You can't choose how it wraps though, it will always split on words (unless of course the entire word is longer than the width then it has to be split somewhere).

And is it bug may be? When caret stays in the last position of the current line, and when I press Right Cursor key, the caret moves to the first position of the same CURRENT line, but NOT of the NEXT line (as it needs).

This sounds like a bug. I'll look into it.

The other things can't be done with tgui. Both the double click one and the furl where on my todo list but they are not that easy to do.
I don't have time now, so I look at it this evening whether there is a way that you could do these things from inside your own code.

A fix has been made, you can download the new version from the master branch on github. You have to compile the library yourself with cmake, there are tutorials for this on my site.

I think I already know what the problem is, I'll see if it can be solved easily.

You can call gui.add(box).

I know that there may be some font related problems in certain situations when doing this, but I think I have fixed the most common ones. But it is still advised to add it to the gui before setting properties like its text and text size. The widget is only given a font at the moment it is added to the gui (which is normally immediately at creation) so some text related function might do nothing when no font has been set yet. But it might work to call gui.add after all the other function, I just don't guarantee that it will in tgui 0.6.

No, tgui doesn't support that yet.

That setting the text size doesn't change the labels is a bug, I cached a little bit too much it seems. Fixed in the latest version.

But I'm not sure what you are referring to with the first part of your post.

What you are doing is call setPlayerNation and pass the return value of the function (void in this case) as parameter to the connect function.

It should be like this (assuming mapManager is an object of type MapManager)

Code (cpp) Select Expand

countryPicture->connect("pressed", &MapManager::setPlayerNation, mapManager);

Since the function takes an int you actually have to do this:

Code (cpp) Select Expand

countryPicture->connect("pressed", &MapManager::setPlayerNation, mapManager, mapManager->getNation(i));

But this will call getNation immediately and call setPlayerNation with a copy of that int. So if the nation changes after calling the connect function then the value passed as parameter isn't changed. So instead you could bind that function call so that getNation gets called when the setPlayerNation is being called.

Code (cpp) Select Expand

countryPicture->connect("pressed", &MapManager::setPlayerNation, mapManager, std::bind(&MapManager::getNation, mapManager, i));

You should read the "Connecting member functions" section on this page for a good explanation on how to bind member functions.

You might also want to look up how std::bind works. If you hesitate how the parameters of the connect function are supposed to be, all the parameters after the first string are just directly passed to std::bind so if you know how it works then you also know what to pass to the connect function. With the exception that you can pass less parameters to the connect function which leads to trying to bind them internally.

my tabs seem to have the wrong text size

The tab class has gone through several internal changes in the last year. If you can't figure out the problem yourself then you should try to provide some minimal code that has this problem.

Since 'widget' is an uninitialized pointer before the static create function creates one, you are indeed calling a function on a nullptr. This is undefined behavior and normally leads to an immediate crash. But it seems that since the create function doesn't access any member variables it doesn't access this nullptr so it silently works (but it crashes later on in this case since it doesn't initializes the widget, it just returns a newly created one).

Yeah, I made a typo. It shouldn't print "e", but "e.what()".
Perhaps change "tgui::Exception" into "std::exception" to catch any exception since I don't think the add function throws any tgui exceptions.

Edit: Are you sure you aren't passing a nullptr to gui.add?

No, but you should just try to debug it and see on which line it returns exactly.

Edit: Possibly because tgui couldn't find something. TGUI v0.7-dev uses exceptions for error handling, you should try putting a try-catch block around your code in main like this. Normally you see the contents of the exception in your terminal when you don't put any try-catch, but perhaps it isn't printing it on certain systems.

Code (cpp) Select Expand

int main()
{
    try {
        /* code */
    }
    catch (tgui::Exception& e) {
        std::cerr << "Exception caught: " << e << std::endl;
    }
}

is there an actual tutorial on the new callbacks?

Yep, all v0.7-dev tuturials can be found here (although there currently aren't many tutorials).
The tutorial for the callback system is split in three parts:
Introduction to signals
Unbound parameters in signals (limited compiler support)
connectEx function (alternative to unbound parameters)

The new loading system uses theme classes. So you first have to create a Theme object and then use that to load your widget. This allows widgets to be connected by the theme to easily make changes that appear on all widgets or even completely reload all the widgets with a different skin.

Code (cpp) Select Expand

tgui::Theme::Ptr theme = tgui::Theme::create("TGUI/widgets/Black.txt");
tgui::Button::Ptr button = theme->load("Button");
gui.add(button);

There is at least one big breaking change still coming in v0.7-dev, the whole loading system is being rewritten. So if you wait on that you only have to change your code once instead of twice. But it is hard to foresee how long it will take before the change is finished (currently expected to be finished before the end of this month).

If I change widgets then the changes are usually pretty small, so the operations you do on the widgets probably won't have to change much. The way you create the widget and add it to the gui however is something that is very different in 0.7 (and will be different once more after the new loading system is done), so this requires changing every widget. Also the entire callback system is different in v0.7-dev as well (so all bindCallback lines have to be changed and callbacks can't be polled anymore).

I only have short-term plans (the changes I want to make up till v0.7-alpha), so I don't even know myself which changes will be made between alpha and final release. So technically many more breaking changes might be made before reaching beta phase (it is only after this point that I start actively recommending tgui 0.7 over 0.6). Although I doubt there will be many really big changes after this new loading system is done.

So changing to v0.7-dev might take some effort, you should decide for yourself if the new features in 0.7-dev are worth the effort. A better textbox and a tooltip class are just a few of the many small improvements.

The TextBox is indeed way too slow in tgui 0.6.
Rewriting the class was one of the first things I did in tgui 0.7-dev, the performance problems should be solved there.

I once wrote this on my blog, to give you an idea how much better it is now:

I am almost done with rewriting TextBox, so it is time to do some performance tests. The new code is 1000 lines shorter (1600 instead of 2600), supports word wrap and fixes all performance problems.

With 100.000 characters, there was still no visible delay when inserting text (but the fps dropped to 30 while typing). Going over 250.000 characters started showing visible performance issues.

So in normal situations (a few hundreds or even thousands of characters) you should have absolutely no performance problems.

Just as a comparison: the old TextBox didn't handle more than 500 characters very well.

You can't get access to the texture from the widget directly.

You could get it through the texture manager, but you will have to know the filename of the texture. So this method works if you want access to a specific texture, but can't be used to get the same texture as a widget without knowing what it was loaded with. The "(0, 0, 300, 25)" in this code is the part of the image to load, in this case the child window title bar.

Code (cpp) Select Expand

tgui::Texture temp;
tgui::TGUI_TextureManager.getTexture("TGUI/widgets/Black.conf", temp, sf::IntRect(0, 0, 300, 25));
sf::Texture& texture = temp.data->texture; // you can assign this to a sprite
sf::Sprite& sprite = temp.sprite; // or just use the sprite that already exists

(you will actually have to store the 'temp' variable, because you have to call tgui::TGUI_TextureManager.removeTexture(temp) to release the texture again, otherwise you will create a memory leak)

The only advantage you get from using the above code instead of the following is that the texture manager will reuse the same texture if it was already loaded.

Code (cpp) Select Expand

sf::Texture texture;
texture.loadFromFile("TGUI/widgets/Black.conf", sf::IntRect(0, 0, 300, 25));
sf::Sprite sprite(texture);

But why would you want to access the textures that the widgets use?

Yeah, the bindCallback function adds callback functions, addCallbackFunction would perhaps have been a better name. Adding instead of replacing the existing one allows multiple callback functions to be bound for the same callback.

Instead of unbindAllCallback you can also do unbindCallback(tgui::Button::LeftMouseClicked), this doesn't clear callback functions that were bound to other triggers. But in your code it probably doesn't matter since you only use LeftMouseClicked.

For RadioButtons, you could use the Checked event instead of LeftMouseClicked, unless you need a callback again when clicking on a radio button that was already checked.

Sorry for my answer comes over a bit harsh, I had written a slightly longer version but I accidentally refreshed the page and I lost it.

I won't be adding a clear function, I don't see any use case for it. You shouldn't be clearing the list since you throw away callbacks like that without even checking what they are. But if you really need to clear it then you should just keep the while loop that you have now.

The callback is removed before the pollCallback returns, so if there are callbacks left in the queue when you jump out of the loop then there must have been multiple to begin with. Are you sure you didn't accidentally give the other radio buttons the same id? Are you binding multiple triggers on the radio button? Perhaps you let it send a callback on both clicked and mouse pressed but only handle one while the other still remains in the queue?

I found some time to do it already, so if you download the master branch from github then you will be able to put the different buttons in the same file by giving them different section names and loading them like this:

Code (cpp) Select Expand

button->load("ThemeFile.txt", "MyButton");

callback.id contains the number that you can change with childWindow->setCallbackId. What you need is callback.trigger which will equal the tgui::ChildWindow::Closed.

TGUI 0.6 is limited to one button per file. You would need to use a different config file for each button.

Maybe I could give the load function an extra parameter to specify the section name. I'll look into that next week.

Every widget can have exactly one id so that you can see from which widget the callback came. Calling setCallbackId will just change the current id so in your code example the widget will use id 2 for both callbacks.

In the callback loop you should just check the trigger like this:

Code (cpp) Select Expand

while (gui.pollCallback(callback))
{
    if (callback.id == /* id of the widget */) {
        if (callback.trigger == tgui::Button::LeftMouseClicked) {
            // Widget was clicked
        }
        else if (callback.trigger == tgui::Button::MouseEntered) {
            // Mouse entered widget
        }
    }
}

See the callback tutorial for more info.