Re: pfSwitch node and pfSwitchVal
John Rohlf (jrohlf++at++tubes)
Sat, 10 Jun 95 11:16:38 PDT
>
> The way pfSwitchVal function is been designed, is making us do unnecessary
> processing in our development.
>
> For example: while converting a SoSwitch node into pfSwitch node in loadIv,
> taking care that all children of SoSwitch get converted into corresponding
> performer nodes, It doesn't allow me to set the switch value (using
> pfSwitchVal)
> to anything >= 0, obviously because at that time the new pfSwitch doesn't have
> any children. Its children get added during further traversals only. Due to
> this limitation, I can't maintain the correspondence between the original
> SoSwitch's whichChild value and the new pfSwitch's switch value at the time
> of node conversion! I have to maintain a list of this information for later
> processing (after the entire conversion) when I need to once again search
> (or maintain pointers) for all pfSwitch nodes and set their switch values to
> the saved ones.
>
> It would be nice if pfSwitchVal was designed so as to check for the bounds
> on the switch value at the time of applying (using) it and not when it is
> being set (ie: initialized). This would allow us to initialize the switch
> value to a non-existant child which could later be added dynamically. Or
> if not added, Performer could give runtime error OR core dump.
>
We agree that the 1.2 pfSwitchVal behavior is bogus - it
has already been fixed as you suggest for the next release.
This archive was generated by hypermail 2.0b2
on Mon Aug 10 1998 - 17:51:35 PDT