TGUI: a c++ GUI for SFML (with Form Builder)

[pighead10]

I've come across another fatal error - it's either me or tgui. Since upgrading to tgui 0.5 (and to the SFML RC), whenever I try and draw an object an unhandled exception occurs, showing me this code in visual studio 2010:

void RenderTarget::draw(const Vertex* vertices, unsigned int vertexCount,
                        PrimitiveType type, const RenderStates& states)
{
    // Nothing to draw?
    if (!vertices || (vertexCount == 0))
        return;

    if (activate(true))
    {
        // First set the persistent OpenGL states if it's the very first call
        if (!m_cache.glStatesSet)
            resetGLStates();

        // Check if the vertex count is low enough so that we can pre-transform them
        bool useVertexCache = (vertexCount <= StatesCache::VertexCacheSize);
        if (useVertexCache)
        {
            // Pre-transform the vertices and store them into the vertex cache
            for (unsigned int i = 0; i < vertexCount; ++i)
            {
                Vertex& vertex = m_cache.vertexCache[i];
                vertex.position = states.transform * vertices[i].position;
                vertex.color = vertices[i].color;
                vertex.texCoords = vertices[i].texCoords;
            }

I tried drawing something in SFML without tgui and it worked fine. I haven't changed any code at all since upgrading other than a few of the function call names to make it work with the new tgui.

[texus]

What objects are you drawing?
Could you try to narrow the problem down by creating just one object and then try to find out which object is causing this?

[pighead10]

Sorry, I meant an SFML sprite. The only thing I can think of, as it works without tgui, is that the tgui window wrapper is somehow breaking this (or if I needed to change something else for the update, but there is nothing in the upgrading tutorial that I have not done).

[eXpl0it3r]

You need to make use of the call backtrace, which will tell you what function call is causing the error.

[pighead10]

You need to make use of the call backtrace, which will tell you what function call is causing the error.

I already know what line is causing the error!

window.draw(sprite)

[texus]

So if I understand it correctly, you are just drawing a sprite, nothing more?

If it worked with v0.4, then something must be broken in v0.5, but I don't have any problems here so you will have to find out what is causing it.
- Have you tried with some basic code, nothing more than creating a window and drawing the sprite?
- Try if it makes a difference if you use sf::RenderWindow or tgui::Window. Is the problem with just linking and including, or does it only occur when using tgui in your code?
- Are you using debug libs or release libs for both sfml and tgui? You can't mix them.

If you think that the problem lies in tgui::Window then you can test with tgui::Form (it isn't in the tutorials, you will need to use the documentation or just look in the header file).

[pighead10]

So if I understand it correctly, you are just drawing a sprite, nothing more?

If it worked with v0.4, then something must be broken in v0.5, but I don't have any problems here so you will have to find out what is causing it.
- Have you tried with some basic code, nothing more than creating a window and drawing the sprite?
- Try if it makes a difference if you use sf::RenderWindow or tgui::Window. Is the problem with just linking and including, or does it only occur when using tgui in your code?
- Are you using debug libs or release libs for both sfml and tgui? You can't mix them.

If you think that the problem lies in tgui::Window then you can test with tgui::Form (it isn't in the tutorials, you will need to use the documentation or just look in the header file).

I'll test with some basic code later, I am going out for a while. Currently what I have tested is my framework  doing nothing but creating the window and drawing a sprite - nothing to SFML is done other than that - using a tgui::Window, and another with a completely minimal program without tgui (using a sf::RenderWindow) to draw a sprite which works. I highly doubt it is my framework but I'm unsure whether it is using tgui or using the tgui window which is causing the problem.

[pighead10]

I built my project again today, and it works! I've absolutely no idea why, but it does.

[texus]

@pighead10
Good to hear that you got it to work.

@Ruckamongus
A full animated interface like you suggested would take too much time and won't come in the near future, but for now I do have an AnimatedButton.

You can use it like this:

tgui::AnimatedButton* button = window.add<tgui::AnimatedButton>("myButton");
button->load("TGUI/objects/AnimatedButton/Example");
button->setFrame(5); // Make the last frame visible, to avoid animation at start

The button is made to replay its animation over and over, but by setting the frame duration of the last frame to 0 you should get the effect you wanted. The only problem I saw so far is that it doesn't really look good in combination with the mouse down image, but it might look a lot better if you don't use the example images (they don't fit together).

[pighead10]

Bug:

for(int a=1;a<=cols;a++){
                        std::string name1 = "backpackgui_spacer"+std::to_string((long long)counter);
                        std::shared_ptr<tgui::Picture> objspacer = std::shared_ptr<tgui::Picture>(SfmlFramework::Singleton()->window->add<tgui::Picture>(name1));
                        objspacer->load("noitem.png");
                        objspacer->callbackID = 50+counter;
                        objspacer->setPosition(m_pRoundManager->getMapSize().x/2*tile_size - tile_size - ((cols/2)*tile_size) + tile_size*a,m_pRoundManager->getMapSize().y*tile_size-100 - tile_size - rows*tile_size + i*tile_size);
                        objspacer->moveToBack();
 

The last line, objspacer->moveToBack(), causes the program to exit with:

First-chance exception at 0x775bb9bc in Build to survive.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x003ee408..
First-chance exception at 0x775bb9bc in Build to survive.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x003edd20..
First-chance exception at 0x775bb9bc in Build to survive.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000..

[texus]

Could you try without using shared_ptr and do it like in the tutorials?
I just did a little test (but with boost instead of c++11) and I only got a crash when using the shared pointer.
I don't really know how shared_ptr works exactly, but I do know that moveToBack changes the location where the pointer is stored and this could perhaps be causing the problem.

[pighead10]

Ah. Well, my framework is entirely structured around shared_ptrs, so that won't be possible. Also, Avast blocks FormBuilder.exe - "Win32:MalOb-HC [Cryp]"

EDIT: Deleted it (I was using the debug version) and regenerated it as the release mode and it is no longer detected as a virus. I probably have some hitherto unknown virus which infected it the first time.

EDIT X2: The formbuilder immediately exits upon opening.

[texus]

As I said a few times before, the form builder will close if it can't find its resources. The latest version should however print an error, so if you start it through the command prompt then you should see what's wrong.

I am going to do some more tests tomorrow, but I fear that your smart pointer is trying to delete the pointer when it is reallocated and as the tutorial says: never delete the pointer. If this really turns out to be the problem then there is nothing else to do then redesign your framework.

[texus]

I got bad news. Although the crash in moveToBack was caused by my code (it's fixed now), the shared_ptr did exactly what I was afraid of. At the end of your for loop, when the smart pointer goes out of scope, it deletes the pointer. So the program will crash on the next draw call.

But I don't see what big changes you would need to make in your framework to solve this. It's not like you can't keep using smart pointers at other places, just not with my objects.
As far as I see (I don't have your full source of course, so I could be wrong), all you have to do is change this line

std::shared_ptr<tgui::Picture> objspacer = std::shared_ptr<tgui::Picture>(SfmlFramework::Singleton()->window->add<tgui::Picture>(name1));

into this

tgui::Picture* objspacer = SfmlFramework::Singleton()->window->add<tgui::Picture>(name1);

That should work fine and, unless you are storing the pointers somewhere (which you normally shouldn't do), you don't even have to change anything else.
edit: You will probably have more of these lines and thus more to change than just one line, but the point is that only the declaration of the objects should change.

[pighead10]

I got bad news. Although the crash in moveToBack was caused by my code (it's fixed now), the shared_ptr did exactly what I was afraid of. At the end of your for loop, when the smart pointer goes out of scope, it deletes the pointer. So the program will crash on the next draw call.

But I don't see what big changes you would need to make in your framework to solve this. It's not like you can't keep using smart pointers at other places, just not with my objects.
As far as I see (I don't have your full source of course, so I could be wrong), all you have to do is change this line

std::shared_ptr<tgui::Picture> objspacer = std::shared_ptr<tgui::Picture>(SfmlFramework::Singleton()->window->add<tgui::Picture>(name1));

into this

tgui::Picture* objspacer = SfmlFramework::Singleton()->window->add<tgui::Picture>(name1);

That should work fine and, unless you are storing the pointers somewhere (which you normally shouldn't do), you don't even have to change anything else.
edit: You will probably have more of these lines and thus more to change than just one line, but the point is that only the declaration of the objects should change.

There's the problem - I'm storing every pointer for every object, and the resource freeing process is based around std::shared_ptr's. However, in my code here:

for(int a=1;a<=cols;a++){
                        std::string name1 = "backpackgui_spacer"+std::to_string((long long)counter);
                        std::shared_ptr<tgui::Picture> objspacer = std::shared_ptr<tgui::Picture>(SfmlFramework::Singleton()->window->add<tgui::Picture>(name1));
                        objspacer->load("noitem.png");
                        objspacer->callbackID = 50+counter;
                        objspacer->setPosition(m_pRoundManager->getMapSize().x/2*tile_size - tile_size - ((cols/2)*tile_size) + tile_size*a,m_pRoundManager->getMapSize().y*tile_size-100 - tile_size - rows*tile_size + i*tile_size);
                        //objspacer->moveToBack(); BREAKS

                        if(i==1 && a == 1){
                                std::string name = "backpackgui_selected";
                                std::shared_ptr<tgui::Picture> selected = std::shared_ptr<tgui::Picture>(SfmlFramework::Singleton()->window->add<tgui::Picture>(name));
                                selected->setPosition(objspacer->getPosition());
                                selected->load("selected.png");
                                selected->moveToBack(); //works fine
                                objects[name] = selected;

The moveToBack() call that is commented out crashes, but selected->moveToBack() later on works fine.