consumed keystrokes

[EzWz]

Hi, we got another issue that one of our testers noticed.

Situation:
The pdf exchange viewer is part of a bigger application. Picture a form with a menubar and a toolbar and such and a listview with some records. Depending on the record that is selected the pdf exchange viewer is showing a different pdf.

When the listview has focus (or any other part of the app except for de viewer) and the user presses ALT then the shortcutkeys in the menu will highlight (for example the F in the File menu will get underlined etc).
When the viewer has focus and the user presses the same ALT key, nothing happens. It looks like the viewer consumed the keypress??
Notifications for keyboard are OFF in the viewer however, so i see no reason why the keypress would be consumed.

I tried setting putting a debug statement in de eventhandler, but it doesnt go off (which i think is correct).

When i put

Code: Select all

Call PDFView1.SetProperty("Notifications.Keyboard.Filter", "All", 0)

in the code, then the eventhandler does go off on the keypress of the alt key (and any other key ofcourse).
I tried using

Code: Select all

Call PDFView1.SetProperty("Notifications.Keyboard.Skip", 1, 0)

for the keycode that was pressed, but that doesnt seem to help.

I've tried this with build 201.

I'm sure the mistake is in my own code somewhere but i can't find anything usefull on the topic in the forums and in the SDK documentation.
I hope it's an easy question

[Stefan - PDF-XChange]

Hello EzWz,

Please try to
SetProperty("Notifications.Keyboard.Filter", 0);
And the Viewer should not handle any keyboard commands leaving them all to your main application.

Because when you "Skip" a key - the Viewer control has already intercepted ("consumed") it, and you will need to implement your custom action after skipping the default action that the Viewer would usually perform.

Best,
Stefan
Tracker

[EzWz]

Hello Stefan,
I've tried your suggestion, but this doesn't seem to have any effect.
This is what I expected, since the original code does not have a line that says "Call PDFView1.SetProperty("Notifications.Keyboard.Filter", "All", 0)", so we NEVER let the viewer consume the keyboard notifications. Since we never turn the handling of these events On, the working is the same as when we explicitly turn the events OFF (which is what your suggestion does if i read it correct).

So in short: with the notifications for keyboard OFF the pdfviewer still consumes all keypresses like ALT, ALT+F etc. ALT+TAB is still consumed by windows however (it shows the switch app dialog).

I will make a test project tomorrow with as few code as possible, to try and see if it's my own code and will let you know the results of that.
Regards, Erwin

[Vasyl - PDF-XChange]

Hi, EzWz.

When the viewer has focus and the user presses the same ALT key, nothing happens. It looks like the viewer consumed the keypress??

Our viewer control 'lives' in different process and, you are right, when it have input focus - it consumes ALL keypresses...
For your case you may try to use one our notify:

Code: Select all

youreventhandler OnEvent(type, name, dataIn, dataOut)
{
   if ((type == PXCVA_OnNamedNotify) AND (name == "Global::CheckSysKey"))
   {
         int nKeyCode = (int)dataIn;
         if (nKeyCode == VK_MENU)
         { 
               // to skip processing it in the viewer-ctrl:
               dataOut = 0;
               // post sys-key event to yourself
         }
         return; 
   }
}

HTH.

[EzWz]

We checked the windowmessages that are being send everywhere with spy++
When i press alt+O then we get:
keydown for the ALT key on the pdfviewer
keydown for the ALT key on the mainform in my own application
keydown for the O key on the pdfviewer
keydown for the O key on the mainform in my own application
KeyUP for the O key in the pdfviewer
KeYUP for the Alt-key in the pdfviewer

The weird part here is that we don't get keyups in the mainform
Also the menubar (which is another 3rd party component) doesnt react to any of it.

I've tried to simulate the keystroke in the eventhandler of the pdfviewer
I've tried sendmessage and postmessage, sendkeys and keyb_event (API) but none of them gave the result i wanted.

There is no way to get the pdfviewer control running in my own process i think.
This seems to be a problem in different ways. This is one of them.
The second is that the pdfviewer is build into a control that is placed on the mainform several times.
For each of these instances the pdfviewer will make a new proces and claim separate memory etc.
Not only that, the application is used on citrix servers and they have a max. nr of processes per session. This maximum is reached very fast because of this issue.
Could we somehow get all the pdfviewer instances to run under the same process this problem would be handled, even if it was a different process than that of the main app.
If the main app AND all the instances where run in the same proces, we'd propably also have a solution for this keystroke problem.

But right now, i dont see a lot of options for this issue. Can you think of anything else i can try?

[Vasyl - PDF-XChange]

Hi, EzWz.

...
KeyUP for the O key in the pdfviewer
KeYUP for the Alt-key in the pdfviewer
...
I've tried to simulate the keystroke in the eventhandler of the pdfviewer
I've tried sendmessage and postmessage, sendkeys and keyb_event (API) but none of them gave the result i wanted.

Please try some modified way:

Code: Select all

pdfViewer.SetProperty("Notifications.Keyboard.Filter", 2, 0); // to intercept key-up events
...
youreventhandler OnEvent(type, name, dataIn, dataOut)
{
   if ((type == PXCVA_OnNamedNotify) AND (name == "Global::CheckSysKey"))
   {
         int nKeyCode = (int)dataIn;
         if (nKeyCode == VK_MENU)
         {
               // to skip processing it in the viewer-ctrl:
               dataOut = 0;
               // post sys-key-DOWN event to your main form
         }
         return;
   }
   else if ((type == PXCVA_OnNamedNotify) AND (name == "Notifications.Keyboard"))
   {
         variant dataOut;
         pdfViewer.GetProperty("Notifications.Keyboard.Msg", out dataOut, 0);
         int nMsg = (int)dataOut;
         if (nMsg == WM_KEYUP)
         {
              pdfViewer.GetProperty("Notifications.Keyboard.Code", out dataOut, 0);
              int nKeyCode = (int)dataOut;
              if (nKeyCode == VK_MENU)
              { 
                   pdfViewer.GetProperty("Notifications.Keyboard.Skip", 1, 0);
                   // post sys-key-UP event to your main form
              }
         }
         return;
   }
}

For each of these instances the pdfviewer will make a new proces and claim separate memory etc.
Not only that, the application is used on citrix servers and they have a max. nr of processes per session. This maximum is reached very fast because of this issue.
Could we somehow get all the pdfviewer instances to run under the same process this problem would be handled, even if it was a different process than that of the main app.
If the main app AND all the instances where run in the same proces, we'd propably also have a solution for this keystroke problem.

I'm afraid, you are right, but we cannot solve this problem in current version. Currently we are working on the new version of our Viewer ActiveX SDK.
Then you will be able to create many viewer controls in your process, new SDK will be 'in-process' fully. Also you'll have almost complete control over it (by subclassing, callbacks, eventhandlers, etc.)

Best
Regards.

[EzWz]

That sounds great. You say you are working on that for the next version or is the version not yet determined?
Some guestimate for a season or so would be nice, that way i might be able to postpone this if it's not too great a period to bridge.

[John - Tracker Supp]

Hi,

The upcoming release schedule is available here ;

https://www.pdf-xchange.com/company ... s/view/111
HTH