TRT TidbitsNotes, Info and Experiences from the Adobe Technical Response Team2010-07-30T08:20:02Zhttp://blogs.adobe.com/tidbits/feed/atomWordPressPatrick Leckeyhttp://blogs.adobe.com/tidbits/2009/05/trapping_keystrokes_from_an_ac.html2009-05-21T11:04:18Z2009-05-21T11:04:18ZContinue reading →]]>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.

]]>0Jay Proulxhttp://blogs.adobe.com/tidbits/2009/02/data_binding_and_accessibility.html2009-02-11T11:28:52Z2009-02-11T11:28:52ZContinue reading →]]>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.

]]>0Jay Proulxhttp://blogs.adobe.com/tidbits/2009/02/accessibility_updates_in_flex.html2009-02-11T11:27:42Z2009-02-11T11:27:42ZContinue reading →]]>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:

]]>0Jay Proulxhttp://blogs.adobe.com/tidbits/2009/02/entering_and_exiting_forms_mod.html2009-02-11T11:22:42Z2009-02-11T11:22:42ZContinue reading →]]>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.
]]>0