Problem with internal viewer - command 'show'

I have problem with internal viewer - command 'show'.
Can anybody tell me if this can be corrected by configuration change or it is "working as designed"?

When I view picture I can close Viewer window by pressing ESC. But when I view .pdf file ESC key don't close window.

The PDF viewer component (whichever is installed; it isn’t part of Opus) must swallow the Esc key.

We have no way of knowing whether third party viewers need to use any given key, so we have to let them have first chance at responding to a keypress when they have focus inside our window frames, else we could break the ability to use them properly.

FWIW, and while it does work, it’s unusual to open things like PDF and other documents in the standalone Opus viewer window (as opposed to the preview pane that’s part of the main window), via doible-click, etc. Opus does that for image formats by default but not document formats, as they’re usually best viewed in their own programs/viewers. You can make it happen by explicitly running the show command, and it does work, but there isn’t much to gain from viewing documents that way instead of in a dedicated program/viewer, if you want them in their own separate windows.

but I am talking about PDF vieved inside DOpus window (internal viewer)

just made some tests... If internal window is running as MAXIMIZED window ESC key works only for images. But if internal viewer is running inside normal window (not maximized) ESC works also for PDF. Semms like bug.

It looks like you're using Adobe Reader there. Opus itself does not contain any PDF viewing code. Instead, we support using several types of third-party viewer components ("preview handlers" in this case) inside our windows, which is what's happening there.

Preview handlers can also run inside of File Explorer's preview window, as well as other tools like Outlook. It's still (in this case) Adobe Reader that's actually viewing the file, just inside of another program's window.

It's up to that viewer component which keyboard events it responds to and how. (While we could probably intercept the keys and override things, we don't want to do that when it isn't our viewer, because that might break something important. As a simple example, if we intercepted the cursor keys then you would not be able to use them to scroll the document. We have no way to know that the Esc key doesn't do something important in someone else's viewer.)

We support that kind of viewer so that you can use them in the preview pane. They also work in the standalone viewer, but that's really just a bonus and not how we expect anyone to view those files. If someone wants to open those files in a separate window, we assume they'll probably be using the application that the viewer comes from (e.g. Adobe Reader, PDX-Change, Sumatra, FoxIt, etc.).

Not that using the other application is likely to help with making Esc close the window, as I don't think any/many PDF viewers do that. I'm just explaining that the viewer isn't our code, and we can only do limited things to how it handles keypresses without the risk of breaking things.

@Leo , thanks for explanation. But it still don't answer my question. Why ESC key is working when window is not-maximized but not working when it is maximized?
The same behavior is for empty window (no preview handler selected):

Steps to reproduce:
1 - map any key for function show (example: F3)
2 - select PDF file
3 - press F3 -> internal viewer should open
4 - double click on window bat to maximize window
5 - close window manually (by X)
6 - press F3 again -> internal viewer should open
7 - press ESC key -> window is not closed

8 - double click on window bat to not-maximize window
9 - close window manually (by X)
10 - press F3 again -> internal viewer should open
11 - press ESC key -> window is closed

what is difference? Internal viewer is maximized or not :slight_smile:

Apologies, I missed that detail in your previous reply. That is strange...

I've done some debugging of it but I'm not sure what is happening. The same happens if you open a PDF in the standalone viewer, non-maximized, and then click another window and click back to the viewer.

I can see in the debugger that the keypresses are no longer even sent to our thread after that happens, which looks like a Windows bug to me. (The window going inactive and active again should not change which thread Windows sends keyboard events to.) Probably triggered by the number of different threads and processes involved in the window with this type of viewer. I can only guess though, since the keypress events simply aren't arriving where they're supposed to (while they do arrive in the right place when the window has only just opened).

It might be possible to work around it with some kind of keyboard hook into the process the viewer is really in, but that gets quite complicated. Since this type of viewer is only really intended to be used in the viewer pane, not the standalone window, I'm not sure it's something we'll find the time to look into in more detail, and it may not be easy to fix at all.

the strangest thing is, that it is working when image / picture is shown inside viewer...

Images are displayed by Opus's internal code (or an in-process, Opus-specific plugin in the case of animated GIFs). The standalone viewer is also designed to work with them, unlike documents where it's more by accident that it can view them (due to supporting them in the preview pane).