Followup question about event triggers

Suppose I have something like this:

      case EVENTID(BUTTON_AUX, EVENT_CLICK_SHORT, MODE_ON):
        SaberBase::DoBlast();
        return true;

      case EVENTID(BUTTON_AUX, EVENT_SECOND_HELD_MEDIUM, MODE_ON):
        if (SaberBase::GetColorChangeMode() == SaberBase::COLOR_CHANGE_MODE_NONE) {
          ToggleColorChangeMode();
          return true;
        }
        break;

If EVENT_CLICK_SHORT returns true, does this mean EVENT_SECOND_HELD can’t be triggered?

no. as soon as you return, it’s back to polling events for what’s next.

Sorry, can you clarify? Do you mean:

  1. “No, if EVENT_CLICK_SHORT returns true then EVENT_SECOND_HELD_MEDIUM is never triggered,” or
  2. “No, that’s wrong, if you return true then it goes back to polling events and will still detect EVENT_SECOND_HELD_MEDIUM when it happens?”

Also, it is the same for any return statement, regardless of whether it’s true or false?

The no was an answer to your question of

The event happens, your blast happens, we return, then we’re done and go back to listening for another event.
If the EVENT_SECOND_HELD_MEDIUM then occurs, then that case is used in the same way.
You could swap the order of the cases in the list and it would make no difference. Hope that clarifies.

Yes

Sounds like 2, then. So the code I’ve posted above means that if I double-click and hold aux, it will first trigger a blast and then enter the color wheel, correct?

no, it holds off a moment before sending the CLICK_SHORT while it waits to see if there’s a second click. This is what allows you to go past first clicks to get to subsequent clicks without triggering everything along the way.

I thought it only did that for EVENT_CLICK_SAVED_SHORT ?

This is the wrong question.
*_HELD events happen before CLICK events.
HELD events happens while the button is still held, click events happen when the button is released. (Or a bit after in the case of saved clicks.)

The order of events are:

  1. PRESSED
  2. HELD
  3. HELD_MEDIUM
  4. HELD_LONG
  5. RELEASED
  6. CLICK_SHORT/LONG

If any of these events return true, then any following HELD or CLICK events are not generated.

Well, not exactly in this case, right? I’m specifically talking about holding the second press via EVENT_SECOND_HELD, so I would assume that EVENT_CLICK_SHORT gets executed on the first press before EVENT_SECOND_HELD ever happens. The question was whether returning true in EVENT_CLICK_SHORT on that first click prevents EVENT_SECOND_HELD from executing.

My assumption until now has been that both will still execute, but you said once an event has returned true, it won’t trigger more events, so I wanted to confirm.

Good point, and an interesting question.
It looks like the second press will re-enable all events, so second click/held events will be generated regardless of whether Event2 returns true or false. It occurs to me that this might be something we might want to change in the future though. Not sure if anybody depends on that behavior or not currently.

The primary purpose of the “returning true stops further events” is to prevent modifier keys from generating events. Like if you hold ALT, then click POWER, it would be silly if the alt button then generated a long click as well, but since there is no such thing as a double-click modifier, perhaps the current behavior is ok.

1 Like

That makes sense. For what it’s worth, the prop file I’ve devised relies on the current behavior. I’m not quite finished with it, it needs some refinement to the volume menu and I might want to borrow Fett263’s color zoom function, but the basic controls are finalized. I’m attaching it here in case anyone’s interested. The commented section at the beginning describes how it’s supposed to work.
saber_caiwyn_buttons.h (15.4 KB)