When parent do any action, its children do same action also. But sometimes, I don't want child do the action. For example, a sprite like a man have a blood bar, when it moving, the bar should moving along with man also, that's OK. But when I shake or rotate the man, the bar should do nothing.
So, is a simple way to control it? The only one way I though is remove those child from parent, after action complete, re-add them.
you can control each child action using its separate tag.when ever you define child then set its tag and after when you want to get action of particular child then get child [self getActionByTag:childTag]; and perform action on it.
As you said removing and reattaching to another node works.
Or don't make that bar as child of man and add it to another node ,handle actions for that separately.
I don't think that there is any way to make child static and move only parent.
Related
I thought that the action you apply to one object of a container is automatically applied to every object in the container, but this doesn't seem to be the case in my project:
By making 1_br_ok_e visible, I would axpect the other two objects in the container to be made visible too, but nothing happens, only 1_br_ok_e becomes visible.
What am I missing?
No this isn't how containers work.
I am quoting from the Scirra documentation (https://www.scirra.com/manual/150/containers):
Placing objects in a container has the following effects:
If one object in a container is created, every other object in its container is also automatically created.
If one object in a container is destroyed, every other associated object in its container is also destroyed.
If a condition picks one object in a container, every other associated object in its container is also picked.
And that's it. Nothing else should be expected from containers.
In your case, destroying the object (and consecutively the whole container) could be an option if you never need them to reappear.
To support Scirra on this, I want to add that maybe in your case this could be a positive feature, but in most cases it's not a desirable functionality. Imagine creating a tank container where you have the tank's body and its turret. Rotating the turret would make the whole tank rotate, since the body would share the same action. You would have no way to make this work.
I have a construction as below:
parent
+ child
+ child
+ child
+ sub-parent
+ sub-child
+ sub-child
For now, I use multiply of "removeChild()", to remove elements from scene one by one. Like this:
removeChild(sub-child);
removeChild(sub-child);
removeChild(sub-parent);
//and so on
It's okay, but I found out that if I remove a parent all its children will disappear from scene too. (For now I do not know for sure ...)
How do you remove elements from a scene in the correct way ? As I do it now (one by one), or I could remove just a parent and my code will be a little bit shorter. Or is it the same thing?
Removing a display object from the stage will also remove all of that object's children. Think of it as a container that holds those children object. If you remove the container, you also remove the objects inside of it.
However, if you still have references to those children objects, or have event listeners attached to them, they won't be garbage collected (they will stick around in memory executing any code associated with them). So you still need to make sure you clean up everything when you remove the parent object.
The "display list" is a tree structure that looks like this:
When you add children to a container (DisplayObjectContainer), those children will remain as children of that container unless they are specifically removed from it.
When a container or DisplayObject is attached to the stage, they will render. If the object is a container, all of its descendants (children, children of children and so on) will also render.
If you remove an object from the stage, it and all of its descendants will stop rendering but their existing parent/child relationships remain in tact. This means if you add a container with children to the stage again, all of those children will begin to render again as well.
So to more accurately answer your question: removing a container does not actually remove its children. The children will not have a connection to the stage and will not render, but they are still children of the container.
With all that said, there is not often a reason that you would need to remove each individual child from a container. So long as the children do not have event listeners attached or are not referenced by the main application in any other way, they will all be eligible for garbage collection when their connection to the stage is severed. Removing the topmost possible container from the stage is perfectly normal.
You can remove the "sub-parent" and its child's will be removed as well from the scene (stage).
I have a SerialElement with two MediaElements and I want to jump in second element after I click the next button.
From SerialElement documentation:
The only way that the "current" status can pass from one child to another is when the state of one of the current child's traits changes in such a way that the SerialElement knows that it needs to change its current child. For example, if each child in the sequence has the PlayTrait, the "current" status advances from one child to the next when a child finishes playing and its PlayTrait's PlayState property changes from PLAYING to STOPPED.
So you can force the current child's state to change:
(serialElement.currentChild.getTrait("PlayTrait") as PlayTrait).stop();
I have a DefaultTreeModel containing a subclass of DefaultMutableTreeNode. I have only overridden isLeaf() to always return true because I lazily load the children when the node is expanded. Then, when the node is collapsed, I remove the children (firing the proper treeNodesRemoved event) because I have unsubscribed from updates from the server.
The problem is that after the user collapses a node and I remove the children, the stupid little expand circle disappears (but clicking that area still works to expand the node). How can I always show the expand control when the children have been removed?
Related: Add 'expand' button to JTree node that has no children?. Is adding a fake child the only way?
The way I did it is I add a fake child and expansion listener when children are removed. When I get notification that the node with fake child is going to be expanded I replace the fake child with actual lazily loaded children.
This way the node always has children and expand control is always presented
Hopefully a quick question here. I have setup a "LayoutPage" custom class (based on MovieClip) and I am attemptimg to create a "selected" behaviour.
When I assign my "addEventListener(MouseEvent.CLICK,toggleSelection)" from within my custom class, everything works as expected, clicking any object of that class does display the correct behaviour.
Now, I would like to extend the functionality by adding keyboard modifyer to either extend the selection or replace it.
For this, I thought of moving the "addEventListener" out of the class and put it inside the parent instead (my "PageLayout" class where all the "LayoutPage" live). But by doing so, the click event no longer register on the "LayoutPage" class but rather on its individual children (Page icon, Page number text field, Page Highlight shape, etc.)
Can anybody explain why this is happening and how I can circumvent it?
TIA
This should be happening no matter where you put your addEventListener. It is because mouseChildren is switched on by default. It is probably best to turn it off inside your LayoutPage class like so:
myLayoutPage.mouseChildren = false;
The actual issue is that use are probably using currentTarget to reference the item that was clicked on in your event handler method. Take a look at the descriptions for currentTarget and target to get a good idea of how they differ.
A good option would be to add your listener at the PageLayout level, but add it specifically to each LayoutPage child like so:
myLayoutPage.addEventListener(MouseEvent.CLICK, toggleSelection);
This way you can just use target in your handlers. But it would probably be best to still switch mouseChildren to false on each of your LayoutPage instances.