I'm debugging the property browsers. Currently they don't handle indexing properly:
multiple instances of /input/mice/mouse/mode[0]/button/ are shown without indices
because the buttons are numbered 2,3,4 but the test it uses is "Is there a child of
this name with index 1?". Clicking on any of them causes a seg-fault because no such
node (with implied index zero) exists.
I propose to change it to display the index if the index is non-zero OR it has
siblings with the same name (i.e. if index!=0 or there are two or more different
indices).
I also want to factor out this code from FG's telnet interface, FG's property picker,
and SGPropertyNode::getPath which all try to do the same thing. Proposal:
/**
* Return "name[index]", or just "name" if 'simplify' is true and
* the index is 0 and there are no siblings with the same name.
*/
string
SGPropertyNode::getPrettyName(bool simplify) const;
("PrettyName" is a horrible name. Suggestions?)
This seems an appropriate addition because the class already contains the ability to
parse such a string (name with optional index) in getNode(const char * relative_path,
...) and to generate one as a complete path, but not yet to generate one as a single
path component.
While investigating, I found that SGPropertyNode::getPath returns a (char *) pointer
to the character data of a string on its stack, i.e. to undefined memory after it
returns. I remember someone was changing strings to char* for efficiency. Perhaps
this bug was introduced then. I'll include a patch for it with my eventual patch for
the above, unless someone beats me to it. I don't think it affects any existing
callers: they all want a string anyway.
- Julian
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
