187
edits
Howto talk:Development of the CDU: Difference between revisions
Jump to navigation
Jump to search
Howto talk:Development of the CDU (view source)
Revision as of 13:16, 4 December 2010
, 4 December 2010→Implementing LSK logics
| Line 47: | Line 47: | ||
I think, we actually talked about this previously on the forums. Instead of using lots of nested XML logics to model a CDU (or any complex instrument), it is actually better to just use the property tree for communicating "events" (e.g. button presses). This would then make it possible for a Nasal script to handle ALL logics (using a registered listener), so that a FSM (finite state machine) can be implemented in Nasal space, this is more flexible than a purely XML-based approach, and could also be more easily reused by other aircraft and developers. My personal suggestion would be to refrain from modeling advanced logics in XML space, while it is certainly possible to do so to a certain degree, the corresponding building blocks are relicts from an era where Nasal scripting was not yet available.--[[User:Hooray|Hooray]] 22:31, 2 December 2010 (UTC) | I think, we actually talked about this previously on the forums. Instead of using lots of nested XML logics to model a CDU (or any complex instrument), it is actually better to just use the property tree for communicating "events" (e.g. button presses). This would then make it possible for a Nasal script to handle ALL logics (using a registered listener), so that a FSM (finite state machine) can be implemented in Nasal space, this is more flexible than a purely XML-based approach, and could also be more easily reused by other aircraft and developers. My personal suggestion would be to refrain from modeling advanced logics in XML space, while it is certainly possible to do so to a certain degree, the corresponding building blocks are relicts from an era where Nasal scripting was not yet available.--[[User:Hooray|Hooray]] 22:31, 2 December 2010 (UTC) | ||
Sorry, I just caught up with this discussion. Again in the A380 MCDU, I separate out the two lifecycle stages, there is a action/render stage and a input stage. | |||
For the action/render stage I have a single dispatch("action"); method in my Nasal, this is called when you click on an action button, so it gets all the data ready for the render stage and then changes pages. | |||
When you click on a input field, it calls selectField("field") which just sets a property called "current-field". | |||
So when you click on the aircraft keyboard it calls a keyPress("key"); function in my mcdu.nas Nasal, this builds the string and sets a property value for whatever the current-field is. | |||
In your case, the selectField is done by pressing the LSK, so this needs a little bit of indirection, you could have an array of properties with the name of the field that maps to the index of the LSK. The LSK has two functions, one to select an action (such as "insert") and one to select an input field before you enter some data. | |||
[[User:Scotth1|Scotth1]] 13:16, 4 December 2010 (UTC) | |||
= Implementing a finite state machine in Nasal = | = Implementing a finite state machine in Nasal = | ||