AUInfo Reading info under mouse on 2560x1440 screen wrong

[WoodGrain]

Hi All,

I'm trying to run a script to fire when a pixel at a certain location on the screen changes to a particular colour, however auinfo is unable to measure the colour where my cursor is due to my high resolution - 2560x1440 on a 13.3" laptop. Does anyone have a workaround or a fix for this?

If I move my mouse to the bottom-right corner of the screen auinfo reports the mouse position as about 1280x720, 1/2 my actual resolution.

Thanks!

[BrewManNH]

That must be one hell of a monitor to achieve that resolution on such a small screen. What does @DesktopHeight and @DesktopWidth return when your script is running?

[WoodGrain]

Toshiba Kira

idk, I've not used those before, I'll throw a script together over the w/e & get back to you

[BrewManNH]

That looks like a sweet laptop.

[WoodGrain]

@DesktopWidth = 1280

@DesktopHeight = 720

Actual Screen resolution 2560 x 1440, so it's exactly 1/2 of the actual resolution. I've heard the same with other people with these high resolutions. I get the same result if I use a pixel colour app to show the colour of the pixel under the cursor, seems apps just haven't caught up yet.

There's probably a way of programatically showing a virtual cursor location on screen as I move the mouse so I can see where it is actually resting and then take a location and colour reading?

[WoodGrain]

Anyone have any suggestions?

[junkew]

Savesceen as a bitmap to bmp file and read analyse the rgb content of the file.e

[WoodGrain]

Thanks junkew, tried that but the area I'm looking at is a gradient, so I'd need to grab the pixel location as well, if autoit can't read the pixel location then when I run my script it will probably be out too

[junkew]

Not sure what you mean with a gradient but if you can make a full screenshot to a bmp then you can grab every pixel you want or load it into gdi functions to manipulate. Search for findbmp and you will see how to get your screenpixels in a huge array. Other options are in the forum to run a fasm script in assembly to quickly analyse pixels.

Could this be the cause

https://social.msdn.microsoft.com/Forums/en-US/3bd3f425-a93d-47eb-b3c0-795bc2458b29/getsystemmetrics-returns-incorrect-screen-size-in-windows-mobile?forum=vssmartdevicesnative

[WoodGrain]

Thanks. By gradient what I mean is I am wanting to read a pixel colour change if a message appears, however the message itself has a gradient from mid blue at the top to dark blue at the bottom of the background, it is not a single colour. I'll have a look around for those tools you mentioned - cheers.

I threw this script together, I'll try it tonight and see where the cursor moves to and the colour it picks up, then just increment/decrement the values until it's in the right position, at which point I can convert the decimal colour to hex to see if it's roughly the right colour (eg http://www.w3schools.com/tags/ref_colorpicker.asp).

$width = 1000
$hight = 700
MouseMove($width,$hight)
$pixcolour = PixelGetColor($width,$hight)
$pixhex = hex($pixcolour,6)
ClipPut($pixhex)
MsgBox(0, "Pixel Colour", "Dec: " & $pixcolour & " Hex: " & $pixhex)

 

[WoodGrain]

Of course the colour may be completely wrong because of the screen resolution, in which case I could probably try doubling the pixel location..

[WoodGrain]

This might also return some interesting info:

Sleep(3000)
$locationX = MouseGetPos(0)
$locationY = MouseGetPos(1)
$msg = $locationX & "," & $locationY
ClipPut($msg)
MsgBox(0,"x,y", $msg)

 

Edited August 6, 2015 by WoodGrain

[Jon]

I'd guess that you are running with a dpi scaling setting of something other than 100%. Sounds like 200%. AutoIt doesn't have the resource manifest HighDpi set, so screen operations get converted and scaled. I can't think of an easy fix. If we manifest AutoIt for high dpi then it would work, but all the GUI controls would break at the same time.

Edited August 6, 2015 by Jon

[WoodGrain]

Aha! Yep, just had a look at my display settings, you are right.

If I drag it back to the left of the display setting everything on the screen is so small lol but if I run my mouse position script above it now gives me my correct screen resolution if I put my mouse in the bottom-right corner.

Hmm, ok, so looks like I'm stuck.

[Bert]

Is there some reason you need to check a pixel? Is there a control you can hook into to see if the status has changed? Pixel checking is the worst way to automate something.

[WoodGrain]

I'm not familiar with how to do that Bert?
I looked through the info that auinfo provided but there is no information change when the button becomes active so the colour change was the best option I could see.

That being said, the button is out of the range for AutoIt due to my high DPI scaling, so even if I could read the change I couldn't click on the button lol.

Edited August 7, 2015 by WoodGrain
additional info

[mpower]

I'm not familiar with how to do that Bert?
I looked through the info that auinfo provided but there is no information change when the button becomes active so the colour change was the best option I could see.

That being said, the button is out of the range for AutoIt due to my high DPI scaling, so even if I could read the change I couldn't click on the button lol.

Is it not something you could activate using ControlSend rather than clicking ?

[junkew]

check with the iuiAutomation thread in examples section and try if simplespy can reach your control (logically it should as its using the uiautomationcore.dll)

most likely the iuiAutomation stuff will have a property of the control if its active yes/no and as such no need to check based on the color.

 

[Bert]

I'm not familiar with how to do that Bert?
I looked through the info that auinfo provided but there is no information change when the button becomes active so the colour change was the best option I could see.

That being said, the button is out of the range for AutoIt due to my high DPI scaling, so even if I could read the change I couldn't click on the button lol.

junkew is right on point

[WoodGrain]

Thanks guys! I'll check it out.

In the mean time since Jon identified the culprit as DPI scaling I'm going to drop my resolution by 1/2 and reduce the DPI scaling which should move the button to a locatable and clickable area on the screen .