Thanks Jim. Using automation as a base is a very good idea. TextFieldAutomationHelper seems like the key. It may be a bit more heavy-handed then I need for this application, but I haven't decided which way to go yet. Thanks again ...
Jim Cheng wrote: > > Daniel Wabyick wrote: > > > I am working on an onscreen keyboard for a touchscreen Flex > application. > > > > Building out the UI should be simple, but I am wondering if anyone has > > ideas on the best way to 'plug in' to the normal Flash key event > > system. I know I can get the current focused object via > > focusManager.getFocus(), but I am uncertain as to the best way to > > 'simulate' the keyboard. I can create KeyboardEvents, but how do I > > dispatch them so that the appropriate components are listening? > > First, get the Flex 2.0.1 updater if you haven't already. The new Flex > Automation framework source code that's enclosed in it will make all the > difference between a couple hours of work versus pulling your hair out > in frustration for weeks on end. > > For components not based on TextField objects, it's trivial--call the > dispatchEvent() method on the currently focused component with > script-instantiated KeyboardEvent instances. That's how Flex Automation > does it. You can see for yourself if you have the Flex 2.0.1 update > installed. Just dig framework source directory and check out line 272 of: > > mx/automation/delegates/core/UIComponentAutomationImpl.as > > TextFields are trickier. To get correctly emulated behavior, you need > to both emulate the original keystroke plus do some text manipulation, > since not all of it's behavior is mediated through the script-accessible > keyboard events. Aside from dispatching the event, you'll also need to > set the selection to the next position and then replace the selected > text with the character specified by your virtual keyboard for regular > keystrokes, while special characters like enter, delete, backspace and > such require some custom handling. Again, the automation classes show > you exactly how to do this, see the replayAutomatableEvent method (lines > 270-436) of: > > mx/automation/delegates/TextFieldAutomationHelper.as > > That should be sufficient for most text entry situations. If you need > more even advanced event emulation, you should probably consider using > Flex Automation. Having tried and failed to do much of the same thing > using ActionScript 2 in the past, I must say that the automation > framework is truly a lifesaver when it comes to such skulduggery. > > While automation is primarily intended for interaction logging and > automated replay for testing purposes, it can also be exploited to > simulate all manner of user interactions in non-standard ways (such as > your virtual on-screen keyboard). While the Mercury QTP plugin is > needed for out-of-the-box testing with Mercury, you don't actually need > to download the plugin installer (and shell out for a commercial FDS > license) to get access to and make use of Flex Automation proper for > your own purposes. > > To hook into Flex Automation yourself, you'll need to write your own > custom adapter classes implementing the IAutomationManager and > IAutomationObjectHelper interfaces and connect these to whatever floats > your boat (perhaps a server back-end, a built-in debugging dialog, or > maybe even a future version of John Grden's XRay targeting Flex and > ActionScript 3). > > This shouldn't be too hard for a seasoned Flex developer familiar with > the rest of the existing framework--I've managed to make a good bit of > headway into writing a few test classes that integrate with the Flex > Automation framework after a weekend's worth of hacking. Unfortunately > though, there's currently very little in terms of existing examples or > documentation to help you find your way around in there. Hopefully, > Adobe might remedy this in the near future (hint, hint). > > Jim Cheng > effectiveUI > >
