Unfortunately it doesn't work that way. If Window-Eyes doesn't see a
field name then a script won't see one either. Scripting isn't magic.
And it can't see any more than Window-Eyes can by default. So there's no
such thing as automating field name reading when the field names are not
recognized as such.
For example, if I tab to a control, any kind of control, and no field
name is spoken, if I open the immediate mode scripting window and
execute the following I will hear: "No field name."
If FocusedWindow.FieldName = "" Then Speak "No field name."
The reason is because in these programs there is no standard definition
of or tag to indicate a field name and what control it is partnered
with. And Window-Eyes can only go so far trying to logically figure out
what the field name is on the fly. When it reaches the outer bounds of
its logic it has to quit while it's ahead; which is having looked at all
common and reasonable relative points.
So, the answer is still the same. Virtually the same process would have
to be done in a script to produce what the Label field name hotkey does.
And it would be a lot more work to script it. The only advantage to
scripting it would be to pin down every label container and point to it.
This would automatically do the same for folks using a different
language because it would be reading the child window containing the
label instead of your defined text. But again, it would be a big project
compared to labeling field names yourself. And because there is no way
to automate this it would have to be done manually for every plug-in you
have and every one you add, just like with the label field name hotkey.
So, unless someone wants to tackle this, I'd suggest just doing it when
you feel like it. Label things while you're working, if you feel like
it. And when you're in the mood just spend an hour or however long you
can labeling fields. If it takes a month or three, who cares. You'll see
the benefit as you work on it and you'll be a very happy camper when
it's done and you made the program you want to use completely accessible.
Regards,
Tom
On 3/1/2012 11:28 PM, Dave Bahr wrote:
No, no, no. you are completely misunderstanding the aim of the possible
script. This isn't about scripting individual field labels. It's about
the automation of field name reading so that the user knows, via
tabbing, what field he is in when working with a complicated vst plugin
such as an equalizer. If the process were simple and just required the
main interfaces of goldwave to be labeled, then I totally agree with
you, field labeling would get the job done. But the idea for this is
that it could be used to interact with a wide array of vst plugins and
make them accessible. Make more sense?
Dave C. Bahr
On 3/1/2012 1:12 PM, Tom Kingston wrote:
What can I say? If it's too much for you to do the labeling in a
program you want to use then I wouldn't hold your breath waiting for
someone else to do a lot more work in order to do the same thing in a
script. You have one specific problem and I've provided a simple
solution; one which is much easier than scripting field labels. So
going without while waiting for someone else to do the work for you is
your choice. Good luck.
If by any chance you reconsider, here's a thought. Rome wasn't built
in a day.
Tom
On 3/1/2012 2:52 PM, Dave Bahr wrote:
responding to tom and dave here.
Dave. I thought about the hotspot script but I don't know how to work it
that well, and I'd need instant response. As for the hyperactive windows
feature, I'll admit I know nothing about it, but this is all contained
in one single window.
Tom. The control insert f idea isn't an option because each plugin
contains different edit boxes. I would spend my whoe life labeling the
boxes and not getting any work done with the plugin.
Dave C. Bahr
On 2/29/2012 11:14 PM, Tom Kingston wrote:
You can do what you want with one of the many overlooked features of
Window-Eyes. I assume you have a set file associated with GoldWave. If
not, associate one.
Now you can assign your own field names. When the edit box you want to
hear the field name for is in focus hit Control-Insert-F, enter the
desired field name in the edit box, tab to OK and press enter. This
name will be voiced automatically whenever that control gains focus.
It will also be voiced with the field name hotkey; Control-Shift-N.
All of these field name definitions are stored in the .we file
associated with the program.
Hth,
Tom
On 2/29/2012 11:06 PM, David Helkenn wrote:
Hi, Dave,
I am not in any position to write the script, but I use Goldwave and
very interested in keeping up with it development. Have you tried
alternatives to a script? I'm thinking of hyperactive windows which
trigger on any change? What about the HotSpot script for moving the
mouse pointer and voicing data? Bottom line, is a script really
needed?
Dave
At 02:15 PM 2/29/2012, you wrote:
Hello List,
I am writing to enquire if anyone would be willing to write a script
that, I think, should be pretty simple. Full details are written
below. It involves writing a script that will somehow route the names
of edit, combo, and combo edit boxes to the screen voice in
goldwave's
standard custom control interface. I know what you're thinking,
standard custom control interface? How can it be standard if it's
custom? Well, that's just the generic name I'm using for it. What
follows is an explanation of the script's purpose and necessary
functions. It might be that the original goldwave script could be
modified to incorporate this feature. Despite the fact that I said it
would be simple, I have provided a rather involved explanation so
that
everything is laid out.
The current custom control set is made by a company called
Embarcadero. The tab index is set by this company and a property
sheets of Goldwave. However, I have done extensive testing and
noticed
that there is a pattern which I think can be utilized by a
Window-Eyes
script.
When the screen cursor is in an edit box such as the tone meter
box of
the current Goldwave version 5.66, it reads the number contained in
the edit box but not the edit box's label. In order to read the
label,
it is necessary to route the pointer of the mouse to the edit box and
press the number pad eight key to find out what this box controls.
For
example, if the box reads "0.00" it could control the decibel
level at
which the tone meter needs to be activated to make a sound alerting
the user that the level is too high. Window-Eyes currently reads the
level properly in its numeric format but the mouse cursor reads it as
"level I DB, 0.0."
This behavior of landing in an edit box with the tab, routing the
pointer, and then pressing the up arrow on the numbpad needs to be
modified so that the screen voice can read the line above the edit
box
where the mouse pointer currently resides. This would allow for
on-the-fly modification of values.
These custom control set edit boxes are the standard for the VST
plug-ins which Goldwave now supports in beta format. The same
behavior
as described in the tone meter edit boxes is present in the plug-in
boxes as well. The issue with these is that, if it's an equalizer
with
35 boxes, trying to route the pointer and see what the box controls
while trying to edit the equalization of a previously recorded sound
takes far too much time to allow for real-time modification. So it
would be necessary for the screen voice to dictate what the mouse
voice originally dictated with that line above the number in the edit
box. Are you with me so far?
I am in contact with the developer of Goldwave but not of the
Embarcadero custom control sets. I would be happy to send e-mails to
whoever writes these to see if we could work out some idea of how to
modify the tab index if that is what needs to be done to allow the
screen voice to read the label of the edit box. As I mentioned before
it appears that the tab index is written internally into the
Embarcadero custom control set. Therefore, it would probably be
easier
to somehow allow the screen voice to read the mouse voice information
in that line above the box as mentioned in the previous paragraph. I
personally do not know any VBS code and do not know how difficult
this
would be. What I do know is that the ability for one to modify the
edit boxes in real time is essential to editing no matter if there's
three or 63 boxes present. Earlier I had also alluded to combo boxes,
which have the same property as these edit boxes seeing as they're in
the same interface. Not all of the combo/edit boxes which contain the
presets for various Goldwave controls are unreadable. In fact, the
presets,/edit box is always read with the word "presets," before the
data is spoken. This of course changes with the user's preference for
when field data and field name are spoken. However, in some of the
level controls such as the tone meter, the combo box to change the
waveform which would be the alert tone from sign to square to saw is
not readable unless the pointer is routed and the up arrow is pressed
as described in the previous paragraph.
I realize that I have probably been far too verbose in my explanation
of the current idea for a script. But I would rather have everything
spelled out as plainly as possible so the potential writer knows what
they're getting into. Feel free to please contact me either off or on
list to discuss this possibility and I will do whatever I can to make
it a reality.
I thank you for your time,
Dave C Bahr
