[jawsscripts] Re: A last-gasp attempt at this 3270 problem of mine
- From: Steve Matzura <number6@xxxxxxxxxxxxxx>
- To: jawsscripts@xxxxxxxxxxxxx
- Date: Thu, 14 Jun 2012 10:32:56 -0400
Ah, my question answered! That explains why I didn't know about it.
This poor user only has JAWS 11! I might go back there with a 13 demo
and give it another go.
On Tue, 12 Jun 2012 05:59:34 -0700, you wrote:
>I'd agree with the results viewer. That seems to be the best bet in forting
>the information. Of course this would make it only for JAWS 13.
>John
>
>-----Original Message-----
>From: jawsscripts-bounce@xxxxxxxxxxxxx
>[mailto:jawsscripts-bounce@xxxxxxxxxxxxx] On Behalf Of Steve Matzura
>Sent: Tuesday, June 12, 2012 5:35 AM
>To: jawsscripts
>Subject: [jawsscripts] A last-gasp attempt at this 3270 problem of mine
>
>Yesterday I spent a very productive three hours framing, labeling, testing,
>triggering, and documenting a very busy screen on a 3270-emulation-based
>application. This thing was dancing on the ceiling by the time I was
>finished with that screen. You could hot-key-read any one of 35 fields on
>the screen, with or without field names, which meant that I had to define
>two windows for each and every field, and just in case you wanted to modify
>any of those fields, you got a complimentary left-mouse-button click on that
>area of the screen which would force the PC Cursor to that location so you
>could type something in if so desired or if that area of the screen were
>even designated as a field in the 3270 window definition back on the
>application's home-base computer. Really neat stuff!
>
>Then, the second part of my day came crashing in. A summary screen
>consisting of eleven lines of what amounted to a history view of account
>activity in reverse chronological order, displayed in a spreadsheet type
>layout, which needed to be broken up into its individual fields, of which
>there were six per line, and searchable and/or filterable by certain
>criteria within the data, such as show only payments, show only bills, show
>only meter readings, etc.
>Ideally, this should be available from the application itself, but it isn't.
>If JAWS had the capability to define frames within frames, and I don't mean
>just define another separate frame that just so happens to be a sub-area of
>another frame, or if the ability existed to load a separate set of frames
>and hot-key triggers for different screens all with the same window name or
>control ID, I'd be set! Anybody remember old JFD and how you could do stuf
>like that back then? I was also thinking of trying to write a script which
>could navigate these eleven lines of data and read only those lines where
>certain information was displayed, like the code or text to indicate a
>payment, for example, so the end-user could press a key and have the eleven
>lines filtered the way they needed, but I couldn't for the life of me figure
>a way to do this and get it coded in an hour or two! Frames are great
>things, but they're not smart in any way, shape or form. You can't tell a
>frame "read this if you contain certain data, keep silent otherwise."
>At least, I don't *think* you can. The only possible way I could think of to
>do this was if the information was color-coded in some way, but it isn't.
>Everything on the screen is the same color except the modifiable fields, of
>which there turned out not to be all that many.
>
>And I haven't even gotten to tell you about another data select screen where
>you put a selection mark in front of a summary line, hit a function key, and
>get one of half a dozen selectable new screens with detailed information on
>the summary item you selected! An incredible amount of data is available
>through this system. I've been in the data-mining industry for years, but
>not since I worked on stuff for the securities industry have I seen stuff
>like I saw yesterday. And they want the customer rep who operates this thing
>to have access to it all so that customers can check on any aspect of their
>account with this company. The customer service industry has come a long
>way. The reports this system produces must be real eye-openers!
>
>... but I digress ...
>
>Then there's the question of just how many key combinations can one person
>be expected to remember for one little old application if I were to define
>frames for every single field on every single screen, most of which wouldn't
>even make sense to be used as such, not to mention I'd run outa keys before
>I ran outa fields!
>
>It was for this reason that I have prepared a report, not yet submitted,
>that states that scripting for this application will not go far enough to
>satisfy the access requirements of a JAWS user to work with it and get the
>job done for which the application was originally written in any kind of
>efficient manner. However, before I submit this report, I thought I'd throw
>it out to you all for one last-gasp effort to see if there's anything I
>haven't tried that I should, etc. Your input greatly sought and appreciated.
>
>__________o?=
>
>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:
