Crash after using drop() on custom GUI element

[Carnafex]

Heya all,

I'm building my own custom GUI element (treeview in this case), and I ran into a problem where calling drop on the pointer is causing my program to crash when changing states.

For a bit more info, basically I have different states in the engine which I change to based on user input. Each state has an init function which builds up the objects and a clear, which clears the scenegraph. (smgr->clear and guienv->clear)

So inside the header I use
IGUITreeview* m_pObjectTree;

And then inside the state init function I call:
m_pObjectTree = new CGUITreeview(m_pGMgr->guienv, 0, 0, core::rect<s32>(0,0,200,500));
m_pObjectTree->drop();

This loads fine, but the moment I change states, (which calls smgr->clear and guienv->clear) my program crashes.

I can fix the crash by removing the m_pObjectTree->drop(), but then that leaves a wonderful memory leak.

So does anyone have any idea how I might fix this?
Any help would be greatly appreciated.

[Virion]

i got the same problem previously, but what i did was just hidden up my GUI elements when I don't need 'em.

->setVisible(false);

[JP]

Try element->remove() instead. Hybrid has recently (today or yesterday) that drop() on a GUI element causes problems in the GUI element graph so that could be why it's crashing.

Also i presume it's actually the call to drop that is causing the crash? After you call drop (or remove) you should set your element's pointer to NULL, otherwise if you then do if (element) it will still return true as the pointer is still pointing to the same memory location as before.

[CuteAlien]

IGUIElements are somewhat special and so what you do here looks actually mostly correct.

Gui elements have usually a reference count of 2 after the construction, that's why they are always dropped once after creating them with new. The reason for this is that the parent which is usually set in the constructor does grab the elements once more. But the engine ensures that you always have a parent - if it is NULL, then it sets the guienvironment as parent. You don't seem to do that and so you have now some problem. I suppose you could probably call the drop in the destructor instead. Or you always set a parent, then you can drop it immediately as it's done in the engine.

[Carnafex]

I've actually tried the ->setVisible(false) and ->delete, and they both kinda work but not nicely with my states. The visible makes it very messy to handle my GUI (since I have alot of elements), and the ->delete clears the memory issue but causes it to die when I quit my program! (pretty much acts the same as using drop)

In the end I tried it the way cuteAlien described and set a parent and dropped it immediately like the engines does. This actually made it remove the memory leak, but still crash like before.

However, you said to perhaps call the drop in the destructor. I checked out the destructor for the element and realised that
if (Scrollbar) Scrollbar->drop();
was actually causing the crash (the destructor was based off the ListBox element, just to give me a starting point). I'm a bit unsure as to why, but commenting these out fixed the problem!

So now I can call drop() normally on the element, fixing the memory leak, and able to change states with the game dying!

Thanks for the help, I can now continue on actually building stuff instead of fixing memory leaks!

[Acki]

I checked out the destructor for the element and realised that
if (Scrollbar) Scrollbar->drop();
was actually causing the crash (the destructor was based off the ListBox element, just to give me a starting point). I'm a bit unsure as to why, but commenting these out fixed the problem!

So now I can call drop() normally on the element, fixing the memory leak, and able to change states with the game dying!

this reminds me of a problem I had when I tried to add a "lifetime" to gui elements...
I wanted the element to delete itself after a given time...
but it turned out that a gui element isn't able to delete itself and the program will crash if it tries...

I think it would be great if there was a "addToDeletionQueue" function for gui elements, like there is one for scene nodes !!!