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

  • From: Andrew Hart <ahart@xxxxxxxxxxxxx>
  • To: jawsscripts@xxxxxxxxxxxxx
  • Date: Tue, 28 Feb 2012 17:44:03 -0300

Hi.  I checked out HandleCustomwindows (there are in fact three or four
of these functions, all called by FocusChangedEvent), but
FocusChangedEvent doesn't seem to be firing.  However, CreateWindowEvent
appears to be catching it very nicely.  I merely have to check that the
window owner is Foobar and use SetFocus if it is.  I'll have to try it
out over a period of time, but it seems to be working so far.

Listen, when I create my own custom CreateWindowEvent, should I be
chaining to the default CreateWindowEvent when my special case
conditions are not met?  I have done this for now, but am not sure if
this is considered the FS-approved kosher way to do this (and hence stay
out of unplanned trouble).

AutoStartEvent and my code to search out such pesky dialogs brings them
into focus (even if they have lost focus) whenever the user switches to
Foobar.  As far as I can tell so far, there's only ever one such dialog
on screen at a time, so I don't need to worry about deciding between
multiple dialogs.

Now I just need to nail down how to detect a loss of focus while Foobar
is running so I can restore it.  fortunately I have some 100%
reproducible situations where this happens so I have to experiment a
bit.  I think I stumbled across an event function in the FSDN that might
be useful here.

Thanks for all the suggestions everyone.

Cheers,
Andrew.

On 28/02/2012 3:41 PM, Travis Roth wrote:
> 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
> 
> 
> 


__________�

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

Other related posts: