[jawsscripts] Re: Ideas for detecting the appearance of some stealthy dialogs

  • From: "Travis Roth" <travis@xxxxxxxxxxxxxx>
  • To: <jawsscripts@xxxxxxxxxxxxx>
  • Date: Tue, 28 Feb 2012 12:41:46 -0600

How about any of the window events?
For example HandleCustomWindows()?
Might have to experiment with these to see if any get called.
I see Outlook scripts also rely on the ScreenStabilizedEvent().
There also is a WindowCreatedEvent(). This one would get called a lot so
might need to take care to not have to process-intensive code in that but
might work as a last resort?


-----Original Message-----
From: jawsscripts-bounce@xxxxxxxxxxxxx
[mailto:jawsscripts-bounce@xxxxxxxxxxxxx] On Behalf Of Andrew Hart
Sent: Tuesday, February 28, 2012 12:23 PM
To: jawsscripts@xxxxxxxxxxxxx
Subject: [jawsscripts] Ideas for detecting the appearance of some stealthy
dialogs

Hi folks,

I'm looking for some advice.  I've been playing with Foobar of late and have
written some scripts to improve a few aspects of its UI, which is for the
most part pretty accessible.

However, there are a number of dialogs that can appear in Foobar and hwich
do not automatically receive the focus when they should.
Some examples include the Preferences dialog, which if it does lose focus
for whatever reason, does not get it back again, even though it continues
sitting on top of the main foobar window and prevents JAWS from seeing
whatever is behind it.  Getting focus back to it involves using the JAWS
cursor to simulate a mouse click in the window and then it can be dismissed
in the usual way.  Some other dialogs exhibit similar behaviour but
frequently don't receive focus.  For example, the Playback error dialog, in
the case that you ask Foobar to play a file which is not accessible or whose
format Foobar doesn't grok, or the report from the Converter plug-in
following a batch conversion operation.

I want JAWS to detect these dialogs automatically and place focus on them
whenever they are present.  Such dialogs are meant to be read, interacted
with and dismissed, not left on the screen during normal operation; JAWS
certainly fails to read things correctly if such dialogs interfere with it.

So far I have a script that can search for such windows and shift the focus
to them.  What I am lacking is a way to automatically detect their
appearance.  I've played around with NewTextEvent thinking that it might be
able to do the job, but monitoring the text being written to the screen
suggests that these dialogs are not firing NewtextEvent when text is being
written to them, and my code is not being called reliably.

I don't want to have to muck around using ScheduleFunction for continuous
monitoring to catch these crittors; I view this solution as messy, lazy,
slow, untidy, inelegant and, ... just oh, did I say messy?
 Yuchk!

There must be other event-based techniques that I could try to achieve what
I want.  Can anyone suggest some ways I could try tackling this?

Many thanks,
Andrew.


__________�

View the list's information and change your settings at
//www.freelists.org/list/jawsscripts


__________�

View the list's information and change your settings at 
//www.freelists.org/list/jawsscripts

Other related posts: