[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:39:56 -0400
Wow, Paul, sounds intense, and possibly a bit out of my league insofar
as engineering goes, but I'm an old-dog programmer that loves learning
new tricks. I just wish I had the opportunity to go back and play with
it, even on my own time at this point. Could be very interesting.
On Wed, 13 Jun 2012 21:50:55 +1000, you wrote:
>Hi Steve,
>
>I believe frames can be made to be quite intelligent. Frames by default
>call the NewTextEvent to do their speaking, but if on the "Events tab" on
>the actions page, you define a user created function, which has the same
>format as NewTextEvent, then you can do all the checking & processing you
>want before finally saying, or not saying the frame content. .
>
>Indeed, that is what I previously did to clarify information on the 3270 we
>use at work.
>
>There is now a new function, not available when I was using the frames, but
>may suit your needs. NewTextEventShouldBeSilent takes very similar
>parameters to NewTextEvent, & with nested IF statements checking the frame
>names & text from the frame, you may be able to silence the unwanted
>information, & allow the rest to go through to NewTextEvent.
>
>Some years ago, we went through a brief period where frames were quite
>unstable, & I was forced to abandon the above method, in favour of the
>below. Frames again became reliable, but I found advantages in my new
>method, so did not return to them.
>
>The 3270 emulator we use at work has some complex screen arrangements, but
>may not be similar to what you are discussing, as I could not quite grasp
>the description.
>
>As mentioned in an earlier post, reading the information as if it was in a
>htm table is often a good way of sorting out a busy screen. I dont have the
>knowledge to do it by compiling it in the virtual buffer in table format, so
>I set up a process to define the table coordinates automatically on arrival
>to each screen layout type. Then allow the invisible cursor to move with
>the table reading keys, announcing the column headers before each item in a
>row, & the row header before each item when moving down a column.
>
>As column headerscan be from 1 to 3 rows, each screen layout type defines,
>in seperate variables, the top & bottom row of the headers, the bottom of
>the table, & the left edge of each column including the row header if
>present, & the right edge of the table.
>
>That way, the same processing & keystrokes can be used for any table I have
>defined.
>
>I found that on some tables that I only needed information in a few columns,
>so I set up a hot key to cause the tables on those screens to be redefined,
>including only the wanted columns. The normal table keystrokes then read
>fewer columns.
>
>When inside one of these defined tables, the invisible cursor is moved up or
>down with the usual nexc or prior line functions by the keys that usually do
>UpCell or DownCell. However, when using the NextCell or PriorCell keys, the
>cursor is "MoveTo" the beginning of the next column, & SayTextBetween with
>the current & next column beginnings as the parameters. the invisible cursor
>is already there if the user needs to read character by character.
>
>Over the years, the system has "morphed" into a monster, but so has the
>system we are trying to access.
>
>Hope some of this may be useful.
>
>Regards,
>Paul from Australia
>
>
>----- Original Message -----
>From: "Steve Matzura" <number6@xxxxxxxxxxxxxx>
>
>
>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.
>
>__________�
>
>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:
