where is pdfviewer

[rtdog]

I see a number of references to an application called pdfviewer that can be used to view PDF documents on the PocketBook 902. Where do I find this application?

[J.C.]

The most basic way is when you are in the library and a book is selected either hold the round button or press the menu button and select pdfviewer from the open with sub menu (assuming the selected book can be opened by it - a pdf for example).

[rtdog]

I'm sorry I wasn't more specific. My understanding is that there is an application called pdfviewer.app that I can install to view PDFs that is not the build-in reader. If the build-in reader is called pdfviewer, where in the file system is it and more importantly, can I pass a command line parameter to it from a custom application to launch it? I can do this easily with things like calc.app and other applications that actually appear in the applications folder.

[troll05]

It is built in, the reader comes with 3 reading apps, AdobeViewer, pdfviewer and fbreader. unfortunately you can not easily access them because they are on the hidden part of the built in memory.

[rkomar]

Originally Posted by rtdog

I'm sorry I wasn't more specific. My understanding is that there is an application called pdfviewer.app that I can install to view PDFs that is not the build-in reader. If the build-in reader is called pdfviewer, where in the file system is it and more importantly, can I pass a command line parameter to it from a custom application to launch it? I can do this easily with things like calc.app and other applications that actually appear in the applications folder.

The built-in reader is in /ebrmain/bin/. You can see the source code for it (or probably an older version) at: http://pocketbook-free.sourceforge.n...urcecode.shtml, and can look to see what arguments it can take (it looks to me like it will just take filename and page number). I'm sure you can call it directly from another application, say using some form of 'execve' in C/C++, or from a shell if available.

[rtdog]

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.

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)?

[rkomar]

Originally Posted by rtdog

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.

Originally Posted by rtdog

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.