Doug, this isn't the case. Hyperactive windows are essentially event
driven so unless you want to insert sleeps scripts buy you nothing in
cases where they will solve the problem. Also speak windows do have
the trigger delay, but it is only used to solve cases where things
are written to the window in such a way that you need to include
delays before speaking. We recommend using sets where possible and
scripts where necessary. Sets will, in general, execute more quickly
because they are doing things native to WE. Scripts are meant to get
you places where sets couldn't go not replace sets. Of course it is
up to the person implementing something to choose which tool to use,
but you generally don't cut wire with bolt cutters or hammer a nail
with a sledge hammer. We still strongly believe in the power and
ability of sets and consider scripts another tool in the box not a
replacement tool. Also, as time goes on, we will continue to enhance
core functionality and application support in WE along with enhancing
the capability of sets and the scripting object model. WE isn't
going to become something glued together by scripts thus turning it
in to a helpless program without them or an unstable mess because it
is fully driven and dependent on them to function.
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]>
>
>
>>Tim,
>>
>>It's possible. One shouldn't discount the already powerful
>>functionality that Window-Eye User windows provide in addition to
>>scripting (along with hyperactive windows, and so on). I still wonder,
>>though, why your SpeakWindow isn't working when you feed it an control
>>ID. Can you send me your latest version of the script so I can play?
>>
>>Thanks,
>>
>>Aaron
>>
>>Tim Burgess wrote:
>>>Aaron,
>>>
>>>Would this be the way to go for my issue reading Sonar sub-windows?
>>>I've
>>>still got no further trying to base them on a control ID using a generic
>>>function like SpeakWindow( controlID). I'm reluctant to adopt your
>>>clips approach, as I've a number of windows to
>>>access this way and digging through the entire application is going
>>>to take
>>>an enormous amount of time.
>>>
>>>Best wishes.
>>>
>>>Tim Burgess
>>>Raised Bar Ltd
>>>Phone: +44 (0)1827 719822
>>>
>>>Don't forget to vote for improved access to music and music
>>>technology at
>>>
>>>http://www.raisedbar.net/petition.htm
>>> -----Original Message-----
>>>From: Aaron Smith [mailto:[EMAIL PROTECTED] Sent: 07 October 2008 16:19
>>>To: [email protected]
>>>Subject: Re: How to do this with VBScripting
>>>
>>>Christian,
>>>
>>>While I applaud your ambition, couldn't you do what you want with a
>>>Window-Eyes user window?
>>>
>>>Aaron
>>>
>>>Christian wrote:
>>>>Hi all,
>>>>Well, I have started to look a little at VBScripting, but I have a
>>>question.
>>>>If I want to capture some text on the screen and store that in a
>>>>variable
>>>and then be able to press a keyboard shortcut and WIndow-Eyes will
>>>then read
>>>that back, what should I look at then?
>>>>Best regards and thanks,
>>>>Christian
>>>>
>>>
>>>--
>>>To insure that you receive proper support, please include all past
>>>correspondence (where applicable), and any relevant information
>>>pertinent to
>>>your situation when submitting a problem report to the GW Micro
>>>Technical
>>>Support Team.
>>>
>>>Aaron Smith
>>>GW Micro
>>>Phone: 260/489-3671
>>>Fax: 260/489-2608
>>>WWW: http://www.gwmicro.com
>>>FTP: ftp://ftp.gwmicro.com
>>>Technical Support & Web Development
>>>
>>
>>--
>>To insure that you receive proper support, please include all past
>>correspondence (where applicable), and any relevant information
>>pertinent to your situation when submitting a problem report to the GW
>>Micro Technical Support Team.
>>
>>Aaron Smith
>>GW Micro
>>Phone: 260/489-3671
>>Fax: 260/489-2608
>>WWW: http://www.gwmicro.com
>>FTP: ftp://ftp.gwmicro.com
>>Technical Support & Web Development
>>
>>__________ Information from ESET NOD32 Antivirus, version of virus
>>signature database 3501 (20081007) __________
>>
>>The message was checked by ESET NOD32 Antivirus.
>>
>>http://www.eset.com
>>
>>
>
--
To insure that you receive proper support, please include all past
correspondence (where applicable), and any relevant information
pertinent to your situation when submitting a problem report to the GW
Micro Technical Support Team.
Aaron Smith
GW Micro
Phone: 260/489-3671
Fax: 260/489-2608
WWW: http://www.gwmicro.com
FTP: ftp://ftp.gwmicro.com
Technical Support & Web Development
--
Doug Lee, Senior Accessibility Programmer
SSB BART Group - Accessibility-on-Demand
mailto:[EMAIL PROTECTED] http://www.ssbbartgroup.com
"While they were saying among themselves it cannot be done,
it was done." --Helen Keller
--
Michael D. Lawler
Voice 260-489-3671
Fax 260-489-2608
Internet mailto:[EMAIL PROTECTED]
web http://www.gwmicro.com
ftp ftp://ftp.gwmicro.com
GW Micro, Inc.,
Development Liaison and Technical Support Supervisor
