No subject

Thu Jul 22 06:11:08 MST 2010

two distinct pathways through a piece.  If the entry point is mouse
clicking (selecting), then it behaves in the way described in that post
you sent me.  If, however, the entry point is a keystroke, then I get
the sense a completely different set of rules apply.

You mention TriggerAction and ReportAction as being exceptions, but I
count at least 9 different traits that listen for keystrokes.  Some of
those determine whether a keystroke makes it to another trait, and in
those cases order could matter (or it could be that those "Restrict"
type traits apply to all other traits in the piece irrespective of
order).  From trial and error, so far I've determined that ReportAction
and GlobalKeyAction both fire before Delete actions, but TriggerActions
fire after delete actions.  This suggests that there is a list.  A list
that determines the order in which key listening traits fire when there
are multiple traits on the same piece listening for the same keystroke. 
I confirmed that Delete happens before TriggerAction by moving the
Delete above TriggerAction and then below TriggerAction and in both
cases the Delete prevented the TriggerAction.  But when I removed the
Delete alltogether, then the TriggerAction happened.  Why did Delete
take precedence over TriggerAction in this case?  Why is Delete higher
than TriggerAction on the list?  ("The list" being the order in which
key-based traits are executed when multiple traits on a single piece
listen for the same key.)

I hope that this clarifies my question.  I am probably making a number
of mistakes in the way I formulate my question because I am still
learning how VASSAL works.  I look forward to further enlightenment.

Read this topic online here:

More information about the messages mailing list