Many times it's true that there's no magic way to label all fields with a script, because fields aren't labeled in a consistent manner in many applications. Sometimes though, a scripter can find a trick that works very well throughout a particular application, or even throughout any application built with a particular set of tools. I think Dave is hoping for a case like that. I have not seen the app he's working with and so can't comment on how likely he is to find that sort of solution here though.
On Fri, Mar 02, 2012 at 12:44:22AM -0500, Tom Kingston wrote: 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 >>>>> >>>>> >>>> >>> >>> >> > > -- 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
