This is more of an off-topic question, but it is about programming. Since the car player software and HiJack both also deal with long and short button presses, I hope someone can lend a hand here.

I'm overseeing a project for which we need to implement long button press timing and logic into a design that was originally centered around short presses (and short presses with repeat)

The input comes from a remote control and the hardware produces three signals when a button is pressed.

When the button is first depressed it sends signal 1
While the button is being held it sends signal 2
When the button is released it sends signal 3

I'm looking for some logic to allow for short and long press support similar to how it's used from the UI on the player and many other consumer electronics devices. A long press should not first execute the function of a short press before starting on its own function for example (similar to a single button being used for both Next Track and Fast Forward).

Any help greatly appreciated.

Bruno

The general idea is to record the time of button-down, then on button-up find how long it's been held down. If it's over your threshold, do the long thing, otherwise do the short thing.

That doesn't help, though, if you want to do something like hold-to-fast-forward, though. I suppose there you'd check on hold signals, too, and if it's over the threshold, then do the hold thing. Or you could continue to ignore the hold signal and just start a timer when button-down is heard and do the hold thing if it doesn't get an up in the appropriate amount of time.

But I'm not a professional programmer, so my ideas may well be naive.

I posted, then I sent a copy to Mark and then I actually started thinking about it. Your last idea is what I came up with as well. I was getting a little confused by two different pieces of hardware I've used and forgot that this functionality is something I'd only like applied to the hardware I described in the original post (it has a unique up event).

1. So, as soon as the button is pressed, start a timer and produce no action.
2. If the up event is received before the timer expires, cancel the timer and execute the short action.
3. If the up event is not received before the timer expires, perform the long action.

That's the basic premise. Any additional subtletly would likely be a product of the specific action being performed by the button. For instance, a fast-forward on long press should continue to fast forward until an UP event. But it would also be feasible to have a single-shot command such as next track be assigned to a long-press as well with no repeat property. So that action is triggered in step 3 above and that's it. The subsequent up event does nothing else and continuing to hold it also does nothing else.

I came back online to delete or add to my original post because I felt a little silly after overlooking what ended up being such a simple set of basic steps to start with.

Bruno

take into account that the 'up' signal may never be received, for some reason.

Hijack does something along these lines, which may be subtly different than the single-timer approach:

1. Timestamp the event (RDTSC or the like) when the button PRESS event is received.
2. If the particular button/context is only valid as a "SHORT press", then send the event immediately to upper layers, and discard the subsequent button RELEASE when it arrives later on.
3. If the RELEASE (or another PRESS of any button) arrives before the LONG press interval expires, then send the button press along as a SHORT press to the upper layers, and discard the RELEASE.
4. When the required interval for a LONG press expires, initiate processing of the button event to the upper layers, and discard the subsequent button RELEASE when it arrives later on.
5. If a REPEAT operation (generate repetitions while pressed) is required, then periodically (at the required repeat interval) resend PRESS events to the upper layers, until such time as a RELEASE is received, or (failsafe) another PRESS is received (for any button).

Cheers

take into account that the 'up' signal may never be received, for some reason.

Yeah, I found that strange in his spec, too. Most consumer infrared devices work like:

Button down signal.

Button held signal.
Button held signal.
Button held signal.
Button held signal.
(... etc until the button is released then it stops.)

There is no button released signal because it's infrared and therefore might never arrive. Since you need to code your receiving app to take that into account anyway, there's no point in having a button released signal.

Mice and keyboards have an up event, and so too does the device I'm using. It isn't an IR device. And no, I didn't design the device, so we have to create the software given its behaviour. And it's different from yet another device we've worked with that doesn't have the different codes but instead sends continuous press codes. The software layer that's being developed does not continuously poll the device, so when codes "stop" being sent, that isn't a valid event (USB connection). We dn't have long-press support implemented for that device and I don't plan on having it added.

The support for long and short (for the new device I originally mentioned) will likely be handled as has been outlined, with a couple of failsafes. But the up event will definitely be used (and useful) when the device buttons are being treated as keyboard keys. Button behaviour should then mimick the keyboard and be governed by its set of repeat rules. I'll have to make sure that despite the current nature of the software layer, it's going to have to handle the no-up case (even though it may be a very unlikely event).

Incidentally, thanks for the help guys. Another reason I primarily read the board for non-empeg puposes now.

Bruno

Now driving new car, but empeg won't likely be installed until after a couple of trips I'm taking in January.

Oh! I think we thought when you said "remote control" you meant infrared remote control. Sorry for the misunderstanding.

If you want practice on how to write algorithms that handle press and release events, mess around in Visual Basic, processing only the MouseDown and MouseUp events on a form. Thing can get really interesting with cascading events and double clicks, it's quite an interesting challenge, depending upon the complexity of your program's functionality. You wouldn't believe the hoops I had to jump through to get long presses, short presses, and double clicks all working and co-habitating peacefully in EmpegFace.

Fortunately I don't have a need for double clicks with this implementation. The only double-click support related to this project is still handled by the OS because those (mouse) events are passed to the system. I also don't have the time to prototype any code myself. I'm in a management and design position of this project and someone else gets to write the code. It's a Mac project and it is remote control related, just not IR. In fact it's RF. But I do believe we should still account for the possibility of never receiving an up vent. I'm asking for some type of watch-dog process to be triggered when the initial press occurs which would manage the event cycle until it ends. If this is done it should be able to track the various scenarios.

I'm swamped with work right now with so many projects and on top of everything handling so many loose ends getting ready for Macworld in January (San Fran). And to make things interesting, the day after I get back from MW, I'm off to Mexico (at least that's supposed to be for relaxing). Of course all this new year's travel only has me worried I might not be able to get back into the country (certain newly required document in Canada which I still don't have... Oh boy.)

Bruno