Messages

Results in the text being off-centered, almost as if the origin to the text didn't get set right.

Not being perfectly centered is a known issue on my todo list, but it only differs a few pixels and isn't that bad so its an entirely different issue here.

I just tested the code you posted and it seems like the mistake is with setting the font. The button is only given a font when you call m_resourcesGui.add so at the time you set its text and size it has no font yet. Moving the add line to before the load call (right after it also works, it just has to be before the other functions) should solve the problem.

It seems like this bug exists in all widgets. I'm not planning on fixing it though (due to a redesign it was already fixed in v0.7-dev), you should just add the widget to its parent before calling text related functions. This order was expected by design (hence add function is automatically called in widget constructor when constructing like in example codes).

You might even want to use the following code instead:

Code (cpp) Select Expand

m_resourcesInterface.tilesTab = tgui::Button::Ptr(m_resourcesGui);
m_resourcesInterface.tilesTab->load("widgets/White.conf");
// other functions like setText
// no need to call add function, already done in constructor

I decided to see what would happen if I created the form in the form-builder and load from the file, and it actually just resulted in no text appearing at all

Did you set a global font before loading the file?
If you did, could you send the file so I can check it?

Widgets (except for Picture) are loaded from config files. These config files describe which images the widget should use.

You are passing images to the load function instead of the config file. What you really want is the following:

Code (cpp) Select Expand

baseSlider->load("widgets/White.conf");

Hi, welcome.

I'm going to need a little bit more information.
- So loading other widgets (e.g. edit box or button) works? (picture doesn't count, it doesn't use a config file)
- Could you paste the exact error message here?
- Could you show the code that reproduces this (simple main function that loads the slider and gives the error)?

It is not possible. You should draw an sf::Text yourself to have more advanced features like bold and underline.

Or you can cheat, put the following before including tgui and use m_Text anyway . But that's probably not what you want.

Code (cpp) Select Expand

#define private public
#define protected public

Edit: I'll think about adding a setStyle function in the future. But I would have to test what the effect would be (since it might break stuff like word-wrap).

I really wish I could help further but I have run out of time. I have to get my windows environment fixed first before I can continue. It seems to work in VS2013, but I'm also experiencing crashes on draw which may or may not be related to the tons of opengl errors in my terminal which are probably caused by my graphics driver. I probably won't be able to help further until wednesday.

You could try one thing yourself in the meantime though:
In addition to the changes that I have made in the version on github, also replace the line "label->setText(label->getText() + tempLine->getText());" in ChatBox.cpp (line 355) to

Code (cpp) Select Expand

std::string temp1 = label->getText().toAnsiString();
std::string temp2 = tempLine->getText().toAnsiString();
label->setText(temp1 + temp2); and then recompile tgui.

[EDIT]

I have solved the "problem". As far as I can see, there was nothing wrong with the code and this is all visual studios fault.

The following code crashed:

Code (cpp) Select Expand

newText->setText(text.toWideString().substr(begin, length));

while the following worked fine:

Code (cpp) Select Expand

std::wstring temp = text.toWideString().substr(begin, length);
newText->setText(temp);

But actually, since this code was only added because sfml 2.0 did not have a substring method (which it now has), I just replaced it to the following and therefore forcing people to update to sfml 2.2. But at least the problem is solved.

Code (cpp) Select Expand

newText->setText(text.substring(begin, length));

To get the fix, you will have to download the latest version from github and compile tgui yourself.

EDIT: ChatBox::addLine still crashes apparently. It seems like VS2012 may have some serious problems with using the sf::String class as temporary value. I'm not sure if I can really fix this.

I have been able to boot my windows again and I can reproduce the error. So it is definitely a bug in tgui.
I'll let you know when I fixed it.

Thanks. It doesn't really help in finding the mistake, but it at least rules out a lot of possibilities.

I just tried booting my windows but it is apparently no longer booting. It worked fine two days ago but now it seems like it won't get further than my grub bootloader. I'm going to try overwriting it with the windows bootloader but if that doesn't help then we have a serious issue as it is the only pc that I have which has the necessary programs installed on it.

What bothers me is that I can't reproduce it on linux.
Could you make sure that you are using the correct sfml libraries? If you downloaded the tgui libraries from my site then you need sfml 2.2, otherwise you must use the exact version which u used when compiling tgui. And also make sure that you use the debug libs for both sfml and tgui.

I would actually need to know what lines inside the tgui code cause the crash. In the stack frame you see those tgui-d.dll, I would have to know which line and which function exactly that it is referring to. Only then would I be able to figure out what is happening without debugging it myself.

After looking it up, I just realized again that on windows you need special files (.pdb files) in order to get that information. These are generated when compiling tgui yourself but not distributed in the pre-compiled library download. I still have this pdb file on my pc, you might want to try putting it next to your dll and see if it gives more information like that.

I'm going to sleep now (it's 3 am here), maybe I will try running that code on my pc tomorrow and see what it gives. But I can't promise anything, I still have to study for my last exam that I have Wednesday and debugging stuff can be too time consuming if the bug isn't immediately found.

When I press retry, it breakpoints into dbgheap.c at line 1424.

At that point, you should look at the call stack. Since those lines of code don't give a problem here (testing on linux though), the callstack would give me some idea of where it happens.

You might also want to give me a minimal and complete example code (simple main function with code that reproduces this problem). Then I can decently test it if I can't find the mistake from the call stack.

Also I had another question about textbox and chatbox. Is there a way to automatically scroll down the textbox, i.e. if the amount of text exceeds the ysize, then can I move the scroll automatically so the last entry is the one that stays in focus within the textbox?

textbox->setText, textbox->addText and chatbox->addLine should all scroll down to the bottom.

No you can't. You must call button->setSize to give it a size.

There are of course workarounds for what you want, but they are probably not worth the effort. You would be able to create a Label widget (without adding it to the gui) and setting the size and text in it. Then add something like button->setSize(tgui::bindWidth(label) * 1.2f, tgui::bindHeight(label) * 1.2f) somewhere in your code. By changing the text or size of the label, the button will then automatically be resized. But then you have to be updating the text in both the label and button the whole time and you might as well just create a button without text and using the label to display the text.

The text size does not change the size of the button. Not even in v0.6.

It only works the other way, by setting the text size to 0 (default), the size of the text is recalculated automatically when the size of the button is changed.

The code u used is indeed wrong. Technically the editBoxWidth and editBoxHeight should be part of the std::bind call because you want to bind 3 parameters (this pointer, width and height) and not just one.

But unlike the old bindCallback function, the connect function will take care of binding for you. It is enough to write the following:

Code Select Expand

buttonCreate->connect("Pressed", &Handler::createNewMap, this, editBoxWidth, editBoxHeight);

The connect function will "detect" that all parameters of the createNewMap function are given and will bind these parameters.

The id itself has only a single purpose: to identify where the callback came from. It doesn't have any special meaning inside tgui. So there is absolutely no problem with reusing the same id in multiple places.

That being said, you can only bind callbacks from tgui widgets. I do not control hot-keys. If you want your code to be executed when you press a keyboard key then you must call the code yourself. There are two ways to handle this.

The first way requires no change to your current code, but I would advice the second method.
When the key is pressed, you will create the callback and add it in the gui (using an undocumented function )

Code (cpp) Select Expand

Callback callback;
callback.id = QUIT_GAME;
gui.addChildCallback(callback);

Of course where you handle this callback, you can only check callback.id because the other properties of the callback are not set.


The second method is is by binding callback functions instead of using ids.

Code (cpp) Select Expand

void quit() {
  std::cout << "Quit" << std::endl;
}
button->bindCallback(quit, tgui::Button::LeftMouseClicked);

// When you press the Q button
quit();

You would have to take a look at the callback tutorial for more info on how to use the bindCallback function. In this example the quit function has no access to the sf::RenderWindow so it can't close it. This could be solved if it is in a class, but then you would have to bind differently (because of the 'this' pointer in class functions), or by using std::bind like the tutorial shows on a tgui::Gui object.

TGUI was not intended to be used with multiple views. However that doesn't mean it won't work, it just hasn't been tested yet.

In v0.7-dev, the Gui object has its own setView which might makes things a little easier. In v0.6 the gui uses the view that is set at the moment you call the handleEvent and draw functions. But in order to use this view, you have to pass 'false' as an extra parameter to these two functions. Since you are working with different views, you will have to make sure that the same view is set at the time you call handleEvent as when you call draw.

Code would look like this. Using multiple Gui objects has not been tested, but as long as they don't contain the same widgets I don't immediately see any problems.

Code (cpp) Select Expand

// ...
tgui::Gui gui1(window);
tgui::Gui gui2(window);
// ...
while (window.isOpen())
{
    // ...
    while (window.pollEvent(event))
    {
        // ...
        window.setView(wiew1);
        gui1.handleEvent(event, false);
        window.setView(wiew2);
        gui2.handleEvent(event, false);
    }

    // ...
    window.setView(wiew1);
    gui1.draw(false);
    window.setView(wiew2);
    gui2.draw(false);
    // ...
}

I see there is a child window but I don't want the user to be able to close any of those child windows - is there a way to remove close X button in a child window?

The close button cannot be removed. It can be blocked though (binding a callback when the window gets closed and not closing the window there). If you don't need a title bar either then you could use a Panel widget.

Thanks for reporting this.
I think I fixed it, but let me know if it is still happening.

I want to believe you about you being sure that the libraries are set up correctly, but I am yet to see a crash on windows that was not caused by incompatible libraries.

Did you have any sfml or tgui version on your computer? If you do, remove them from your pc (or temporary rename the folder) to make sure they don't influence anything.
Since you are linking dynamically, make sure that you are using the right dlls. It wouldn't be the first time that someone used the right libraries but the wrong dlls.

If I would have the same compiler I would ask to send everything so I can test it on my pc but that won't be possible. But if you send me the .cbp file then I can double check if all settings are correct.

There is only one far-fetched reason that I can think of other than a wrong set-up. Did you build both the release and debug version of tgui? If you did, try clearing the cmake cache and just build the debug version. That would rule out the debug tgui libraries being linked to the sfml release libraries.

TGUI does not support android or ios yet.

I tried to get it working on android a few months ago but I failed to get it running.
My knowledge of the system is lacking (while sfml has two developers for just android) and tgui requires c++11 which means that I can't base the entire cmake code on the one in sfml.

On very short term I don't even have time to work on tgui and when I do, I want to finish the most important stuff in v0.7 first. So my next attempt to port it to android will probably be in august or something.

I don't have an iOS device but I may be able get it working on an emulator if I can set up an OS X on my pc again. But android has a bigger priority (since it is easier for me to test).

I just remembered something. The handleEvent function returns a boolean value telling whether the event was consumed by tgui. So if you receive a sf::Event::TextEntered event then you could just check the return value of handleEvent. If it returns false then your game engine can continue with the event.

Good luck with exams!

Thanks.

Edit:
I knew I implemented this for someone, but apparently I did it for you. So I guess you might already know that option

The hasFocus function on the Gui object was only added because sfml did not yet have a way to check which window is focused. So it is indeed entirely unrelated.

But I don't want to add such a function because I don't like the focusing part of my gui in general. It has to be completely redesigned to be useful. So maybe one day something like that will be added.

I even thought that some widget is always focused in the gui, so you should be glad that you can even detect it with the way you currently do

I really don't know yet which direction my gui will take. I think the focus system as it exists now might even completely disappear in the future. But I don't have time to think about these things, I'm in the middle of my exam period.

In case you haven't figured it out yourself yet by now, the code you need is:

Code (cpp) Select Expand

comboBox->bindCallbackEx(&GuiOptions::resolutionCallback, this, tgui::ComboBox::ItemSelected);

I'm assuming that you are putting this code inside a function from GuiOptions, based on the error. Otherwise the 'this' should be replaced with the pointer to the class instance.

It is because you are binding a member function instead of normal function.

I don't have time to write a full answer right now, but it is mentioned in the tutorials https://tgui.eu/tutorials/v06/callback-system/.

The question is a bit unclear.

If your goal is to find out what the currently selected item is, then the above answer is correct.

If you however want a callback when the selected item changes, then do the following:

v0.6:

Code Select Expand

comboBox->bindCallbackEx(function, tgui::ComboBox::ItemSelected);

v0.7-dev:

Code Select Expand

comboBox->connectEx("ItemSelected", function);

In both cases the function looks like this:

Code Select Expand

void function(const tgui::Callback& callback)
{
    // callback.text contains the newly selected item
}

For more information about how the callbacks work, see the tutorials.

PS: As you can see it is best to mention which tgui version you are using. I know it is unlikely that you are using v0.7-dev, but I still have to give the information as well just in case.

You're welcome. I'm glad you like it.

Sorry for double post.

There is no problem with double-posting. I actually prefer it over editing a post that you made hours earlier.

If you make a new post, I will get an email and read it. But I don't get a mail if you edit a post. If it's just a small edit or if the post was only a few minutes ago then editing is better, but if like in the other topic there is half a day between the post and the edit, then you should have made a new post instead.

I'm not strict with rules for editing or double posting, you should just do what you find best for that situation.

I've identified the problem why unique_ptr::~unique_ptr was not calling destructor, cuz they were not tagged as virtual

Damn virtual destructors in c++
I can think of reasons why they don't do it, but it would be so much easier if they were virtual automatically once you inherit from the class