Accounting for variable resolutions (coordinate issues)

[iGo]

Hello everybody,

Okay so this issue has been enough to get me to register - my first post!

I cannot for the life of me figure out what is up with a particular script I'm working on. This post is perhaps the most urgent issue.

First off, know that I've Google'd and searched the forums here thoroughly before posting. Usually I can find a solution somewhere. Not the case if I'm asking a question about it.

So - The Problem:

I have automated a very time intensive, tedious... repetitive task on my computer, and I've done so successfully. I want to share this with other people, so that I can save them time as well. Of course, however, all of my MouseClick (...) and MouseMove (...) and PixelGetColor (...), etc. commands are for coordinates specific to MY computer, at MY resolution that I determined them from. Including my computer, I have 3 computers that I can check my scripts on. They all have different resolutions. So to test that my script would work on somebody else's computer that I send the program to, I of course wanted to test it first on my 3 computers, which are all at different resolutions (and 2 different aspect ratios).

 

Attempted Solution(s):

To account for the varying resolutions, my instinctive thought was "duh.. just adjust the coordinate positions by a scale factor relative to the resolution on my computer, that I determined the coordinates on." Oh if only it actually was that simple. I've read probably 10 threads on here since then where other users suggested the same thing I thought of, because logically.. you'd think it would work. For goodness sake, it seems like something resolved by basic math. But no, if they had actually tested it (as I did), it doesn't.

Here's my code where I declare how much to adjust ("scale") the coordinates by:

$xScaleFactor = @DesktopWidth/1536  ; 1536 is MY width, in pixels, at my resolution* (I have an issue with this as well)
$yScaleFactor = @DesktopHeight/864  ; 864 is MY height, in pixels, at my resolution* (I have an issue with this as well)

Global $x = $xScaleFactor           ; make equal to the Scale Factor for simplicity sake when multiplying by this factor throughout the entire script
Global $y = $yScaleFactor           ; make equal to the Scale Factor for simplicity sake when multiplying by this factor throughout the entire script

and here is an example of me accounting for the new user's, possibly different resolution:

MouseMove ( 512*$x , 165*$y , 1 )    ; 512 and 165, respectively, were the X and Y coordinates on MY computer when I originally determined the coordinate positions

I guess first, as an "aside" question, I don't understand why my Resolution gets reported as 1536 x 864 (I've confirmed this with the Window Spy/Info tool.. the bottom-right of my screen is in fact shown as position ~1536, 864), even though my actual resolution is 1920 x 1080 ... proof:
http://prntscr.com/3bih1y

but what gets reported is..:

http://prntscr.com/3bijof

One thing I noticed is that 1920 and 1080 are *exactly* 1.25 (i.e. 125%) of 1536 and 864 - the correlation of which I admittedly do not understand. I've tried multiplying the scale factor by 1.25 to account for this and still... the coordinates that the other [test] computers move, click, etc. at are incorrect.

 

So.. does anybody have ANY idea? I feel like I've tried everything. I would like to avoid having to send them additional #include files if possible - this is just a big pet peeve of mine (I always feel like a program should be standalone, without depending on anything else.. it should be self-sufficient, neat, efficient.. send 1 script file, not 1 and 14 others just to make the damned thing work).

At first I wasn't wanting to change their resolution to what mine was while the script does its stuff (I feel like this would make them uncomfortable/freak them out), but I've noticed that the old _ChangeScreenRes User-Defined Function (UDF) seems to not exist anymore anyways. I also found while searching for a solution for this another function called "DisplayChangeRes" which might have worked (no idea how this worked, never heard of it before this), but nonetheless apparently that function doesn't exist anymore either.

Anybody?
Help would be MUCH appreciated! 

- iGo 

Edited April 19, 2014 by iGo

[Melba23]

iGo,

Starting at the bottom:

 

I would like to avoid having to send them additional #include files if possible

Then I suggest you use another language! Seriously, why the problem? You can use Au3Stripper to remove all the comments and blank lines from your script and unused functions and variables from the includes and what you are left with is a single script - so everything is "self-sufficient, neat, efficient".

As to the resolution problem - I would strongly suggest that you use a more reliable and efficient method to automate your tedious task. Can you not identify the various controls using the Window Info Tool? That would allow you to use the Control* functions which are not resolution dependent. What apps are you automating?

M23

Edit: And welcome to the Autoit forum, by the way.

Edited April 19, 2014 by Melba23

[iGo]

Yeah, if I need to include #include files, I may just mark them as hidden so that they don't make the folder look all ugly, lol. Clutter just agitates me I like things like this (ex: coding) especially to be neat, simple, elegant.

Regarding what is being automated. This applies to a BUNCH of things I've made scripts for over the years. I've wanted to be able to port over many different scripts I've worked on over the years to different computers, but never had been able to because of this exact issue (I would have to literally go through EVERY single coordinate and change them 1 by 1). This would affect scripts of mine where I'm utilizing Excel, Google Chrome, Notepad.. a bunch of different things (depending on whatever I was saving time with by automating with that script). About 99.9% of the time I'm utilizing multiple programs (i.e. not just Excel). I very often am interacting with a browser (Google Chrome).. it lets me check on things at home when I'm not there, lets me give people access to files of mine (employees, etc.) without compromising my security, etc..

Regarding the Control functions. Oh yes, how I've longed to use those lol. However, using them seems to be so conditional that I can never depend on them (I prefer to use things that work every time, so that as I get into the habit of using it I don't have random surprises). The Control function doesn't seem to help here, entirely.

For example:

When I use it on something simple like [Microsoft] Excel, yes, the "ControlClick Coords" are exactly the same:

I tested this simply, by highlighting and capturing the ControlClickCoords position for a constant object on multiple computers (I randomly chose to use/highlight the "Up" scroll button on the side.. the button at the very top of the scroll bar, pointing upwards, that you would click to scroll up 1 piece). I set both computers' Excel sheets to the same Zoom (80%), and recorded the positions.. = (8, 9). On another test computer (which even has a different aspect ratio), the coordinates matched (i.e. it took me to the exact same spot). So if I only used Excel, at least this would work, it seems (at least I suppose).

However, when I tested it in Google Chrome, it failed. This is a critical failure.

I tested this simply, by going to www.google.com and highlighting/capturing the lower-right of the capital G in their logo, because again this is a constant image (I can go to another computer and their page would be exactly the same).

On my computer the ControlClick Coords were: 688, 281.

On my test computer (same one as before, different aspect ratio) the ControlClick Coords were: 768, 255

On my second test computer (same aspect ratio as my main one, two lines up), the ControlClick Coords were: 614, 254

- Repeating the Google Chrome experiment with the scroll bar (as I did in the Excel test) yielded the same, failing results.

 

Any other ideas? Anybody?
They're much appreciated, ALL of them!

 

- iGo 

Edited April 19, 2014 by iGo

[Melba23]

iGo,

Did you actually read what I posted? You can get everything into a single script using Au3Stripper - no need for hidden includes.

Only some apps display control data in the Window Info Tool - many newer apps do not. For these you can try the IUIAutomation method which is explained here. Good luck.

M23

[FireFox]

Hi,

What does this code return :

Local $aWgp = WinGetPos("[CLASS:Progman]")

ConsoleWrite("Width: " & $aWgp[2] & "px" & @Lf)
ConsoleWrite("Height: " & $aWgp[3] & "px" & @Lf)

And also, your msgbox doesn't proof anything, post instead a fullscreen screenshot which will show the screensize by the size of the picture.

I would like to say a word about includes : those are optional librairies required if you want to use custom functions or some constants (which are a good coding practice).

Edit: Why don't you send them the compiled executable instead of the sources ?

AutoIt is pretty neat about sources files, look at the C# all the files it creates. Just zip all it will be fine

Br, FireFox.

Edited April 19, 2014 by FireFox

[MilesAhead]

Another approach you might try is calculating the percentage of the work area for each x and y you use on your monitor.  Then get x and y on the "foreign" monitor by multiplying the original x and y by that percentage.  You may have to take into account where the client area of the window starts.  How many pixels x and y etc..  I'm not sure how constant this is across resolutions.

See the function below in Snippets to get the work area

_GetDesktopArea()

[JibsMan]

iGo, I have the exact same resolution on a ASUS Q501L Laptop. We are also trying to map MouseClick coordinates for multiple displays. Notwithstanding the suggestions above, did you resolve your issue? IS there a mathematical solution to the 1536 x 864 Resolution problem?

Thanks

JibsMan

[AdmiralAlkex]

Based on the OP's screenshots you can tell that he is running with increased DPI, so are probably you. Check your screen settings.