Hi Csaba and Melchior,
oops, sorry, I've made a mistake attaching the failures.nas script, but
please believe me that I've first tried
setlistener(f ~ "/serviceable", failure[f], 0, 0);
in order to behave as written in setlistener doc (wiki and globals.nas).
I've just write back to correct listeners args (0 ,0), and unapply patch
but here is the result, I only unchecked Airspeed Indicator, in
Instrument Failures dialog, then use the "Apply" button:
airspeed indicator failure
altimeter failure
turn indicator failure
slip-skid ball failure
heading indicator failure
vertical speed indicator failure
which is not correct. With the small patch applied, correct listeners
args (0, 0) and unchecking Airspeed Indicator again:
airspeed indicator failure
which is correct. I think that it wasn't discovered before (was it?)
because nobody has put several listeners on several properties contained
in one single dialog, or maybe it has no effects (tests on property
value as I've done myself before searching to modify dialog-apply?). I
don't think that the dialog is broken, but for me the dialog-appply
command is.
Reading the code about dialog-apply fgcommand I've seen that every
<object-name> is copied in dialog.cxx, FGDialog::applyValues
for (unsigned int i = 0; i < _propertyObjects.size(); i++) {
const string &name = _propertyObjects[i]->name;
if (objectName && name != objectName)
continue;
copy_from_pui(_propertyObjects[i]->object,
_propertyObjects[i]->node);
}
independantly of changes, so I thought that it was maybe the reason for
listeners to be fire up.
best regards
seb
Melchior FRANZ a écrit :
> * Melchior FRANZ -- 2/21/2009 9:33 AM:
>> You should have used:
>>
>> setlistener(f ~ "/serviceable", failure[f], 0, 1);
>
> Whoops. Of course, I meant:
>
> setlistener(f ~ "/serviceable", failure[f], 0, 0);
>
>
> The meaning of the first optional argument is:
>
> 0 ... just attach (default)
> 1 ... attach and run initially
>
> and that of the second is:
>
> 0 ... trigger on change only
> 1 ... trigger on writing -- independent of value (default)
> 2 ... trigger on writing to node or children, as well
> as addition and removal of children
>
>
> BTW: We might decide at some point that we only want to dialog-apply
> if values changed, but this needs more consideration, and one broken
> dialog isn't enough reason to convince me. ;-)
>
> BTW2: dialog-{apply,update} should handle an arbitrary number
> of <object-name>, not just one.
>
> m.
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
