* Melchior FRANZ -- Sunday 22 February 2009:
To make listeners work as expected the solution is to make *listeners*
work as expected, not to change dialog-apply in a way that makes them
not work as expected. ;-)
This should now work. A dialog-apply change might come later. Or not.
(I'm still
* Melchior FRANZ -- 2/23/2009 10:18 AM:
the node value shall not be read twice
Disregard! You aren't doing that, and why should you?!
But also don't read the widget value twice, please. :-)
m.
--
Open Source Business
Hi Melchior,
you can find the patch with, I hope, the correct improvement you asked.
I wanted to add that I really agree your point of view: To make
listeners work as expected the solution is to make *listeners*
work as expected, not to change dialog-apply in a way that makes them
not work as
I object to the proposed change. (Reasons below.)
* Sébastien MARQUE -- 2/21/2009 2:39 AM:
In this script you'll find several listeners linked to several
properties that can be modified using instrument-failures.xml or
system-failures.xml.
Except that these are *not* change-only
* 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 ...
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
On Sat, Feb 21, 2009 at 11:32 AM, Melchior FRANZ mfr...@aon.at wrote:
setlistener(f ~ /serviceable, failure[f], 0, 0);
0 ... trigger on change only
As I wrote in my other email, this doesn't work as expected. The
listener is triggered initially even if the property doesn't change.
Yes, I will be obliged to check the value to avoid the instrument fix in
some cases. But as I discover this problem I wanted to try a solution
for every dialog-apply, to make the listeners work as expected, for
future uses, not only the failures system I'm trying to write.
If the fix is
On Sat, Feb 21, 2009 at 2:39 AM, Sébastien MARQUE seb.mar...@free.fr wrote:
no problem. I've attached a nasal script to put in whatever aircraft you
want. In this script you'll find several listeners linked to several
properties that can be modified using instrument-failures.xml or
Hi all,
I'm still trying to get failures implemented specifically for one
aircraft (before finding a better way for global solution). I've got a
problem with the dialogs instrument-failures.xml and
system-failures.xml, using the check boxes.
Indeed, it seems like the dialog-apply command
On Fri, Feb 20, 2009 at 1:23 AM, Sébastien MARQUE seb.mar...@free.fr wrote:
Indeed, it seems like the dialog-apply command changes every single
property linked to a checkbox causing the listeners set on these
properties to be triggered even if the property hadn't be changed by the
user. The
Hi Csaba,
actually I already use a listener that only fires then the value really
change. I've looked in Nasal scripting wiki page and globals.nas to be
sure, and tried the other possible values for the fourth argument of
setlistener, with no more succes, that's why I looked in FG sources. If
12 matches
Mail list logo
