TRT Tidbits

Trapping Keystrokes from an Acrobat Plug-in on Windows

Patrick Leckey — Thu, 21 May 2009 11:04:18 +0000

This is a question I get a lot – “How do I prevent certain hotkeys from being issued by the user using the Acrobat SDK?”. Well, quite frankly, the answer is – you don’t. The Acrobat SDK does not provide any mechanism for trapping keys in the Acrobat interface, and these features have been left out for a good reason; your platform APIs already have a mechanism to do this, and they provide much greater control than anything the SDK could provide (which would need to be limited in scope to the active application window). You can use these platform APIs in your plug-ins, using your plug-in as a proxy to these interfaces, and doing whatever you want with the resulting responses from the platform APIs.

In this article, we’re focusing on Windows (since this is the OS the majority or these questions come from). We’ll be focusing on the SetWindowsHookEx method to set up a keyboard hook that will pass all keystrokes to a callback, analyze the key codes and discard the ones that we want to ignore while passing the rest on down the line.

For the purposes of this article, I have modified the file “BasicPlugin.cpp”, which is part of the “BasicPlugin” sample contained in the Acrobat 9 SDK. I am using Visual Studio 2005, as this is the only tested & supported platform for developing Acrobat plug-ins on Windows.

You can download the updated “BasicPlugin.cpp” here. Simple replace the BasicPlugin.cpp in the PluginSupport/Samples/BasicPlugin/Sources folder and rebuild the project. This will add a menu item in Acrobat named “Hook Plugin” under the “Acrobat SDK” submenu. Choose this menu item and it will alternate enabling or disabling the hook. I have hooked CTRL+C, CTRL+V, CTRL+X in order to demonstrate impeding a user from using hotkeys to copy data from a PDF.

Data Binding and Accessibility

Jay Proulx — Wed, 11 Feb 2009 11:28:52 +0000

When updating text via data binding in Flex, JAWS (or other screen readers) will not automatically read the change. Imagine a Flex application where every time a visual String was updated, the screen reader read that change. It would be worse than being in a theatre before the curtain rises! However, after data binding has occurred, you can use your screen reader shortcuts to move back and forth through the accessible properties and hear any changes that have been made.

The best way to review what text should be read is to use an accessibility inspector such as Inspect32, or Accessibility Explorer (both available from Microsoft). You can step through the MSAA properties and review the descriptions and names. I find the easiest way to ensure you’re looking at just Flash Player is to use Accessibility Explorer and use the select with mouse tool and click on an instance of Flash Player within a browser.

Accessibility updates in Flex SDK 3.1

Jay Proulx — Wed, 11 Feb 2009 11:27:42 +0000

If you’re using JAWS, and are experiencing unusual behaviour reading your mx:Text controls, it may be due to an issue in Flex SDK 3.0.0 (or Flex Builder 3.0.0). There were a number of Accessibility updates released in Flex SDK 3.1 (or Flex Builder 3.0.1). Since then Flex 3.2 and Flex Builder 3.0.2 have been released, and official support is offered for those products, try the latest Flex SDK Mileston release available here:

http://opensource.adobe.com/wiki/display/flexsdk/Download+Flex+3

Entering and Exiting Forms mode with JAWS 9

Jay Proulx — Wed, 11 Feb 2009 11:22:42 +0000

So, this doesn’t seem very obvious. If you want to enter forms mode in JAWS 9, you either need to hit numpad-plus, or for those of you who are numpad-challenged, the other obvious combination is capslock-semicolon.