On Tuesday, June 18, 2002, at 02:38 am, David Megginson wrote:
>
> The node argument is as follows:
>
> 1. If the value of an existing property node has been modified, it is
> the node itself.
>
> 2. If a property has been added or removed, it is the property's
> parent.
Hmm, how is the listener meant to work this out? Seems like you'd be
better with a bigger interface (change / add_child / rmv_child) and
default { } impls so people can ignore changes the don't care about. For
the add / remove cases, you'd like to know the parent node and the child
node, I guess.
>
> To add a listener to a node (there's not yet any remove
> functionality), you simply use the SGPropertyNode::addChangeListener
> method:
>
> node->addChangeListener(this);
>
> The property manager automatically fires change events for non-tied
> properties; for properties with tied values, the subsystem to which
> the properties are tied must trigger change events manually with
>
> node->fireChangeEvent();
>
> (or not, as desired).
This seems like an opportunity for bugs, though I can't think of a
better solution either. Certainly this point needs to be emphasized,
otherwise there will be a situation where someone moves some code from
using non-tied to tied props (for whatever reason) and the behavior of
every system that depends on those properties subtly changes. This is a
worst case scenario, naturally ...
Just though of an extreme solution to this. In a debug build, the props
code could run a check each frame against the previous and current
values of every tied, event-listened prop (i.e not that many). If it
sees a value change without the event change being fired, it could log a
warning / error.
That's a lot of effort, though.
>
> This addition adds no measurable overhead (just a null pointer check)
> when listeners are not enabled; when they are enabled, the overhead
> will depend on the listeners.
Hmm, does this mean we're limited to one listener per node?
H&H
James
Anyone who considers arithmetical methods of producing random digits is,
of course, in a state of sin. -- John Von Neumann, 1951
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
