question about delete and order

I’ve narrowed the TTA wonder bug down to an interaction between Delete and a TriggerAction.

If I remove the Delete, then the TriggerAction fires. But with the Delete in, the TriggerAction does not fire. Interestingly, if I add a ReportAction beside the TriggerAction that triggers on the same key, then the ReportAction DOES fire, which surprised me.

Here are the details.

Colossus Card includes AgeACivil prototype
AgeACivil prototype includes PickCard prototype

PickCard ctrl-A TriggerAction issues Ctrl BACKQUOTE
Colossus CTRL BACKQUOTE is the input key for a Delete on that card
BUT
AgeACivil ctrl-A TriggerAction is supposed to issue a alt-semicolon
But that triggeraction never happens.

If I remove the Delete trait, then the AgeACivil ctrl-a TriggerAction DOES happen.

Which makes me suspect that the Delete is happening before the AgeACivil ctrl-a TriggerAction, and so, since the card no longer
exists, the TriggerAction can’t happen.

I’ve tried changing the order–moving Delete to top or bottom, but it makes no difference.

Any suggestions?

Thanks!
Ken

Hmmm…yes. What you suspect is the logical reason. Changing the order in this case will not make a difference. The routine is flawed. It needs a controlling DP interacting with the routine to let it know what it should do - if true goto trigger, if false goto delete. To do this you will have to nest the existing routine with another Trigger/DP check and set routine

Thanks for the quick reply. By DP I assume you mean Dynamic Property? Do I really need to create a new DP for this? That seems convoluted.

What determines the order between a Delete and a TriggerAction on the same object (possibly in different prototypes)? I am seeing a ReportAction and GlobalKeyCommand both occurring before the Delete, but the Trigger Action after the Delete. What determines the order that traits fire?

yes DP = dynamic property

Certain traits�do not obey stacking trait order so their location within the
piece/prototype is irrelevant - this may be one of those cases and why I bring
up the DP need to bring order to the chaos :slight_smile:

In general as you look at the piece tree execution runs from bottom up as you
look at it.

i.e

Basic Piece

(Prototype A): Delete

(Prototype A): Marker

Trigger 1

(Prototype B): Rotate

(Prototype B): Layer

Report

GKC

Trigger 2

In this example Trigger 2 affects everything�where as Trigger 1 should only
affect the Delete and Marker trait.

You can try and fix your stack order according to this general rule but I don’t
think it’s going to matter though


From: fil512 ken.stevens@sympatico.ca
To: messages@vassalengine.org
Sent: Wed, July 28, 2010 8:09:56 AM
Subject: [messages] [Developers] Re: question about delete and order

Thanks for the quick reply.� By DP I assume you mean Dynamic Property? Do I
really need to create a new DP for this?� That seems convoluted.

What determines the order between a Delete and a TriggerAction on the
same object (possibly in different prototypes)?� I am seeing a
ReportAction and GlobalKeyCommand both occurring before the Delete, but
the Trigger Action after the Delete.� What determines the order that
traits fire?


Read this topic online here:
https://forum.vassalengine.org/t/question-about-delete-and-order/3127/3

Thanks tm. It sounds like you don’t know the answer to my question. Is there anyone else who lurks in these forums that knows the answer? Once again, my question is as follows.

What determines the order between a Delete and a TriggerAction on the same object (possibly in different prototypes)? I am seeing a ReportAction and GlobalKeyCommand both occurring before the Delete, but the Trigger Action after the Delete. What determines the order that traits fire?

Is there a list I can consult that shows the order? Is it determined by depth (i.e. would a chain of 3 triggers fire before a chain of 4 triggers)? Is it determined by type (as seems to be the case illustrated above)? How can I determine the order? I don’t want to just code a solution that works and leaves a big mess for the next guy. I want to code the “proper” solution.

Thanks!
Ken

No - I did answer your question.

What determines the order between Trait A and a Trait B on the same object
is its Stacking Order

Again, trait order work bottom up, as explained here
https://forum.vassalengine.org/t/trait-order-in-counters/126/1

There is no other determining factor.
BUT there are exceptions and you’ve come across one

Namely, Triggers do not obey stack order and Report Actions do not obey
stack order. If the key that implements them is picked up by the keylistener

  • they will execute - thats just how they work

There is no list. It’s just something you learn building modules

-----Original Message-----
From: messages-bounces@vassalengine.org
[mailto:messages-bounces@vassalengine.org] On Behalf Of fil512
Sent: Wednesday, July 28, 2010 12:49 PM
To: messages@vassalengine.org
Subject: [messages] Edit: [Developers] Re: question about delete and order

[This message has been edited.]

Thanks tm. It sounds like you don’t know the answer to my question. Is
there anyone else who lurks in these forums that knows the answer? Once
again, my question is as follows.

What determines the order between a Delete and a TriggerAction on the
same object (possibly in different prototypes)? I am seeing a
ReportAction and GlobalKeyCommand both occurring before the Delete, but
the Trigger Action after the Delete. What determines the order that
traits fire?

Is there a list I can consult that shows the order? Is it determined by
depth (i.e. would a chain of 3 triggers fire before a chain of 4
triggers)? Is it determined by type (as seems to be the case
illustrated above)? How can I determine the order? I don’t want to
just code a solution that works and leaves a big mess for the next
guy. I want to code the “proper” solution.

Thanks!
Ken


Read this topic online here:
https://forum.vassalengine.org/t/question-about-delete-and-order/3127/5

tm,

Thanks for your patience with me. I still have much to learn about VASSAL module programming. That post you sent me was helpful. It should be a part of the “Game Piece” page in the Reference Manual. Is anyone maintaining the Reference Manual?

I guess I didn’t formulate my question clearly enough and that’s why you feel like it’s been answered. Let me try a more precise formulation:

There are 34 different types of traits, starting with Basic Piece and ending with Set Global Property. There are four different “entry points” into a piece:

  1. A player can select it by left-clicking it.
  2. A player can trigger a pop-up menu of choices by right-clicking on it.
  3. A player can type a keystroke that the piece is listening for.
  4. The engine can fire a keystroke that the piece is listening for.

In each those four different entry points, which of the 34 traits are involved? For a particular entry point, and the traits that are involved in that entry point, in which order are the traits executed?

Not knowing the answer to these questions makes it hard to program in VASSAL. It sounds like you are recommending determining the answer to my question by trial and error, “learn by building modules”. But if I take the trial and error approach, I’ll probably end up coding all sorts of stuff unnecessarily, and my resulting module will be complex and difficult for maintainers to support. In order to create a nice clean module, I need to know the rules of the VASSAL programming language.

From what I’ve seen working with it so far, I get the sense there are 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.

Ok I see what your getting at better.
Your 4 entry points - Im not sure what #1 is/does, a piece doesnt do anything just by left clicking it unless it is invoking an Action Button which invokes a Key command to initiate something (or do you mean dragging)

#2 is no different than #3 that is just how you interface - it is their key command that initiates the action
#4 cannot happen without some sort of initiation previously from 1-3 above - something told it to do it :slight_smile: If #4 is the cause, you need to widen the scope to find out where it came from to understand the reason why

Which of the traits are involved? I’ve d/l and will look, this requires plain old fashion detective work to figure out what is trying to be done (Need to find the original sequence description first so I know where to start)

Programming is different from Modding - which one is it your wanting to do ?

Delete vs Trigger problem. Something to consider here. A Delete trait employs an active key command, but a Trigger trait can be employed in two different ways, active (using only the key command field) or passive (using only the listen for keystroke field).
Perhaps this may be why you are seeing the Delete occur before the Trigger if the trigger is using a passive key instead of an active key.

Tim,

Thanks for offering to help. I posted details to the problem on the following forum.

viewtopic.php?f=8&t=3203

Now onto your response. The reason I mentioned clicking is that it seems to me there is a concept of a “selected” piece. E.g. when you hit a keystroke, I believe that the keystroke is sent to the selected piece. I thought the way you selected a piece was by clicking on it. E.g. if you left-click on a card and then press ctrl-a, it will add THAT card to your hand. If you left-click on a different card, then the ctrl-a will apply to that card instead. There will often be logic in a prototype that fires conditionally based on attributes of a piece; the values of those attributes, I assume, is based on the left-click selection of that piece.

That is why I assumed that #2 and #3 are different. After writing that, it occurred to me that there’s a #5 which is dragging the piece.

The reason I broke out #3 and #4 is it seems to me there are plenty of places in the code where there is a keystroke trigger for a key that it is assumed will be pressed by the engine and not a player (a dumb way to call a function IMO but that’s a separate topic.)

On the programming vs. modding topic, I understand that supporting the VASSAL engine is different work from supporting a module. But I would call both programming, it’s just that in the former you’re programming in the functional programming language of Java whereas in the latter you’re programming in the declarative language VASSAL. Java has a very clear instruction manual. If you want to know what order things happen in Java, it’s very clearly documented. Things also happen in a specific order in the VASSAL programming language, but I’ve been having trouble finding the documentation that will tell me what order key listeners will execute in. But whether it’s programming or modding I guess is a semantic debate.

I had a look at the code and it looks to me like the “active” and “passive” keys in a TriggerAction are treated identically.

From TriggerAction.java:

[code]
public Command myKeyEvent(KeyStroke stroke) {
/*
* 1. Are we interested in this key command? Is it our command key? Does it
* match one of our watching keystrokes?
*/
boolean seen = false;
if (key.equals(stroke)) {
seen = true;
}

for (int i = 0; i < watchKeys.length && !seen; i++) {
  if (watchKeys[i].equals(stroke)) {
    seen = true;
  }
}[/code]

If it helps in your troubleshooting, I’ve uploaded the output of vassal-module-analyzer for TTA. It prints out all the traits in a human-readable, searchable format as well as lists all key senders and key listeners by key. (I wrote vassal-module-analyzer last week in order to wrap my head around this wonder problem–for more details on it, see my other posts in the forum.)

Thus spake fil512:

Thanks for your patience with me. I still have much to learn about
VASSAL module programming. That post you sent me was helpful. It
should be a part of the “Game Piece” page in the Reference Manual. Is
anyone maintaining the Reference Manual?

Last I checked, Ed Massena said the next version was nearly ready.

Not knowing the answer to these questions makes it hard to program in
VASSAL. It sounds like you are recommending determining the answer to
my question by trial and error, “learn by building modules”. But if I
take the trial and error approach, I’ll probably end up coding all sorts
of stuff unnecessarily, and my resulting module will be complex and
difficult for maintainers to support. In order to create a nice clean
module, I need to know the rules of the VASSAL programming language.

The more discussions I see of the way that traits work, the more I think
that we need to overhaul it to make it more consistent…


J.

In each those four different entry points, which of the 34 traits are
involved?

It doesn’t matter which entry point. And almost all of them are involved
depending on the keystroke.

For a particular entry point, and the traits that are
involved in that entry point, in which order are the traits executed?

If you’re looking at the list of traits in the editor, it goes from bottom
up. There are some exceptions, however. Triggers are always done last and
I believe that Reports are done last.

Not knowing the answer to these questions makes it hard to program in
VASSAL. It sounds like you are recommending determining the answer to
my question by trial and error, “learn by building modules”.

Experience is invaluable. Also looking at other people’s examples.

From what I’ve seen working with it so far, I get the sense there are
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.

There is no difference.

You mention TriggerAction and ReportAction as being exceptions, but I
count at least 9 different traits that listen for keystrokes.

Actually, almost all of them do. Off the top of my head, I can’t think of
one that doesn’t.

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.

Triggers are usually fired last. All the others are triggered from the
bottommost in the list to the topmost in that order.

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.

Triggers are an exception to the rule.

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.)

Trigger is last. This is because it waits for the state of the change to be
finalized before checking whether the trigger can be fired.

Hope this helps.

  • M.

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:
question about delete and order - #7 by fil512


messages mailing list
messages@vassalengine.org
vassalengine.org/mailman/listinfo/messages







In each those four different entry points, which of the 34 traits are

involved? �

It doesn’t matter which entry point. And almost all of them are involved depending on the keystroke.

For a particular entry point, and the traits that are

involved in that entry point, in which order are the traits executed?

If you’re looking at the list of traits in the editor, it goes from bottom up.� There are some exceptions, however.� Triggers are always done last and I believe that Reports are done last.




Not knowing the answer to these questions makes it hard to program in

VASSAL. �It sounds like you are recommending determining the answer to

my question by trial and error, “learn by building modules”. �

Experience is invaluable.� Also looking at other people’s examples.



From what I’ve seen working with it so far, I get the sense there are

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.

There is no difference.�


You mention TriggerAction and ReportAction as being exceptions, but I
count at least 9 different traits that listen for keystrokes. �

Actually, almost all of them do.� Off the top of my head, I can't think of one that doesn't.
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. �

Triggers are usually fired last.� All the others are triggered from the bottommost in the list to the topmost in that order.
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. �

Triggers are an exception to the rule.
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.)

Trigger is last.� This is because it waits for the state of the change to be finalized before checking whether the trigger can be fired.

Hope this helps.

- M.

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:
https://forum.vassalengine.org/t/question-about-delete-and-order/3127/7
_______________________________________________
messages mailing list
[messages@vassalengine.org](mailto:messages@vassalengine.org)
[vassalengine.org/mailman/listinfo/messages](http://www.vassalengine.org/mailman/listinfo/messages)




Maybe I’m missing what it is you are trying to accomplish with having a
delete trait and a trigger trait fire on the same keystroke, but this
behavior I would expect out the delete trait. If you delete a piece you are
telling to the module to remove it completely and make it unable to be
referenced for the rest of that session and save files. I would think delete
would take precedence over other traits just to be sure it couldn’t cause
any undo issues like infinite loops on key strokes or circular references
generating errors.

Perhaps what you are looking for is an invisible piece that can act as a
proxy for the trigger actions and send the delete keystroke to the real
piece when needed.

-----Original Message-----
From: messages-bounces@vassalengine.org
[mailto:messages-bounces@vassalengine.org] On Behalf Of Tim M
Sent: Wednesday, July 28, 2010 7:44 PM
To: messages@vassalengine.org
Subject: [messages] [Developers] Re: question about delete and order

Ok I see what your getting at better.
Your 4 entry points - Im not sure what #1 is/does, a piece doesnt do
anything just by left clicking it unless it is invoking an Action Button
which invokes a Key command to initiate something (or do you mean
dragging)

#2 is no different than #3 that is just how you interface - it is their
key command that initiates the action
#4 cannot happen without some sort of initiation previously from 1-3
above - something told it to do it :slight_smile: If #4 is the cause, you need to
widen the scope to find out where it came from to understand the reason
why

Which of the traits are involved? I’ve d/l and will look, this requires
plain old fashion detective work to figure out what is trying to be done
(Need to find the original sequence description first so I know where to
start)

Programming is different from Modding - which one is it your wanting to
do ?

Delete vs Trigger problem. Something to consider here. A Delete trait
employs an active key command, but a Trigger trait can be employed in
two different ways, active (using only the key command field) or passive
(using only the listen for keystroke field).
Perhaps this may be why you are seeing the Delete occur before the
Trigger if the trigger is using a passive key instead of an active key.


Read this topic online here:
https://forum.vassalengine.org/t/question-about-delete-and-order/3127/8

I agree with you that consistency is the best route whenever possible.

However, there are probably good, practical reasons why VASSAL has made exceptions to consistent trait order execution. But if you are going to make exceptions, then you really need to write down the rules for people so we know how it works. Otherwise module designers will code via trial and error, and guesswork which will result in them feeling frustrated and it will also result in convoluted modules. I’m really happy to hear that someone is working on updating the Reference Manual. That’s hard work, but the benefits to the community will be enormous.

Thanks for all the help with this. Sorry that I sound like a broken record about the question of trait order execution. I feel that it’s important that it be clear to module designers how it works.

It sounds like you’re guessing. How can I get a definitive answer to my question?

Here are some traits that don’t listen for keystrokes:
Action Button
Does not stack
Non-Rectangular
Area of Effect
Sub-Menu
Restrict Commands
Restricted Access
Marker

This sounds like another guess. Is there a forum post maybe somewhere that definitively answers the question about trait execution order?

Are they the only exception? Does this apply to both the watch keys and the key command for the trigger? What about Report Action? Are they last too? Which is laster?

Not trying to be a pain in the ass, just seeking to understand,
Ken

I think it’s extremely dangerous to change things. It may be possible to
deprecate inconsistent features.

It mostly makes sense.

However, there is a feature that I’ve used that only sort of works that
doesn’t make a whole lot of sense. If two traits respond to the same key
event, they will both respond, but some traits do not check the inner trait
to see if anything else will respond. And I don’t mean the “restrict
commands” trait which is obvious. I’ll see if I can find the one I mean –
i.e., it will respond to the keystroke, but nothing above it will. That
drives me nuts.

Another inconsistent feature is traits that check for properties. Some
check for property names starting from
getOutermost(this).getProperty(propName). Others only check property names
starting from getInner().getProperty(propName). That also drives me nuts.

And kids that walk on my lawn. They drive me nuts too.

  • M.

On 29 July 2010 13:32, fil512 ken.stevens@sympatico.ca wrote:

“uckelman” wrote:

Thus spake fil512:
The more discussions I see of the way that traits work, the more I
think
that we need to overhaul it to make it more consistent…

I agree with you that consistency is the best route whenever possible.

However, there are probably good, practical reasons why VASSAL has made
exceptions to consistent trait order execution. But if you are going to
make exceptions, then you really need to write down the rules for people
so we know how it works. Otherwise module designers will code via trial
and error, and guesswork which will result in them feeling frustrated
and it will also result in convoluted modules. I’m really happy to hear
that someone is working on updating the Reference Manual. That’s hard
work, but the benefits to the community will be enormous.

I think it’s extremely dangerous to change things.� It may be possible to deprecate inconsistent features.

It mostly makes sense.�

However, there is a feature that I’ve used that only sort of works that doesn’t make a whole lot of sense.� If two traits respond to the same key event, they will both respond, but some traits do not check the inner trait to see if anything else will respond.� And I don’t mean the “restrict commands” trait which is obvious.� I’ll see if I can find the one I mean – i.e., it will respond to the keystroke, but nothing above it will.� That drives me nuts.


Another inconsistent feature is traits that check for properties.� Some check for property names starting from getOutermost(this).getProperty(propName).� Others only check property names starting from getInner().getProperty(propName).� That also drives me nuts.


And kids that walk on my lawn.� They drive me nuts too.�

- M.

On 29 July 2010 13:32, fil512 <ken.stevens@sympatico.ca> wrote:


"uckelman" wrote:
Thus spake fil512:
The more discussions I see of the way that traits work, the more I
think
that we need to overhaul it to make it more consistent...



I agree with you that consistency is the best route whenever possible.

However, there are probably good, practical reasons why VASSAL has made
exceptions to consistent trait order execution. �But if you are going to
make exceptions, then you really need to write down the rules for people
so we know how it works. �Otherwise module designers will code via trial
and error, and guesswork which will result in them feeling frustrated
and it will also result in convoluted modules. �I'm really happy to hear
that someone is working on updating the Reference Manual. �That's hard
work, but the benefits to the community will be enormous.

Thus spake Michael Kiefte:

I think it’s extremely dangerous to change things. It may be possible to
deprecate inconsistent features.

I’m not suggesting that we change the behavior of existing features without
providing some kind of versioning for them.

However, there is a feature that I’ve used that only sort of works that
doesn’t make a whole lot of sense. If two traits respond to the same key
event, they will both respond, but some traits do not check the inner trait
to see if anything else will respond. And I don’t mean the “restrict
commands” trait which is obvious. I’ll see if I can find the one I mean –
i.e., it will respond to the keystroke, but nothing above it will. That
drives me nuts.

Another inconsistent feature is traits that check for properties. Some
check for property names starting from
getOutermost(this).getProperty(propName). Others only check property names
starting from getInner().getProperty(propName). That also drives me nuts.

If you want to track those down and fix them, go for it. At the rate I’m
going with all the web site stuff, I’ll get to problems like this myself
shortly after the sun burns out.


J.

C,

What I’m trying to do is fix a bug in someone else’s module. It’s a monster module with over 5000 traits (Through the Ages). As someone completely new to VASSAL, I’ve probably bitten off more than I can chew here, but I am confident that if I can just learn the rules that govern trait execution that I WILL be able to fix this bug. It’s been harder than I expected to learn the rules that determine the order traits are executed in. I keep hearing about general rules, and then guesses at exceptions to those rules, but no-one seems to really know how it works. For example, above you write, “I would think delete would take precedence over other traits.” You’re making a guess when you say this. Programming shouldn’t be about guesswork. The rules about how VASSAL works should be clear: no guessing; so we can all just get on with the business of building modules.

Your suggestion to use an invisible piece is intriguing. Someone earlier suggested I use a Dynamic Property. There are probably other ways to skin this cat too. But I want to pick the “proper” solution. And in order to do that, I need to know the rules that govern trait order execution. Surely someone in the VASSAL community knows the answer to that question without guessing… Anybody?

Ken

“mkiefte” wrote:

If you’re looking at the list of traits in the editor, it goes from
bottom
up. There are some exceptions, however. Triggers are always done
last and
I believe that Reports are done last.

It sounds like you’re guessing. How can I get a definitive answer to my
question?

I’ve looked at that code a lot. I wasn’t definitive on Report Actions,
because I’ve never cared about that trait in the past.

Here are some traits that don’t listen for keystrokes:
Action Button
Does not stack
Non-Rectangular
Area of Effect
Sub-Menu
Restrict Commands
Restricted Access
Marker

Ah, well, there you go. But certainly more than 8. And Restrict Commands
does listen for keystrokes.

This sounds like another guess. Is there a forum post maybe somewhere
that definitively answers the question about trait execution order?

It’s not a guess.

Are they the only exception? Does this apply to both the watch keys and
the key command for the trigger? What about Report Action? Are they
last too? Which is laster?

The default is to do your action first and then check for inner traits
(traits that are higher up on the list). Trigger does all the inner
(higher) traits first and then does it’s action(s) which may fire other
triggers which will be after that, etc. Reports are done after the
keystroke that it’s reporting is done. Between reports and triggers,
whichever is higher in the list will go first – i.e., it will be the
reverse of the normal procedure.

Not trying to be a pain in the ass, just seeking to understand,
Ken

No problem. I get the impression you’ve looked at the Java code. You will
learn an awful lot that way. I’ve looked at a lot of programs in my life and
I have to say, that documentation lies a lot, but code never lies.

And I’m more than happy to answer questions about the Java code.

  • M.





“mkiefte” wrote:


If you're looking at the list of traits in the editor, it goes from
bottom
up. �There are some exceptions, however. �Triggers are always done
last and
I believe that Reports are done last.



It sounds like you're guessing. �How can I get a definitive answer to my
question?

I've looked at that code a lot.� I wasn't definitive on Report Actions, because I've never cared about that trait in the past.



Here are some traits that don't listen for keystrokes:
Action Button
Does not stack
Non-Rectangular
Area of Effect
Sub-Menu
Restrict Commands
Restricted Access
Marker

Ah, well, there you go.� But certainly more than 8.� And Restrict Commands _does_ listen for keystrokes.



This sounds like another guess. �Is there a forum post maybe somewhere
that definitively answers the question about trait execution order?

It's not a guess.



Are they the only exception? �Does this apply to both the watch keys and
the key command for the trigger? �What about Report Action? �Are they
last too? �Which is laster?

The default is to do your action first and then check for inner traits (traits that are higher up on the list).� Trigger does all the inner (higher) traits first and then does it's action(s) which may fire other triggers which will be after that, etc.� Reports are done after the keystroke that it's reporting is done.� Between reports and triggers, whichever is higher in the list will go first -- i.e., it will be the reverse of the normal procedure.


Not trying to be a pain in the ass, just seeking to understand,
Ken

No problem.� I get the impression you've looked at the Java code.� You will learn an awful lot that way. I've looked at a lot of programs in my life and I have to say, that documentation lies a lot, but code never lies.

And I'm more than happy to answer questions about the Java code.

- M.

Think we went over that once before, the problem iirc is not that it can’t be fixed to act in a consistent way, it’s that modules might break after if they depend on the way things work now.

Heres a simple example:

Today you might have a stack order like this -

BasicPiece
Report Action, CTRL B, output “Hello”
Trigger Action, inkey CTRL A, outkey CTRL B, CTRL C
Report Action, CTRL B, output “World”
Report Action, CTRL C, output “End of Routine”

when we execute the CTRL A we get the output in the chat window as follows

World
Hello
End of Routine

thasts not quite right, so to fix we reverse the 2 CTRL B reports

BasicPiece
Report Action, CTRL B, output “World”
Trigger Action, inkey CTRL A, outkey CTRL B, CTRL C
Report Action, CTRL B, output “Hello”
Report Action, CTRL C, output “End of Routine”

and when we run again we now get

Hello
World
End of Routine

it works - but now if we leave it like it is and fix all traits to respect stack order properly we would only get

World

which is breaking the way things work today and to fix properly we would have to reorg the entire stack like so

BasicPiece
Report Action, CTRL C, output “End of Routine”
Report Action, CTRL B, output “World”
Report Action, CTRL B, output “Hello”
Trigger Action, inkey CTRL A, outkey CTRL B, CTRL C

Now ideally everything should be organized like the last example and work that way, but unfortunately it’s not and/or doesn’t

I agree with Mike, that change could be dangerous