CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 5 of 5
  1. #1
    Join Date
    Mar 2017
    Posts
    3

    Design Pattern to update child objects when parent changes

    Hello, I have been slowly learning how to make a simplistic GUI for a game, and I am unsure on how to update child objects when their parent changes. For example, I'd like to have a single master "UIParent" object that all objects are a child of. I could then hide the UIParent, and in turn hide every GUI Object.

    My ideas so far have been:

    When rendering simply check if the parent is visible and itself is visible, then draw. The problem here is that anything that is a child of a child of the UIParent (or further), will only see the visibility of the it's own parent, and nothing higher.

    If on each update, I change the visibility flag on each object to that of the UIParent, then the update order would matter, and I would then need to keep two flags for parent visibility and self visibility. I don't think this would work for childen of anything that isn't the UIParent either. (I think, I'm second guessing myself on this one)

    I could use some sort of message design pattern... I haven't thought too much on that, as it is not something I have experience with yet.

    Do you have any ideas, or hints on what I should be trying to do?

    Thanks

  2. #2
    Join Date
    Mar 2017
    Posts
    3

    Re: Design Pattern to update child objects when parent changes

    I think I found a decent solution with this simple function:

    Code:
    bool getParentVisible(void)
    {
    	if (m_parent)
    	{
    		return m_parent->getParentVisible() && m_visible;
    	}
    	else return m_visible;
    }
    This traverses each parent in a chain up to the topmost parent comparing the visibility with the current object. This is the first time I've ever found a use for recursion!

  3. #3
    Join Date
    Feb 2017
    Posts
    677

    Re: Design Pattern to update child objects when parent changes

    Quote Originally Posted by Tayrnis View Post
    When rendering simply check if the parent is visible and itself is visible, then draw. The problem here is that anything that is a child of a child of the UIParent (or further), will only see the visibility of the it's own parent, and nothing higher.
    Another way to organize a part-whole hierarchy is as a tree where each parent knows its own children. There is a design pattern for this called Composite but that may be overkill if you're not an OO fanatic .

    Such a tree can easily be traversed top-down using recursion and any parent node will always be encountered before its children. So say you are traversing the tree in order to print visible nodes. Then whenever you encounter a non-visible node you simply just skip it which also means all its children (and all their children etcetera) also will be skipped regardless of whether they are marked as non-visible or not.

    But it's still sometimes necessary for a child to know its parent which corresponds to the organization you have now. So in practice one often ends up with both "every parent knows its children" and "each child knows its parent" in the same data structure.
    Last edited by wolle; March 19th, 2017 at 04:53 AM.

  4. #4
    Join Date
    Mar 2017
    Posts
    3

    Re: Design Pattern to update child objects when parent changes

    Quote Originally Posted by wolle View Post
    Another way to organize a part-whole hierarchy is as a tree where each parent knows its own children. There is a design pattern for this called Composite but that may be overkill if you're not an OO fanatic .

    Such a tree can easily be traversed top-down using recursion and any parent node will always be encountered before its children. So say you are traversing the tree in order to print visible nodes. Then whenever you encounter a non-visible node you simply just skip it which also means all its children (and all their children etcetera) also will be skipped regardless of whether they are marked as non-visible or not.

    But it's still sometimes necessary for a child to know its parent which corresponds to the organization you have now. So in practice one often ends up with both "every parent knows its children" and "each child knows its parent" in the same data structure.
    Thanks for the reply, that makes a lot of sense! This would also allow me to recursively update the on screen positions of each child when a parent is moved!

    I'm not sure why, but I put on restriction on myself that the relationship could only be one way. It makes sense that they should know each other.
    Last edited by Tayrnis; March 19th, 2017 at 12:52 PM.

  5. #5
    Join Date
    Feb 2017
    Posts
    677

    Re: Design Pattern to update child objects when parent changes

    Just a note to implementation.

    I see you are using pointers to represent nodes but I don't know what kind it is. Remember you cannot use std::shared_ptr to represent both the parent->child and child->parent relationships. It's because that would result in nodes holding each other circularly and reference counting smart pointers (like std::shared_ptr) cannot handle circular chains. To overcome this you need to use ordinary "raw" pointers or std::weak_ptr:s in one of the directions, say (preferably) from child to parent.

    Good luck!
    Last edited by wolle; March 20th, 2017 at 03:22 AM.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured