Jim Wilson writes: > "Ranges" and "Value lists" would be good. I was thinking of > enforcing rules defined in xml in the prop_picker, but it sounds > like your saying that should be in the property manager code. > Which makes sense. It'd be good to have a error return code(s) > from the property manager so that prop_picker (and the other > interfaces) could display a message to the user.
If the property manager could enforce basic constraints, it could eliminate a lot of C++ code. What are some reasonable facets for a property? Here's what I've thought of, going from general to specific: All Properties -------------- - is readable? (already implemented) - is writable? (already implemented) - is archivable? (already implemented) - data type (already implemented) - list of allowed values Numeric Properties ------------------ - minimum value - maximum value - wrap past minimum? - wrap past maximum? Real-Number Properties ---------------------- - step/granularity Right now, I can define /controls/throttle as a readable, writable, archivable double-precision floating-point value, and all of that information is available to the property picker. With some relatively minor changes, I could also specify that the property's minimum value is -1.0, its maximum value is 1.0, and that it should freeze rather than wrapping at the minimum and maximum -- the property manager could enforce all that. In addition, since the number of properties in the core tree will be very small (probably less than 1,000), we could add optional debugging information. For example, as a compile-time or runtime option, we could track the number of reads, writes, and ties (for weeding out unused properties, typos, etc.), and could even through an exception (as a crude breakpoint) when certain values are assigned to certain properties. All the best, David -- David Megginson [EMAIL PROTECTED] _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
