In some cases, the performance of SET files can be improved by using cursor
delay. A cursor key is any key that is passed through to an
application. If something is to be read after this key is pressed, you can
determine, for each key, how long to wait before reading the
information. This is a fixed number, and not event-driven, however.
At 02:11 PM 10/7/2008, you wrote:
It's too early for me to tell if my theory is accurate, but my theory
is that scripting things like window/area speech will prove more
reliable than using user/hyperactive windows, just because scripting
can let us fire the speech on actual events rather than estimated time
delays. In other words, I am assuming a scripted solution would
behave more consistently on slow machines, fast machines, a machine in
the middle of a CPU-intensive virus scan when the window comes up,
etc.
Of course I welcome correction from those who know. This is my
experience in other environments, but I've not played much with
Window-Eyes set files.
On Tue, Oct 07, 2008 at 01:36:10PM -0400, Aaron Smith wrote:
Tom,
If you have a solution, and it's working great, save your head some
trauma, and go with it. Scripting is very powerful, very cool, and it
can really make inaccessible applications shine. But remember that sets
have been around since the inception of Window-Eyes, and (as you already
well know) offer quite a power punch themselves.
I think the best way to do all, end all, is use a combination of the two
technologies. Use sets where you can, and script where you can.
The ultimate goal isn't to prove you could do it all with scripting. The
ultimate goal is to just prove you can do it. The uber-ultimate goal is
to provide accessibility, regardless of how.
But, you already knew all that.
Aaron
Tom Kingston wrote:
>Aaron,
>
>This brings up the same question I've been pondering regarding Sound
>Forge. I'm just as hyped up about scripting as everyone else and want it
>to be the do all end all for everything. And it's given me the ability
>to do some really cool stuff I can't do with sets. But the plug-in
>windows are where I keep wondering if set files are really the way to
>go. Here's why.
>
>These windows are dialogs and don't scale to resolution. The problem is
>that there are many custom track bars and the values they change are
>scattered all over the place. Some are in text boxes but many are just
>text clips anywhere from 1 to 10 clips away from the track bar. So
>indexing these all relative to the focused control would be an enormous
>project. I tried OnChildClipRendered but like your hotspot script these
>plug-in windows make it act strange. It works fine in the main window or
>in other windows I've tried but for some reason the clip is spoken twice
>in these plug-in windows. They must be rendered twice for some reason.
>
>My sets for the previous version worked great in these windows but I've
>been beating my head against the wall trying to script them. Sounds like
>I'm trying to get you to tell me what I already know I should do. But I
>just want to make sure I'm not missing a simple scripting answer.
>
>Thanks,
>Tom
>
>----- Original Message ----- From: "Aaron Smith" <[EMAIL PROTECTED]>
>
...
Lloyd Rasmussen, Senior Project Engineer, Engineering Section
National Library Service for the Blind and Physically Handicapped
Library of Congress (202) 707-0535 <http://www.loc.gov/nls>
HOME: <http://lras.home.sprynet.com>
The opinions expressed here are my own and do not necessarily represent
those of NLS.
