> From: Erik Hofman
> Jim Wilson wrote:
> > Hmmm...so why would that make a difference on the pui end? It makes more
> > sense that the requirement of an active read (that
> is bound to a subsystem owned getter) would be the cause of no on screen
> update. I don't think the pui would care who owns the
> value, does it? Sorry I haven't looked at the code and don't have time to
> > Actually I'm now wondering why we don't just do a once per frame refresh of
> > the browser so that the display always updates
> per frame (only while that dialog is displayed). It wouldn't cost all that
> much and would certainly increase the utility of the
> Curtis is right, the property browser uses a callback function provided
> by the property code which is only called for properties that don't use
> the Tie() function (It has been discussed in the past to add the same
> functionality for all properties but it either requires C++ operator
> mangling or a function that checks for a change every frame).
Actually it is a change listener. Maybe I misunderstood what Curt was saying,
but AFAIK the "Tied" properties you speak of are bound to subsystem defined
getters/setters not C++ variables. Of course, probably there is something else
I'm not aware of.
Regarding property picker refresh, on further reflection probably an N times
per second approach to refreshing the widget would be better than per frame.
Anyone interested could perhaps make gui.cxx into a proper flightgear subsystem
and do it from there.
Flightgear-devel mailing list