Is there a simple way to detect a single-click-long-press event?

[bcelary]

I am wondering if there's an easy way (other than extending the library with new events) to detect a single-click followed by a long-press event, e.g. you double-click the button, but instead of letting go on the 2nd click you hold it and it triggers different action than long-press that is currently implemented.

[bxparks]

That's an interesting question. I'm not even sure that it should be called "double-click-long-press", because what would we call a "single-click-long-press"? Well that's just a normal LongPress. So what you call a "double-click-long-press" is actually a Click, followed quickly by a LongPress.

So I think this could be accomplished by creating an instance of IEventHandler that listens for kEventClicked, saves the current milliseconds for the clicked event, then listens for a kEventLongPressed, and checks whether that occurs within getClickDelay() getLongPressDelay() + getDebounceDelay() + some slop milliseconds after clickedEventMillis. If so, then this is your new event, which I still think is more accurately called "single-click-long-press".

I haven't verified any of this. Actual code needs to be written and verified.

[bcelary]

Thanks for the confirmation and a suggestion. I'll give it a try and report back (might take a while though as that's not super critical right now)

[bxparks]

If you code this up and it works, it will have a subtle bug. If you store the millis as a uint16, the counter will rollover after 65.536 seconds. So if you Click, then wait 65.536 seconds, then LongPress, then you will trigger this new event even though it should not. The same thing happens if you store millis as a uint32, it will rollover after 49.71 days. So a Click, followed by 49.71 days, followed by a LongPress will erroneously trigger this event.

The solution requires changing the core AceButton code, to add a new event type, let's call it kEventNull (maybe kEventReset, kEventIdle), which is triggered when nothing happens after some reasonable amount of time, say, 10-20 seconds. The downstream client code would use this event to reset any internal timers like yours.

If you actually code your IEventHandler and it works and you end up using it, I would be willing to implement this kEventNull (kEventReset) to fix that subtle bug.

Additional Note to My Future Self: The solution might as simple as adding an event dispatch in the existing AceButton::checkOrphanedClick() method. Maybe an orphaned Clicked is the only thing that that we need to worry about. Or it could be that a more general kEventReset event is required, to indicate that "nothing has happened in the last 10-20 seconds".

[bxparks]

By the way, I released v1.10 a few days ago which adds support for kEventHeartBeat. It is disabled by default. When enabled, the default kHeartBeatInterval is 5000 milliseconds, and is configurable like all other timing parameters.

The kEventHeartBeat will solve the problem of the orphaned Clicked event that I mentioned above. In your IEventHander, you would save the time stamp of the last kEventClicked. Then listen for the kEventLongPressed and kEventHeartBeat. In the kEventHeartBeat handler, if kEventClicked has been pending for too long (say 5 seconds), reset the pending kEventClicked so that a phantom kEventLongPressed does not cause accidentally trigger your custom kEventSingleClickedLongPressed event 65.535 seconds later.

[bxparks]

Forgot to add:

• README.md documentation here: https://github.com/bxparks/AceButton#HeartBeat
• example code here: https://github.com/bxparks/AceButton/tree/develop/examples/HeartBeat