* 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 stil
Hey,
* Sébastien MARQUE -- 2/23/2009 11:01 PM:
> you can find the patch with, I hope, the correct improvement you asked.
Yes, thanks. I do currently not have access to my machine, but will commit
in a few days if nobody is quicker. (Temporary variable names with a
scope of just three lines should
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
* 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
* Sébastien MARQUE -- 2/20/2009 1:23 AM:
> This is not new, it was the case with the precedent gui dialog, and I
> used a Nasal workaround but not really useful as it disallows to come
> back to a previous state.
I've written a lot of dialogs, the most complicated ones among them,
and I don't re
* Sébastien MARQUE -- 2/21/2009 7:05 PM:
> 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,
To make listeners work as expected the sol
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 rejecte
On Sat, Feb 21, 2009 at 11:32 AM, Melchior FRANZ 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.
Sébastien,
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 liste
* 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
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 listene
On Sat, Feb 21, 2009 at 2:39 AM, Sébastien MARQUE 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
> system-failures.xml.
>
>
Hi Csaba,
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
system-failures.xml.
Then open the Equipment -> Instrument failures dialog
On Fri, Feb 20, 2009 at 8:46 AM, Sébastien MARQUE wrote:
>
> 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 n
Hi,
attached the patch to apply only the changed values in a dialog box
using dialog-apply fgcommand. Now only the listener(s) associated with
the changed value are fired. It works fine here, and I think it could be
useful to apply it.
Thanks a lot
regards
seb
Sébastien MARQUE a écrit :
H
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
On Fri, Feb 20, 2009 at 1:23 AM, Sébastien MARQUE 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 result is that
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 cha
18 matches
Mail list logo
