Sounds good. Are there any performance implications? Off hand it doesn't sound like it. Maybe a test doing a bunch of switches back and forth between different types just to check for leakage would be good. Am I right though that since the SetXXXValue alone won't change, this clear will not be done frequently? Or do we have code that will (maybe incorrectly) do this every frame?
Maybe cc a copy of your proposal to David Megginson would be a good idea. Best, Jim > -----Original Message----- > From: Melchior FRANZ <[EMAIL PROTECTED]> > Sent: Monday, 9. May 2005 8:13 -0400 > To: flightgear-devel@flightgear.org > Subject: [Flightgear-devel] [RFC][PATCH] SimGear: property system bug > > Vivian pointed out that a redefined Ctrl-U key binding didn't work > correctly. I found out that this is, because the definition in > $FG_ROOT/keyboard.xml sets <value type="bool"> for binding[1], > and ... [better sit down first!] ... and assigning <value type="double"> > in a *-set.xml file doesn't *really* set "double" as new type! > > Instead, the boolean is kept, and a double sqeezed into it. In other > words: once tainted as bool, you can throw all doubles in the universe > on a property node, and all it will accept is 0 and 1. Without warning! > > To fix that I added a clear() method to SGPropertyNode, which does first > call private clear_node() and then sets the type to NONE. Only now a new > type can get assigned. This new method is called from the XML > handler's startElement() (which fixes the Ctrl-U bug), and while I > was at it, from removeChild(), where it makes sense, too. setDoubleValue() > alone, for instance, does of course still not change a node type to > double. Patch attached. > > Does anyone have objections? Better solutions? (code preferred! > > m. > > > > > > PS: is it just me or is sg/fgfs grossly over-commented?! It's not > uncommon to see things like: > > // set node value to 0.0 > node->setDoubleValue(0.0); > > I add these silly comments, too, if it's the style of the file, > but it always costs me some nerves. (No need to tell me that this > is better than too *few* comments, which is an entirely different > story. :-} > _______________________________________________ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > _______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
