Accelerator-key messages

[anovy]

Hi,
How can I forward accelerator-key messages to the PDF XChange viewer window if it has no focus? First I thought that I can simply call IOleInPlaceActiveObject::TranslateAccelerator in my application's message pump. But this does not work. I also noticed that if the PDF XChange viewer window has focus, then my application's message pump does not work, i.e. the PDF XChange control has its own message pump (so in fact is is not true InProc server). So is there a way how I can force your control to process accelerator messages even if it has no focus?

[Vasyl - PDF-XChange]

Hi, anovy.

Sorry, but there is no simple way to do this, you are right: the main part of pdf-xchange control is out-process.
But you can try a nonstandard method in your message loop(pseudocode):

Code: Select all

...
if (<keyevent>)
{
    HWND hWndMain = GetChildWindow(pdfxviewControl.hwnd); // obtain our main window, pdfxviewControl.hwnd is container only
    PostMessage(hWndMain, <keyevent>); // relay key event to our main window for translating into accelerator.
    return; 
};
...

The new version of our activeX will be in-process fully.

HTH.

[anovy]

Yes, I already tried such approach and generally it works, however it of course eats all key messages. If XChange control has no focus, then I need (and it has only sense) to pass to it only those keys, which are mapped in their accelerator table. The IOleInPlaceActiveObject::TranslateAccelerator method should do such work, but it is intended for InProc servers only. Even so I think you can support this method, the in-process part can ask for this the out-process part via some internal method.

But don't worry with this more, I have few ideas how to solve this problem.

BTW:
The window handle which I used in my test for direct key message processing was obtained from IOleWindow::GetWindow method (I'm not using MFC, just plain C++). I hope it is the right window (because it worked ).

[anovy]

Hi again,
My first idea was to enumerate all commands and get their Shortcut property to obtain list of all keys for testing in my message loop. However I found that if the command has default shortcut (the shortcut was not redefined), then the returned Key value is always 0. So it is impossible to obtain real shortcut values for commands in default state. I only know that the Shortcut is in default state (Modifiers value is -1), but I cannot get the real Key, Modifiers and Type values for this default shortcut. Why? I think you should return real values also for commands with default shortuct and the default state can be indicated only by some flag (e.g. in Modifiers value: ALT flag is 16, CTRL flag is 8, SHIFT flag is 4, so the flag indicating default shortcut can be 32).

BTW:
Why you have the Type value? Why it is not flag (1) in Modifiers? In such case this would be pretty compliant with the Windows ACCEL structure and the Type value can be used for another purposes (e.g. just as 'default state' indicator).

[Vasyl - PDF-XChange]

Hi, anovy.

The IOleInPlaceActiveObject::TranslateAccelerator method should do such work, but it is intended for InProc servers only. Even so I think you can support this method, the in-process part can ask for this the out-process part via some internal method.

We will investigate this feature. This feature can be implemented in the next build.

Why you have the Type value? Why it is not flag (1) in Modifiers? In such case this would be pretty compliant with the Windows ACCEL structure and the Type value can be used for another purposes (e.g. just as 'default state' indicator).

You are right in some cases, but, unfortunately, is too late to full change it.
Many existing features was developed dynamically therefore they can have some disadvantages.

Your suggestions will be considered in the new version(V3). Thanks.

Best
Regards.

[anovy]

Hi,
I understand that any such change is complicated, because you should keep backward compatibility. Maybe you can create new shortcut property, for example named ShortcutR, which will be for reading only and which will return real Key, Modifiers and Type values also for commands with default shortuct. And such modification can be done already in version 2.

Addtional suggestion: It would be nice if you can add to the Shortcut group a new item (read only) which will return the UI string of the shortcut (e.g. "Crtl+B", "F11" etc.). It would be handy for use in client controls (tooltips etc.) outside your control.

BTW:
Is there some approximate schedule for version 3?

[Vasyl - PDF-XChange]

Hi, anovy.

I understand that any such change is complicated, because you should keep backward compatibility. Maybe you can create new shortcut property, for example named ShortcutR, which will be for reading only and which will return real Key, Modifiers and Type values also for commands with default shortuct. And such modification can be done already in version 2.

Ok. It will be added into the next build.

Addtional suggestion: It would be nice if you can add to the Shortcut group a new item (read only) which will return the UI string of the shortcut (e.g. "Crtl+B", "F11" etc.). It would be handy for use in client controls (tooltips etc.) outside your control.

This feature is present already:

Code: Select all

GetProperty("Commands["Copy"].ShortcutText", dataOut, 0);
// dataOut == "Ctrl+C";

HTH.

[anovy]

Thank you Vasyl.

BTW: The ShortcutText property is undocumented, so I did not know about it.

[Vasyl - PDF-XChange]

Hi, anovy.

1. In the new build you will be able to obtain the default shortcuts for all UI-commands.
Please look to the updated help, [Preferences/Named Items/Objects/Commands/Item/Shortcut] section.

2. Added new commands:
MsgToCommand - translates windows message to UI-command identifier
MsgToCommandAndExec - translates windows message to UI-command and executes it.
For details look to [Preferences/Named Items/Simple Operations] section in the updated help.

Wait for the new build...

Best
regards.