If I call any of the "fake" button codes from my user application, bad things happen. It doesn't appear to be quite a kernel panic, but the empeg locks up and I need to power cycle to get it back. I wouldn't expect good things to happen when trying to call the Hijack menu from a user app, but I was hoping to make use of the NextSrc, VisualSeek, and a couple others. I know the fake presses aren't in the .h, so they're probably not meant for use outside IR translations... But it'd be nice if at least some of them were available from user apps. Possible?

Test code attached to reproduce..

From the "documentation":

Insert button codes into player's input queue (bypasses hijack)

The reason is simple: if codes are fed back into Hijack instead of into the player, then they'll also get fed to userland again, and we'll end up in a nasty loop.

I'm not likely to touch the button handling code again if I can help it -- too fragile.

Cheers

Hm, okay. Figured I'd ask. I can probably replicate the VisualSeek and NextSrc functions in userland anyway, but I didn't want to reinvent the wheel if it was a simple fix. Guess not.

In theory, I could have Hijack examine the codes fed back to it from userland, and re-queue (to itself) any hijack-only codes. But then things would execute out-of-sequence, and I'm not sure it would help overall.

Plus I really don't much want to touch that code again.

Cheers