View Single Post
Old 04-30-2011, 01:14 PM   #7
rkomar
Wizard
rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.
 
Posts: 2,985
Karma: 18343081
Join Date: Oct 2010
Location: Sudbury, ON, Canada
Device: PRS-505, PB 902, PRS-T1, PB 623, PB 840, PB 633
Quote:
Originally Posted by rtdog View Post
Thanks, that worked awesome for me. Now I can spawn the application from my app. My only remaining issue is that when I hit the "home" key on the child application, it goes back to the main menu and exits my application, but leaves the child application running. So if I spawn calc.app, hit home, then my application is dead but calc.app is still running and so is the main menu. Then the navigation keys will paint both a change on the main menu and simultaneously key selection change on calc.app, which is overlayed with the menu.
Do you want your application still running beneath calc.app? If not, using 'execve' in C/C++ or 'exec' in the shell should kill your application while starting up calc.app. If you want your application to keep running, then you can probably get the PID of the child process as you spawn it and later send it the kill signal when shutting down. I think you should be able to do that in the EVT_EXIT section in your application's event handler. However, I'm not sure it's a good idea to have multiple applications grabbing the screen and button events at the same time.

If your application uses the InkView API, maybe you should look into using the latter's book handling features rather than calling pdfviewer directly yourself.

Quote:
Originally Posted by rtdog View Post
I suspect that I can capture EVT_EXIT on my app, then kill any child processes that I spawned as my app exits, but I'd prefer to capture the home keypress and abort the exit. Anyone have any experience with overriding the built-in key handler? Alternately If I had the source to pdfviewer I could just recompile that app. Is there any access to the source code of pdfviewer that's a bit more current? Or is the link that rkomar posted the most up to date (for the 902)?
I don't think you can do anything with the sources. pdfviewer is built using the InkView API (see the call to InkViewMain in the main routine), and the API handles events first and passes them on to the application's handler. I haven't noticed anything in the API that allows the action of the Home button to be overridden. In fact, KEY_HOME isn't even defined in inkview.h, so it looks to me like they don't even expect you to try to handle it. So, you should study the API first to see if you can figure out how to do what you want first before futzing with pdfviewer sources.

You can always remap the Home button to something else in the global configuration, but that means it won't work at any time, and not just when your application is running.
rkomar is offline   Reply With Quote