[jawsscripts] Re: hairy problem on a project, re differing coordinates yielded in terminal emulation installations

  • From: "James Panes" <jimpanes@xxxxxxxxx>
  • To: <jawsscripts@xxxxxxxxxxxxx>
  • Date: Mon, 1 Dec 2008 05:56:45 -0500

Hi Jeff and Tim,

Tim's idea is on the right track, but does not go far enough.

If you must use absolute coordinates, make them global variables. You will 
need coordinates for x and y offset. You will also need a row height and 
possibly a character width value.

Place these values in a ".ini" file and load them at run time. Try using the 
AutoStart event to perform this task.

By placing the values that are resolution dependant into a separate .ini 
file, you eliminate the need to touch the code every time the screen 
resolution changes.

If you are really clever, you can create a utility to automatically detect 
screen resolution and set these values with a hot-key.

HTH


Regards,
James

jimpanes@xxxxxxxxx
jimpanes@xxxxxxxxxxxx
"Everything is easy when you know how."

----- Original Message ----- 
From: "Tim Burgess" <tim@xxxxxxxxxxxxx>
To: <jawsscripts@xxxxxxxxxxxxx>
Sent: Monday, December 01, 2008 5:25 AM
Subject: [jawsscripts] Re: hairy problem on a project, re differing 
coordinates yielded in terminal emulation installations


Geoff,

I don't think there's going to be a quick fix here.  I avoid absolute
co-ordinates like the plague for exactly the reason you're having problems.
Having said that, there are definitely situations where you can't get away
from them and, in such situations, I declare 2 constants: X_OFFSET and
Y_OFFSET that are factored into every co-ordinate call.  The advantage of
this is that, if you ever have to move machines and you end up with the kind
of situation you describe, you just change the values of the constants to
account for the difference.  On the original configuration they'll both be
set to zero, but they can obviously be changed to either negative or
positive values according to need.

Best wishes.

Tim Burgess
Raised Bar Ltd
Phone:  +44 (0)1827 719822

Don't forget to vote for improved access to music and music technology at

http://www.raisedbar.net/petition.htm

-----Original Message-----
From: jawsscripts-bounce@xxxxxxxxxxxxx
[mailto:jawsscripts-bounce@xxxxxxxxxxxxx] On Behalf Of Geoff Chapman
Sent: 01 December 2008 01:20
To: jawsscripts@xxxxxxxxxxxxx
Subject: [jawsscripts] hairy problem on a project, re differing coordinates
yielded in terminal emulation installations

ah Mighty scripters.
ok, I've got a really hairy one that I'm very desirous of any assistance
with, that anyone might be able to give me. although it's not directly
scripting related, but it kinda is.

The explanation is a tad lengthy, but I wanna try and be as thorough as I
can, and present you with as much information that I can into the problem,
so as to hopefully minimize people having to ask if I've checked this or
that etc.
so, ... if you could bear with me to read through it?

Last year with the so kind and considerate help and fantastic knowledge of
people on this list, and serious input from another guy who isn't on this
list, I was able to complete scripting up a system for pizza hutt call
centre order takers, such that a blind person could work in their call
center and do the job of filling out all the necessary details on the
various screens to take orders, confirm addresses, store opening/closing
times where applicable, confirm pricing for products, read back the pizzas
to the customer in human language rather than code, type any special
instructions, etc.
now apparently Sighted Order takers have only "dumb terminals," connected to
what I believe is called an A S 400 server? if I have the terminology right.

But in order to give jaws a chance at the thing, of course it needed to be
opperable in a windows environment.

So, pizza hutt installed on a windows box, what seems to be being referred
to as a 5250 terminal emulation software called IBM client access express,
version 5.0, as indicated in the about box, and was thus able to connect to
the as400 server using this setup, causing the main ordering terminal window
to occur in this environment.


So last year, I was able to complete this system on that Pc and the Blind
ordertaker has been happily employed and using it for a year.
That pc was a generically built one from a shop I trust that I've been using
for many years, with reputable components etc.
But it wasn't a branded one.

Now they wish me to make efficiently accessible, what they call the advanced
CSR functions, and they've given me a newish pc, this time a branded hp one,
(hardware specs detailed at the end,) again loaded with the same version of
the IBM client access express terminal emulation software, that was put on
the original pc.

ok now here's the problem.
on the NEW development PC, there's a few serious display rendering
anomalies, that are simply causing the system I previously built, not to
function at all on this new PC. and I obviously simply must find out why,
and how I might fix it, before I can begin to start coding up anything else.
Because, wisely or unwisely, pretty much everything I've done in the
scripting code of the system I built, in being able to glance at, and handle
the autoLoading of new frameSets into memory to cope with speaking right
frame/field  labels for differing screens, has all been done pretty
carefully using absolute pixel coordinate functions. like GetTextInRect()
etc, Which I found to be the most reliable method for both triggering and
often also glancing at/gathering data for display in virtulal viewer upon
double Click of the keystroke, for easier review etc.
I.e. this GetTextInRect function isn't robust in the sense that it didn't
use either application window, or current window relative boarders, but
absolute ones. Even though some of the functionality I used, did use frames,
which presumably would've at least been application window boarder relative.

There are a couple of issues, and I'll take the major one first.
But they're all display coordinate related.

1. the X/Y coordinate of the top left hand corner, of the actual terminal
window itself, is sitting approximately 28 pixels lower in absolute terms
relative to the top of the screen on my new pc, than it sits on the prior
one.
The x coordinate however, is identical on both pc's.

This is my primary problem.

2. The TitleBar, Menu Bar and Graphic Toolbar of the actual IBM client
access express 5250 program, which lie above this main terminal window, are
also not sitting in identical spots re their absolute Y coordinates, but,
for example they're only off by a margin of 3, 7 and 8 pixels, in case of
the TitleBar, menuBar and ToolBar respectively.
I.e. with the old PC that's working, the TitleBar is sitting at an absolute
Y coord of 13, whereas the old Pc, it's sitting at a Y coord of 10.
The menu bar sits at a y coord of 29, whereas the new pc they've given me to
use now, menu bar sits at a y coord of 36.
The ToolBar below this, starts on the old working pc, at y Coord 54, whereas
the new one it starts at an absolute y Coord of 62.

But, as I say, the top left corner of the emulation window itself, on the
old working pc, starts at an absolute y coord of 82, whereas on the New pc,
it's found at an absolute Y Coord of 110.
So this to me means there's some anomaly between the bottom of the toolBar,
and the top of where the terminal window itself starts, which I've gotta try
and get to the bottom of, and eliminate.

All the specs related to the toolBar I can think to check, via right
clicking on it and going into toolBar styles, are the same on both pc's.
Jaws reports The graphics as 18 by 16 on both PC's, when the "show text on
toolBar" option is unchecked.

3. on the old PC, jaws reports the font inside the main terminal screen
itself, as IBM 3270 19 point, whereas on the New Pc, it's reporting as IBM
3270 18 point.
This effectively means, that each line turns out to be 26 pixels in height
on the old working pc, and only 24 pixels in height, on the new one. which
of course means that as one progresses vertically down the screen, the
absolute coordinates are going to get further and further at variance
between the two systems, and things will thus break by degrees depending on
which part of the screen we are relying on things being at identical
absolute coordinates relative to the top lefthand corner.

Of course both app windows have been checked for maximization.
every other view and toolBar styles related issue I can think of to check,
has been checked on both pc's, and appear identical.

We've of course checked Screen Resolution and color bit Depth on both PC's,
and they report identical. Both have windows xp professional service Pack 2
installed on them.

the old pc is a generically built one as I say, but has a separate NVidia
Display adaptor  in it model Geforce 7300GS, (with either 128 or 256 meg
ram, I can't quite remember which,) 3.0ghz Single core CPU, 1 gig system
Ram.

The new Pc is
an hp3530, with only 512 meg system ram, and a 2.8GHZ CPU, using if memory
serves, an onboard intel extreme graphics adaptor, I think the 865G chipset?
don't quote me on that last spec though as I haven't written that down?

any clues anyone might throw at me to solve this one would be ever so
greatfully recieved.

thanks.

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

__________ 
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:

  1. Home
  2. jawsscripts
  3. Archive
  4. 12-2008