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

  • From: Andrew Hart <ahart@xxxxxxxxxxxxx>
  • To: jawsscripts@xxxxxxxxxxxxx
  • Date: Tue, 28 Feb 2012 21:23:34 -0300

John,

Most interesting.  I'd like to see your script to detect these kinds of
things.  Perhaps it is better than what I am doing.  the problem with
these windows is that they are at the same level in the Window structure
(i.e. siblings) as the main application window.  The Unfortunately, they
simply do not get the focus at all.  Consequently, GetTopLevelWindow
returns the same thing as GetAppMainWindow (except when things like the
open File, Jump to Time and Add Files dialogs have focus).  However,
clicking the mouse in the problematic windows or using SetFocus with the
appropriate handle brings focus to them and JAWS then works fine with them.
Neither the FocusChangedEvent* functions nor WindowActivatedEvent
function get fired when they are drawn.

The CreateWindowEvent function does seem to get fired and I can use
SetFocus to make these dialogs behave themselves more or less.
Unfortuantely, my crude solution at present  breaks oodles of other
dialogs and things in Foobar, so I need to specify much finer conditions
under which I should set the focus.  Clearly, I need to be muchmore
discriminating about when to set the focus and when to leave JAWS to
apply its default behaviour.  Nonetheless, I can make the problematic
Windows more or less behave themselves and it's a matter of ensuring
that my solution applies only to them so as not to break other aspects
of the Foobar UI.  I just have to keep pecking away at it.

Thanks once again all.  I'm getting lots of good stuff here.

Cheerio,
Andrew.

On 28/02/2012 4:56 PM, John Martyn wrote:
> I have encountered this issue before.
> The trick is to use the GetTopLevelWindow(GetFocus()) or if the jaws cursor 
> is already in the window, GetTopLevelWindow(GetCurrentWindow()). Make sure 
> the jaws cursor is active. Once you get a handle you can refocus this item. 
> If you need more assistance, I can post my script to detect top level windows 
> such as this. If you are navigating around and want the check window function 
> to take place, you would have to insert the function into one of the common 
> keys such as the up and down arrow, tab keys and such.
> Let me know if you get the idea.
> John Martyn
> 
> 
> -----Original Message-----
> From: jawsscripts-bounce@xxxxxxxxxxxxx 
> [mailto:jawsscripts-bounce@xxxxxxxxxxxxx] On Behalf Of Jerry Randell
> Sent: Tuesday, February 28, 2012 11:48 AM
> To: jawsscripts@xxxxxxxxxxxxx
> Subject: [jawsscripts] Re: Ideas for detecting the appearance of some 
> stealthy dialogs
> 
> On 2/28/12, Andrew Hart <ahart@xxxxxxxxxxxxx> wrote:
>> 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
>>
>>
> Did you experiemnt with a FocusChangedEvent Function?
> __________ 
> 
> 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
> 
> 
> 


__________�

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

Other related posts: