[jawsscripts] Re: Frames: was RE: script help.

Wow sean!

well, Thank you so much for your so kind words on my dashed off little
posting!  I've never gotten such a rave review before! <grin.> I feel all
warm and fuzzy honored now.
<smile.>


Truth is, Before I knew anything about scripting, and I don't know much now,
<smile,>
Frames were kinda my "only game in town!" as it were, so I cut most of my
teeth in configuring things utilizing them.
However then in 2007, I got a job coding up an accessible system for pizza
hut here in Australia, so that a blind person could readily access the call
center as400 terminal emulation based system they're using out here to take
orders and things, and I used frames extensively for that too! because, so
I'm told, I cannot of course verify it myself because of my almost total
ignorance of window hierarchy structure and the like,
that it seems in this kind of environment, there are no separate, "windows,"
going on in here where stuff appears, that you can use any kind of window
handle milarky to grab data that way anywayz!
and although it's all very keyboard drivable,
of course nothing talks at all by default as you tab around in this puppy.
I can't quite remember now, but I don't think
focusChangedEvent even runs as you tab!

So OnFocus, OnText,  and static Frames, and the GetTextInRect  functions,
became my bestest friends! <grin.>

much joy was, eventually, obtained from utilizing these.

Of course soon I found I had to subcontract in a real scripter, Jim
Snowbarger, whom I was working with at the time testing HotSpotClicker for
him,
to build me this very cool bunch of utilities to manage my frames, such that
I could have multiple FrameSets going on, one for each new screen pretty
much.
Since of course one soon runs into limitations of frames sorta crashing over
each other, across multiple screen situations if you've only got one
FrameSet for the whole jolly application!
.  So what Jim's custom built Frames managing utilities enabled me to do,
was create new frameSets as needed, named with screenNames that I'd work
out, from the resident app.jff and jfd files I was creating them in, and
then Load those new ScreenContextual frameSets to handle that screen,
over the app.jff and jfd files when particular text that certain ONText
frames were watching for denoting certain screens,
appeared.

He also built me very funky functions such that I could save or delete
individual frames as I tweaked them, to or from any of the Screen based
frameSet names I'd created. Such that I could, for example, create a new
OnTextFrame that might need to be present in certain frameSets, in the
app.jff/jfd file, then save that frame out to the ScreenBased frameSets I
needed it to exist in.

now I know all the coders out there are probably groaning with the
methodology I chose to make this all happen, but, I didn't know any other
way, and after an extensive period of time, <grin,> I was able to get it
functioning using those crazy sounding methods!
of course one had to reeeally mess around juggling priorities of the frames
etc, and one did begin to run into some slight vagueries of behaviour when
pushing the jff's that hard, but, It did work a treat in the end.
The person is successfully working in the call centre now with it that way.

But frames really are very very powerful I reckon. I mean, for ages and ages
I was under the crazy impression that the only two validation rules for them
firing, were Window Title and Window Class.
and that all one could do was to leave them active or disable them.
But of course this is sooooo not true! you also have two other validation
types, Window Text, and Frame Text, which you can add to, or replace the two
default Widnow title and Class validation rules as desired.
and, you can modify the comparisons the rules will check for as well.
Contains, is the default, but you can alternatively choose, Is, is not,
Contains, or does not Contain, as relating to text in the Frame, the window,
the window title, or the class.

And then they've got all the events you can get the frame to do! all  listed
there.  and two of them which are very useful of course, is to run script,
or run script event. which efectively means you can create your own function
in the jss, it has to have no parameters though,
and call that function as one of the Frame events.  you type it in there
without parenthisies, and it'll run them!
and you can even run a scheduled function, if you create a function in the
jss, that then schedules another function, so sorta daisyChaining them that
way, means that I could time delay some functions a bit when needed.
very cool.

What I did was to set up certain OnFocus frames, such that when the focus
moved inside them as one tabbed about, it would trigger the reading of other
data onScreen, which I'd set up frames around each individual bit of data I
might need spoken, and put in custom SayString prompts as well if needed,
such that the user knew where they were.

Crucial to getting this to work reliably though, was,
A. to first choose the right kind of cursor in the pcsws 5250 application
that jaws liked. It had to be blinking and underlined from memory, not blok
etc. then jaws always seemed to reliably know where the cursor/focus was.

B. when creating ONFocus frames, I'd route JawsToPc, then, I discovered that
I needed to always altShiftLeftArrow twice, to move the left edge of the
Desired OnFocus frame, 6 pixels to the left of where jaws reckoned the focus
actually was.
this increased my reliability of OnFocus frames to 100 percent in this
particular application, so long as the priorities were set carefully, when
these existed inside other larger frames that may've been watching for other
things ... etc.



I'm creating another system for them now actually, for their Advanced CSR
ordertakers, which is a whole new bunch of screens in the same kind of
environment. But I'm using more GetTextInRects this time around than I did
last time, which seems to me to be a very similar thing really, all very
static and non-dynamic, just like frames admittedly are, but, this is for
stuff that remains very static in where things appear in this kind of
environment, so it works ok here.
I'm also gunna utilize much more watching for stuff to come in to
NewTextEvent, then schedule screenCheck functions I'm building, to then
check whether that data is in a certain spot on Screen, and if it is, to
then autoSpeak promptts or load the right FrameSets for that screen or
whatever, rather than relying on so many OnText trigger type frames, having
to be in multiple sets, which gets kinda messy after a while. <grin.>

I'm also gunna use KeyPressedEvent, like the other guy up here was doing as
well, to enable me to give the same keys, multiple differing jobs dependent
on Screen Context, with another little utility function that Jim built for
me, which is just a little SaveKeyHistory deal, which one places at the top
of KeyPressedEvent.
I think it keeps a scrolling record of keys last pressed, and has another
little KeyboardTimeOut helper function that runs with it which facilitates
IsSameScript to work as it normally would as well.
Keyboard Help for each individual key on each screen can also be
individually gotten to speak contextually, using another outside If,
statement in KeypressedEvent, checking for the 0 or 1 status of a variable
called gbKeyboardHelp
so that this time around, I hope that I can not only have different frames
working on different screens, but also utilize a few similar Keystrokes, to
run different functions based on the screen context, which will be even
nicer than before.
where I was still tied to finding new keys to glance at new whatever new
frames I might have on individual screens, because I was just using the one
jkm entry for each keyStroke.


From: "Sean Randall" <seanr@xxxxxxxxxxxxxxx>
To: <jawsscripts@xxxxxxxxxxxxx>
Sent: Tuesday, February 17, 2009 10:55 AM
Subject: [jawsscripts] Frames: was RE: script help.


> Geoff,
>
> Sorry for the splintering topic here but I wanted to thank you for your
very
> well-done comments on frames.  Myself (and I suspect many others) overlook
> frames as the "non-programmers" way of making accessibility modifications;
> but your message has made me realise how much of an idiot I'm being.
>
> I think that you are correct when you point out that a lot of our
grievances
> with frames stem from the fact that, in dynamic situations, they can
become
> unreliable.  A change of screen resolution and your neatly-cultivated
frames
> become utterly useless - in fact, often detrimental to whatever
application
> they're used in.  I even saw a frame messed up by a tooltip once and the
> only way it read properly was when the mouse cursor was safely positioned
> away from the item in question.
>
> Still, you've opened my eyes to the fact that frames have possibilities.
I
> reckon that your message should be saved to the jawsscripts wiki for the
> benefit of others - how many times, scripters, have you written a script
for
> yourself without even thinking of a frame?  I'm certainly guilty of that
> one.
>
> Sean.
>
> -----Original Message-----
> From: jawsscripts-bounce@xxxxxxxxxxxxx
> [mailto:jawsscripts-bounce@xxxxxxxxxxxxx] On Behalf Of Geoff Chapman
> Sent: Monday, February 16, 2009 11:47 PM
> To: jawsscripts@xxxxxxxxxxxxx
> Subject: [jawsscripts] script help.
>
> oh BTW stephen, I haven't at all tested Rui's suggested code for solving
> this one, but just to inform you too, that in my very very limited
knowledge
> and experience of scripting, control ID's of windows may sometimes not be
> static and/or useful at all! and sometimes, your text that you want auto
> spoken, may not even be written in a separate window as defined by the OS
> anywayz!  like more and more modern programs in my again very limited
> experience, seem to not be doing!
> So what people are suggesting up here for your help, may not necessarily
> produce the results you desire. that's not because the information is
wrong,
> it's just because there seem to be such a miriad of ways developers can
> build applications, in how they structure them etc, that one solution just
> might not work, to bring the actual end user result joy that you desire.
> agaomn again not wanting to put you off at all, or make anything seem
> superior or out of reach or anything, just seeking to give you some
> perimeter perspectives that if you haven't delved around this area much,
may
> not have occurred to you before.
>
> hanging around here is certainly one cool way to learn things though.
>
> I've learned stacks and continue to learn!
>
> BTW, I've had a fair bit of experience in usage of Frames over the years,
> since I've had to reeeeally pull some stops out of them because they at
> least had a front end wizared style approach which negated me having to
> learn every sylabol of a language, to get the leastest acccessibility joy
> done.
>
> So I'd be interested in you perhaps telling more of what you tried and
what
> failed, in the way of your frames usage. because, frankly, if stuff is not
> gunna be moved around to varying screen resolutions etc, I'fe personally
> found that frames and frames manager can be a jolly powerful and very
useful
> tool, to solve some simple access problems, like glancing at stuff fast,
or
> having stuff automatically spoken in various situations etc.
>
> you said initially that you felt the frames idea may've been inadequate
due
> to your suspicion that the area where the desired text is being written,
> might actually vary or move position.
> Is this an actually verified phenomena?  i.e. with careful coordinate
> dcheckings of top/bottom lines of text being written etc, or with eyes? or
> are you just assuming it due to it not seeming to "work," when you first
do
> it?
>
> Because like scripting although in my view far simpler, though I realize
not
> in everyone up here's view who knows the language, Frame debugging has
some
> knacks to it as well, which can be well worth working through, if you
don't
> think you're ready to wanna dive in an learn scripting methodologies.
>
> i.e. the simplest one that breaks them is, you need to make sure that the
> window Titles it grabs when the frame is being defined, don't contain
> non-static information in them, meaning, when you define the frame, the
app
> window it finds and notes down the title of, might contain certain text,
> that won't be there, in other environmental situations.  when it isn't, of
> course if window Title matching is taken as one of the validation criteria
> for the frame properly firing and doing it's job, then it will fail!
because
> that text which was there when the frame was defined, is now gone, or
> changed! so it's vital to just go into frames manager, and then into the
> properties of the frame your seeking to define to speak any new text that
> enters it, and suss out what the window title has in it, or even just
> disable window title totally at present, from being classified as
validation
> criteria, then saving your frame changes as you exit frames manager, and
> then seeing if your frame works.
> Also, using the jawsKey+control+A keystroke, to display all active frames
in
> virtual viewer, can help you to debug, because you can see easily then
> whether your frame really is spanning the full content of the area your
new
> text keeps being written in.
> hth.
>
> geoff c.
>
> __________
> Visit and contribute to The JAWS Script Repository http://jawsscripts.com
>
> View the list's information and change your settings at
> http://www.freelists.org/list/jawsscripts
>

__________ 
Visit and contribute to The JAWS Script Repository http://jawsscripts.com

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

Other related posts: