Hello: This is what I am doing now. I override the removeChildren and works well. The other methods that remove a child reduce to this method call so I only have to override the one removeChild method.
Take care Garrett On Jan 14, 2008, at 7:25 PM, Bradford, Chase wrote: >> >> Hello Robert: >> >> Yes, I forgot the prototype was for position and num elements. >> Sorry >> about that. I guess the confusion is: >> >> _children.erase(_children.begin()+pos,_children.begin() >> +endOfRemoveRange); >> >> childRemoved(pos,endOfRemoveRange-pos); >> >> Then we need childRemoving: >> >> childRemoving(pos,endOfRemoveRange-pos); >> >> _children.erase(_children.begin()+pos,_children.begin() >> +endOfRemoveRange); >> >> childRemoved(pos,endOfRemoveRange-pos); >> >> If we want to have access to the actual objects before whacking them >> from the list. >> >> >> Take care >> >> Garrett >> >> On Jan 14, 2008, at 2:13 PM, Robert Osfield wrote: >> >>> HI Garrett, >>> >>> On Jan 14, 2008 5:38 PM, Garrett Potts <[EMAIL PROTECTED]> wrote: >>>> Is there a problem with childRemoved taking as an argument a >>>> osg::Node* type. Looking at the code in where childRemoved in the >>>> osg::Group node the indices as mentioned can't really be used to >>>> access the list in which the node was removed. Instead, would it > be >>>> better to just pass the osg::Node* to childRemoved? >>> >>> The unsigned int position is used because the Nodes themselves have >>> been removed and potentially no longer exist, so it'd be very bad >>> thing to pass the Node* around. >>> >>> The concept behind the childInserted and childRemoved is that it >>> enables the maintenance of data structures that exist on a one per >>> child basis where there is 1:1 correspondance between the lists that >>> hold the original child data and the local data. >>> >>> Robert. >>> > > For your case, would it be sufficient to override removeChildren( > unsigned int pos, unsigned int cnt), and do your processing before > forwarding the call to osg::Group::removeChildren(pos, cnt ) > > Chase > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions- > openscenegraph.org _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
