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 must matter.  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

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