I’m getting some unexpected results when running the following code:
to openRunControl options
(* Determine pc, make sure navigator view is open *)
log options
...
if options's tac_fu_sw is not empty
set options's tac_fu_sw to options's tac_fu_sw &&& (rc_stay_open: true)
openTacFuSw options's tac_fu_sw
end if
...
End openRunControl
to openTacFuSw options
...
Log options
set the duplicatepropertykeymode to last //stay_open will overwrite old stay_open intended for run control dialog
openRunControl (stay_open:true) &&& options
log (stay_open:true) &&& options
Click "run control/tac fu sw"
...
if options's rc_stay_open is empty or options's rc_stay_open is false
closeRunControlDialog
end if
end openTacFuSw
openRunControl is called like this: openRunControl (battery_activate:(all:“enable”), dpaps:“applied”, perm_to_fire:“ic”, tac_fu_sw:(all:“ready”), tactical_trigger:“depressed”)
and produces these log messages:
[quote=“log”]2011-02-09 12:03:10.156 -0500 log (battery_activate:(all:“enable”), dpaps:“applied”, perm_to_fire:“ic”, tac_fu_sw:(all:“ready”), tactical_trigger:“depressed”)
…
2011-02-09 12:03:13.126 -0500 log ((all:“ready”),(rc_stay_open:“true”))
2011-02-09 12:03:13.173 -0500 log ((stay_open:“true”),(all:“ready”),(rc_stay_open:“true”))
…
2011-02-09 12:03:16.194 -0500 log ((stay_open:“true”),(all:“ready”),(rc_stay_open:“true”)) [/quote]
I don’t understand why the &&& operator is producing nested lists. This is not the behavior i see in the manual’s examples (although those examples are with normal lists and not property lists).
As a workaround, i tried replacing the line
openRunControl (stay_open:true) &&& options
with
replace property (stay_open: true) of options
openRunControl options
And I got the following error:
Why wouldnt options be modifiable?
Thanks for any help.