I tried, and tried, and tried again. But haven't been able to get this behaviour at all. Yes, I was in the car and not using hijack's 'DC mode' override.

But from your description, this should not be possible. I've looked at my code, and it clearly does 'BINDBUTTONS', followed by 'SETGEOM', before flushing pending serial input and refresing the screen. The advantage of a single thread application, I know that gpsapp doesn't refresh the screen until the hijack redirections are all registered.

The only thing I can think of now is that hijack somehow clobbered the array that I passed along with the ioctl. I don't see any code in hijack that would in fact do so. But it isn't too much trouble to pass a copy of the array instead of the original.

I have noticed the 'standby' bug. When I start my engine, the accessory line is temporarily turned off and the empeg blinks into standby for a moment. When it returns, it always returns to the player. My guess is that the player in fact exits and restarts and that hijack responds to the player startup by reinitializing some pointer and completely forgets that there was a 3rd party app running.

Because the app isn't getting any input, it simply runs indefinitely in the background and can't tell anything is wrong because the waitbuttons, pollbuttons and screen refresh ioctls never fail. Hmm, that is probably the easiest solution, add an error code to some of these ioctls when hijack doesn't think that the app is 'in control'.
_________________________
40GB - serial #40104051 gpsapp