I actually have not proven that sufficiently, but I suspect GetObjectRect
becomes accurate in JAWS 15.
I just tend to avoid the whole mess and use UIA when I need accurate locations
nowadays. Admittedly though,
there are occasions when even that is a problem. For instance, some QT
applications (*points a finger at
TeamSpeak*) can start slowing down the more UIA calls you make.
On Tue, Jan 12, 2016 at 04:22:59PM -0600, Snowman wrote:
Interesting. So, does GetObjectRect actually use the accLocation stuf
behind the scenes, and convert it for you?
In otehr words, one should always use GetObjectRect, and never do
accLocation directly any more?
----- Original Message -----
From: "Doug Lee" <doug.lee@xxxxxxxxxxxxxxxx>
To: <jawsscripts@xxxxxxxxxxxxx>
Sent: Tuesday, January 12, 2016 2:48 PM
Subject: [jawsscripts] Re: get X Y coordinates for MSAA object
First, in case it's any comfort, I find this annoying and complex as well.
:)
Here's the problem with fixing it so we don't have to worry about it though,
and some details on what I think
JAWS has done with this over time:
When you use the JAWS UIAScriptAPI, you are using JAWS code to get
coordinates. Same with JAWS calls like
GetObjectRect, GetWindowRect, etc.
When you go to an MSAA object and get its coordinates with o.accLocation
though, you are not funneling the
coordinate values through JAWS; you are obtaining them directly from an MSAA
COM interface. This means JAWS
couldn't fix it anyway.
What follows is a mixture of slightly educated guesswork and rumor, and as
such, I can't guarantee its
accuracy:
I believe the various JAWS versions work like this with respect to DPI
awareness and coordinate translation on
a high-DPI system with a non-DPI-aware application:
JAWS 14 and older:
- The OSM will be wrong.
- MSAA coordinates will be wrong.
- UIA coordinates (JAWS 14 only) may be wrong.
JAWS 15:
- The OSM will be wrong.
- MSAA coordinates will be wrong.
- UIA coordinates will be correct.
JAWS 16 and 17:
- The OSM will be correct.
- MSAA coordinates will still be wrong (see above).
- UIA coordinates will be correct.
Btw, when I say the OSM will be wrong, I mean that pressing the left mouse
button on the word "OK" in the
off-screen model could click something somewhere else instead of clicking
what you expect.
I welcome corrections to all that info, as precision in this crazy
high-resolution world is sometimes plenty
useful.
On Tue, Jan 12, 2016 at 03:26:22PM -0500, Jonathan C. Cohn wrote:
My understanding is that since 96dpi was fairly standard, newer systems that
have higher DPI will still tell old programs that the dpi is 96 and then do
scaling to make things still readable. Programs that tell the OS that they
understand the new protocols can set scaling, so that their images somehow.
My questions:
For low vision folks that adjust their screen resolution to make items
readable will this still work with Windows 8 and 10? My father fits in this
category, and quickly jumped back to Windows 7 after finding 10 impossible
to use.
In terms of JAWS developers can we check if the app is DPI aware, does it
make a difference,. Doug mentioned that the bounds commands for UIA
correctly handle high DPI systems, but that the equivalent WINDOWS / MSAA
methods/functions do not adjust.
As a JAWS developer I would love to not have to worry about this level of
detail given an object within a window / object, I would love to use an
Object method that gives me the bounds of that object in a usable form.
Though even WindowEyes with Client/Window/Screen rectangles and points
doesn't give me the flexibility I would appreciate.
Jonathan Cohn
On Jan 12, 2016, at 2:35 PM, Snowman <snowman@xxxxxxxxxxxxxxxx> wrote:__________???
I can tell you that I took a look at the link Doug provided, and felt like
I
was drowning in a sea of detail without a grasp of the basics.
It's like going to school for the first time at age 5, and having them
start
you in the eighth grade.
But, that article is definitely not DPI for Dummies.
They talk about scaling in there. And, I think scaling is the way you
translate from the pixel coords we know, to get to the actual dot coords
on
the physical monitorl.
But, I'm still guessing.
----- Original Message -----
From: "Geoff Chapman" <gch@xxxxxxxxxxxxxxxx>
To: <jawsscripts@xxxxxxxxxxxxx>
Sent: Tuesday, January 12, 2016 3:13 AM
Subject: [jawsscripts] Re: get X Y coordinates for MSAA object
Wow! this is all very, very complex eh! It sure would be helpful to
understand it all indeed!
But, since I have not yet seen a response to the Snowman's impressively
comprehensive attempt to get our heads around this, from his current
understanding of the matter, do I take it we are all in the dark? as it
were?
----- Original Message -----
From: "Snowman" <snowman@xxxxxxxxxxxxxxxx>
To: <jawsscripts@xxxxxxxxxxxxx>
Sent: Saturday, January 09, 2016 11:08 AM
Subject: [jawsscripts] Re: get X Y coordinates for MSAA object
Thanks for this clarification. Good to keep in mind.
I have often tried to figure this out, but don't actually know anything
about it, which is part of the problem. I would love to hear somebody
explain it in language I could understand.
So, as you read my ramblings below, keep in mind that these are not known
facts, but I am just stating things I currently believe, in an attempt to
identify misconceptions.
So, is the DPI setting configurable, such that you could configure such a
laptop to be 96DPI standard, such that older apps would still work like
jaws
expects?
I don't quite understand that since, I thought the definition of a "dot"
was
a patch of illuminated color on a monitor screen.
If you draw a line on screen, that line is not a true continuous line,
but
is, in fact, a series of closely spaced dots. And, the DPI setting would
say how close they are to one another.
I expected that the location of each of the possible dots was a physical
property of the monitor, and thus not selectable. But, I thought I did
see
a DPI setting somewhere in some display properties. If I change that, am
I
actually changing the behavior of the computer such that, when that
setting
lines up with the properties of the physical monitor, stuff works well,
but
if not, then completely not?
Or, are their monitors that can operate with various DPI settings?
Next, what is the relationship between a Pixel, as understood by jaws,
versus a dot.
I played with this a bit a while back and, to be fair, I think that
version
of jaws did not track resolution changes without a restart, and maybe
even
a
reboot. So experimentation was cumbersome enough as to interfere with
my
learning process. And, I was playing with a very small set of
applications.
But so far, I have had the impression that on-screen objects in
application's have fixed dimensions, in terms of number of pixels. And,
by
changing your display resolution, what you are actually controlling is
what
percentage of the physical screen dimensions are occupied by this object.
Higher resolutions mean that the object takes more of the screen, much
like
a zoom control. High resolution means objects appear to shrink in size,
but
you get more of them visible. Lower resolution means they get larger,
but
fewer of them are visible.
For example, if you have a button whose top right corner is at 1280,1,
and
your display resolution is 1280 by 1024 or whatever that is, then the
right
side of that button will be at the very right side of the screen, because
the screen is 1280pixels wide. And, if you now change the display
resolution down to 1024 by 768, that button will disappear off the right
side. It will no longer be visible. But, if you take the jaws cursor to
that pixel address, you will still hit that button, as far as the
application is concerned.
So, I have had the impression that pixel-based addressing, meaning using
what JAWS calls screen coordinates, in order to locate some on-screen
object
is not affected by screen resolution. Jaws will still hit the same point
in
the object, no matter the resolution, so my script still works. My
relation
to the application seems to remain constant. What changes, is whether or
not that object is actually visible, or, if it is, how much of it.
To support that, there would need to be a translation between pixel
addressing, and dot addressing. And, it would seem pretty messy, since,
unless you really restrict the choices, you would have Pixels landing
between dots.
I wonder what a DPI-aware application would actually do. How doe sthe
DPI
setting affect the pixel address of an object.
So, can somebody provide a brief tutorial on this here? I would really
like
to understand this, and think it would be of general interest to finally
get
all this straight.
----- Original Message -----
From: "Doug Lee" <doug.lee@xxxxxxxxxxxxxxxx>
To: <jawsscripts@xxxxxxxxxxxxx>
Sent: Wednesday, January 06, 2016 9:45 PM
Subject: [jawsscripts] Re: get X Y coordinates for MSAA object
Beware that on modern high-resolution laptops, when the DPI setting is
not
standard (common nowadays I think),
and when the app you're scripting is not DPI-aware, MSAA coordinates can
be
wrong. UIA coordinates tend to be
right in my experience for these situations, at least in JAWS 16 and 17
and
I think 15. They are probably also
wrong in 14 and older. For DPI-aware apps, I think you'll be ok with MSAA
or
UIA coordinates. I welcome
corrections to all this; I'm basing this mostly on situations I've seen.
Many modern apps should be DPI-aware,
but legacy apps (VB stuff for example) will probably not be so.
On Thu, Jan 07, 2016 at 02:39:42PM +1100, Nick Allan wrote:
Thanks, I'll give this a try, didn't see the accLocation property.
Nick
-----Original Message-----
From: jawsscripts-bounce@xxxxxxxxxxxxx
[mailto:jawsscripts-bounce@xxxxxxxxxxxxx] On Behalf Of Snowman
Sent: Thursday, 7 January 2016 2:36 PM
To: jawsscripts@xxxxxxxxxxxxx
Subject: [jawsscripts] Re: get X Y coordinates for MSAA object
Nick,
use syntax like
you need integers to receive the output from the line below.
int t, w, l, h
If your MSAA object is in variable o, then
o.accLocation(intref(l),intref(t),intref(w),intref(h), id)
----- Original Message -----
From: "Nick Allan" <Nick.Allan@xxxxxxxxxxxxxxxxxxx>
To: <jawsscripts@xxxxxxxxxxxxx>
Sent: Wednesday, January 06, 2016 2:56 PM
Subject: [jawsscripts] get X Y coordinates for MSAA object
Hi all
I've got an MSAA object identified, but need to get its actual screen
coordinate as I need to check for a graphic to the left of the object on
a
toolbar. Is there a way to get the X Y coordinate for an MSAA object?
Nick Allan
Specialist Support
Vision Australia
454 Glenferrie road
Kooyong Vic. 3144
P: 1300 84 74 66
www.visionaustralia.org<http://www.visionaustralia.org>
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
__________???
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
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
__________???
View the list's information and change your settings at
//www.freelists.org/list/jawsscripts
--
Doug Lee, Senior Accessibility Programmer
SSB BART Group - Accessibility-on-Demand
mailto:doug.lee@xxxxxxxxxxxxxxxx http://www.ssbbartgroup.com
"While they were saying among themselves it cannot be done,
it was done." --Helen Keller
__________???
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
__________???
View the list's information and change your settings at
//www.freelists.org/list/jawsscripts
