[jawsscripts] Re: Scripting horror!
- From: "David Farough" <David.Farough@xxxxxxxxxxxxx>
- To: <jawsscripts@xxxxxxxxxxxxx>
- Date: Mon, 05 Jan 2009 09:41:35 -0500
Hi Don:
I have seen this class used in many applications. It is usually the
main application window.
Perhaps If you are testing for these windows in the Default scripts,
you could use either GetOwningAppName
or GetWindowOwner first to see if the window belongs to your telephone
application.
Have you tried using bx to determine the correct path to use to get to
some of the problem buttons? Are these windows displayed long enough to
reclasify or experiment on?
David Farough
Application Accessibility Coordinator/coordonateur de l'accessibilité
Information Technology Services Directorate /
Direction des services d'information technologiques
Public Service Commission / Commission de la fonction publique
Email / Courriel: David.Farough@xxxxxxxxxxxxx
Tel. / Tél: (613) 992-2779
>>> "Donald Marang" <donald.marang@xxxxxxxxx> 01:15 pm Thursday,
January 01, 2009 >>>
You described my situation with Verizon Call Assistant. All of the
dialogs
have the class of "#32770". I thought this was random until I
discovered
that Notepad also uses this class. The application uses this class for
the
main window, the results window, the "Toast" windows that popup in the
notification area like a HelpBalloon, windows that pop up like ToolTip
windows and confirmation dialogs. It would have been much simpler if I
could just Reclassify individual windows as ToolTip and HelpBalloon!
Instead I created my own WindowActivatedEvent, which checks for this
class,
then performs a series of If ... Then ... ElIf ... statements that
check the
Control ID and text of its first child to accurately determine the
window.
Although most of the Control IDs do not change, a few strangely have
the
same number. Perhaps they lost count when creating the controls. The
numbers start at 201 and count up. But the Close button in the title
bar
and the next page button use the same ID.
All of this takes a lot of trial and error!
I still have serious problems reliably moving to buttons that are
visible on
the screen with theMoveToControl statement! Sometimes it seems that
there
is a barrier between the main dialog where the main buttons are located
and
other dialogs, like the results dialog. I switch to the JAWS cursor,
set
the restriction to none, and try every way of moving the cursor and
focus I
know about. But it fails! Sometimes it performs and reads and reacts
like
I expect, but the PC cursor refuses to move to the new window when the
function finishes. In this function, I am not using any SaveCursor
statements.
The window handle of the application occasionally changes, even without
closing! I think its schizophrenic. There are two instances of the
application running all of the time according to WinDig. Is this
normal for
an application that also runs in the system tray? If I use nested
statements throughout the application to dynamically get the main
application window handle, the scripts fail. I had to set a global
variable
and use that to make it work at all. That is until the main
application
window handle decides to change.
Slowly my scripts for this unruly application is becoming useful and
more
stable! I had a lot of cases where it came in handy, like telling me
my son
called and left a message just after midnight while I was on the phone
with
my daughter.
Don Marang
__________
Visit and contribute to The JAWS Script Repository http://jawsscripts.com
View the list's information and change your settings at
//www.freelists.org/list/jawsscripts
Other related posts:
