I want to know which method of child get called when we remove any Node from its
parent.
I created MyLayer by extending Layer class and then add my own sprite MySprite which extend Sprite class of cocos2d-x framework. I need to decrease a counter when child removed so i need a method which i'd override in my MySprite class.
I use this method to remove.
parent->removeChild(child);
Here parent is MyLayer and child is MySprite pointer.
If the child is running these two methods will be called:
child->onExitTransitionDidStart();
child->onExit();
If you remove the child with cleanup = true(which is the default value), child->cleanup(); will be also called.
So the best solution for you would be to override virtual void onExit(); function of the child. And in the overridden method don't forget to call Node::onExit(); or whatever your superclass will be.
Related
I'm trying to do the tutorial for this:
https://www.makegameswith.us/gamernews/384/build-your-own-2048-with-spritebuilder-and-cocos2d
I want to add CCSprite for the above tutorial. I laid out the CCSprite in Spritebuilder and turn their visibility off at first. When the respective tile appear, only then the CCSprite will be visible. For example, when Tile A first appear, then CCSprite A will appear. When Tile A merge with another Tile A, Tile B will appear and so does CCSprite B and so on.
The problem is that the switch case used to determine the tile value is located at Grid.m but the CCSprite added to Spritebuilder is under the CCNode of MainScene class. If i don't put custom class for CCSprite, XCode couldn't find the member variable. If i put custom class of "Grid" for CCSprite, XCode would return error of "This class is not key value coding-compliant for the key spriteFrame." What should i do here?
Assuming in your CCB the root node is a CCNode (A) and you add a child CCSprite (B) to it, then:
if specified, the custom class of node A must be a subclass of CCNode
if specified, the custom class of node B must be a subclass of CCSprite
Regarding the variable assignment:
the variable of node A should be empty (at best it will create a reference to itself)
if needed, the variable of node B should be set to "doc root" and given a legal ObjC variable name (ie _nodeB)
Now when you set the custom var of node B and it is set to "doc root", you must add a correspondingly named property or ivar to the custom class for node A. Which means node A must have a custom class for "doc root" variables to work. Let's name it CustomClassA:
#interface CustomClassA : CCNode
{
CCSprite* _nodeB;
}
#end
Assuming you made node B use a custom class (inherited from CCSprite) you can also specify the custom class:
#class Grid;
#interface CustomClassA : CCNode
{
Grid* _grid;
}
#end
And add #import CCSpriteCustomClassB.h to the implementation file of CustomClassA.
Note that variable assignment does work without using a custom class in the node where you enter the variable name, but the root node must use a custom class for variable assignment to work.
PS: I'm not entirely clear on the "owner" variable setting. Normally owner will be nil, it's only non-nil when you specify it in code using CCBReader's load:owner: method. This serves some purpose but I haven't found and can't think of a use case for it at the moment.
I have a QWidget based class that I need to instantiate from another object.
If I create the widget in the body of its parent widget class it is all good:
new NodeWidget(rootItem, this); // this works
But when I use the aux method the widget is created, but never drawn.
rootItem->createWidget(this); // internally rootItem does the same thing as above
The method itself:
void createWidget(QWidget * target) {
if (!_ui) _ui = new NodeWidget(this, target);
...
}
The way I see it, both approaches do the same thing, but the first one works while the second one does not. The NodeWidget constructor runs, but the widget does not appear in the parent widget and the paintEvent is never called. Any ideas why?
EDIT: This is certainly odd, I noticed that the following line:
new QPushButton(this);
works when called in the constructor of the parent widget, but not when called from the mousePress event. What IS the difference?
Do you call show() for your custom widget?
If the child widget is created after it's parent is already showed the parent-child relationship can't show the child too, so you need to explicitly call show().
But when the widget is added in the constructor, the parent isn't showed yet and then when the parent is showed it automatically shows all the children that were not explicitly hidden.
Do I understand everything right - if I am creating some Qt object via new and this object has constructor with parent parameter then if I'm passing value to this param I don't need to call delete on this object, it will be called automatically be parent object? And this is true for every Qt class that has parent param in constructor?
Yes:
When you create a QObject with another object as parent, it's added to the parent's children() list, and is deleted when the parent is.
I have system that has classes derived from QGraphicsWidget. I manage derived class objects in layouts on QGraphicsScene. Now I need a compound item that contain two or more QGraphicsWidget in it and also I need to put that item inside my layout. So I choose QGraphicsItemGroup and write I class like this.
class CompositeItem : public QGraphicsItemGroup,public QGraphicsLayoutItem
{
...
};
I only implemented sizeHint function again.
When add CompositeItem instance to layout it does not shown.
What may cause this? Where I made wrong?
Call show() on either the QGraphicsItemGroup or QGraphicsWidgets after adding to the layout.
Add setGraphicsItem( this ) to your constructor.
For example, in an MFC program, I have my main application and a 'class'. What should I do if I want to update a control (say, a listbox) that is situated on my main application from that 'class'?
heres an example that worked for me
theApp.m_pMainWnd->GetDlgItem(IDC_BUTTON6)->SetWindowTextW(L"Run Auto Test");
Your class can be designed to trigger an event which your main application can listen for. Then, a listener/event handler/delegate can be called to handle the event and update the listbox. Typically, most event formats pass a reference of the sender, in this case your 'class', as well as an object containing event arguments. These arguments can be used to pass the list of items you want to add to your listbox.
If you have the handle to dialog object in your class, then you can use GetDlgItem(ResourceID) to get list control object.
The easiest approach is to expose the listview from your application form/window to the classes that use it. You can do this either by passing the listview object (or parent window) to the class constructor, or storing it in a static variable that is accessible by the class.
For better encapsulation, you can put a method in the application that the class can call, e.g. "AddItemToListBox()". This allows the application object to remain in control of how you access the listbox. Again you can do this as a static method, or pass the main program object's 'this' pointer into the class constructor.
i.e.
class CApplication
{
CListBox m_ListBox;
public:
static void CApplication::AddItemToListBox(CString itemText)
{
// Add the item as you wish here
}
}
class CMyClass
{
afx_msg void CMyClass::OnMouseDown(...)
{
CApplication::AddItemToListBox("This is a test");
}
}