Jump to content
  • Advertisement
Sign in to follow this  
  • entries
    45
  • comments
    48
  • views
    51921

True helplessness

Sign in to follow this  
hplus0603

270 views

So, I ran into this problem, where after I delete a CEGUI GUISheet within the handler of a button Clicked event, the CEGUI library crashes.
I tried making the deletion deferred (by queuing an event and not deleting until I'm outside the CEGUI library) but that didn't really improve things; I'll still crash somewhere deep inside the CEGUI library right after.
Given my no-source policy, this turns out to be a problem -- the manual, such as it is, shows nothing wrong, and the CEGUI forums have not yet come up with any help for this situation.

By the way, that's one of my pet peeves about Open Source: they tend to believe that Doxygen headers is all the documentation you need. There are two problems with this:
  • The first is that you don't get any good overview of the entire system ("it starts here, and the forks into these separate interfaces, ...").

  • The second is that people tend to write documentation like:

    /** Set the active widget.
    * @param widget The widget to set.
    */
    void setActiveWidget(Widget *wig);



That's not documentation; that's an insult to the reader's intelligence!

Documentation will tell you what the valid arguments for "wig" would be (is NULL OK?), what state the object needs to be in for the function call to make sense, what happens to the previously set Widget (is it deleted or just ignored?), etc. Given that writing that level of documentation is hard work for little to no visible gain or peer approval, most Open Source projects don't really get to that level. There are some exceptions -- just like there is some commercial source with abysmally bad documentation -- but in general, my experience has been that, when people get paid for documentation, rather than doing it in their spare time, the documentation is better.

OK, so this aside aside, I'm now stuck with a crash. I suppose I can work around it somehow; say by just hiding a GUI instead of deleting it, but down that path lies madness. I won't remember to do it right later, and thus I'll sit with a memory leak forever, where an entire GUI gets leaked each time it's shown. I tend to dislike being in that situation.

Can I re-design the entire GUI approach in my game? Perhaps all GUIs are declared up-front, and pre-loaded, and then you just show/hide them, rather than creating/destroying them. That would be somewhat resource intensive, but would work around this problem (which I can't even prove is a bug, given my "no source" approach). System design imposed by third party bugs? (assuming the bug is not in my code, of course -- which it might be; I just can't tell)
Sign in to follow this  


1 Comment


Recommended Comments

Turns out that, even though the destructor is public, you don't destroy a GUI on the GUI object itself; you ask the GUI manager to do it.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!