Coordinate Percentage Algorithm

[UnknownWarrior]

So from all my research from this forum, I've came up with pretty much the same algorithm written many different ways -- all are yielding the same, yet wrong, answer.

In My PC the x spot where i want to click is in the 400 pixel.

In another PC is not in the same position because the resolution change.

So i do some maths. First, i think.. The porcentage of the desktopwidth that tells me where is the spot

If desktopwidth is the 100% then 400 will be the xx%

$xPercent = 400 * 100 / @DesktopWidth

so i grab that number and start using that number instead of 400 in the following way

$x = xPercent * @DesktopWidth / 100

I hope you understand my way to do it.

ToolTip( "Waiting for you to click the mouse to set initial position", @DesktopWidth / 2, 50, "Awaiting input.", 1, 2 )

;Set mouse click position

While 1

If _IsPressed( 01 ) Then

$MP = MouseGetPos()

$RelativePOSX = $MP[0] / @DesktopWidth

$RelativePOSY = $MP[1] / @DesktopHeight

ToolTip("")

ExitLoop

EndIf

Sleep(10)

WEnd

Func CoordSwitch($X, $Y, $W, $H) ; $W, $H - Original

; MouseClick("Left", @DesktopWidth / $W * $X, @DesktopHeight / $H * $Y, 1)

MsgBox(0, 'Coord', 'x = '&@DesktopWidth / $W * $X &@CRLF& 'y = '&@DesktopHeight / $H * $Y)

EndFunc

My example:

I want to click on a certain button with MouseClick. It is located at 885, 183 (we will just use the x coord for demonstration) with the resolution of 1440x900. I want to be able to click on that same button (it's very small) with a 1280x720 resolution as well. So, I plugged in 885 in any of those 3 equations and they ALL result in 785 for the answer. The problem? I used Au3Info and that coordinate actually resides on 772 (x).

Why such the big difference? I do realize there are aspect ratios, but I have not seen them demonstrated in ANY of the threads I found - and people claimed these conversions were working for them... (1440x900 = 16:10 and 1280x720 = 16:9 ratios)

Any ideas? o.o

Thanks

[PhoenixXL]

I want to click on a certain button with MouseClick

Its not the efficient way

Try with ControlClick and use Autoit Window Info tool to find the Information required

Then no problem should reside regarding resolution or the position of the Button

Regards

Phoenix XL

Edited July 18, 2012 by PhoenixXL

[UnknownWarrior]

I have to use MouseClick though

[JohnOne]

I don't get it, if a gui is 400 x 400 pixels

It is 400 x 400 pixels at 1440x900 res and it is 400 x 400 pixels 1280x720 res.

Please use MouseCoordMode Option, or provide some kind of believable scenario where that does not work.

[UnknownWarrior]

I'm not saying the GUI isn't the same - it would be. However - MouseClicks are not. And when you can't record the coordinates via the window (controlclick coords), you must use absolute coords so MouseCoordMode doesn't apply.

My example is above and you can simply test it by changing your screen resolution and try double clicking on a program on your desktop (leave the script as-is when changing res.). It won't click on the same program.

[Spiff59]

The formula works perfectly, it'll click on the exact same physical spot on your monitor, regardless of the resolution. Put a big greasy thumbprint on the target spot of your monitor and in 5 different resolutions the mouseclick will hit the spot.

I think you're expecting webpages or GUI's to be simply proportionally stretched or zoomed when you change resolutions. I've found that not to be the case. I believe everything is redrawn with different fonts, control sizes, spacings, etc. There's no guarantee that a button 20% from the left margin of the screen in a 1280 resolution will be redrawn exactly 20% from the left edge in other resolutions.

If you can't reference controls directly, then you'd need to maintain a table of coordinates, and use the appropriate set of numbers depending on the users resolution.

typo

Edited July 18, 2012 by Spiff59

[UnknownWarrior]

Ok, I get what you're saying here. So you mean there is no efficient way to convert a x-coordinate at 885 (1440x900 res) to a coord on a 1280x720?

Could the aspect ratio be the cause of the slight difference between the answer to the equation (785 x-coord) and the actual answer (772)? Would there be a way to somehow run that aspect ratio into that algorithm above?

[Spiff59]

If the Mona Lisa were your desktop background and you wanted to poke her in the eye with a mouseclick, I think the formula would work on all resolutions, because you are evenly stretching or shrinking the image proportionately to match the desktop resolution. The image is a single entity being resized.

I had no luck applying that principle in the past to system controls, html, and the like that are a bunch of seperate entities and seem to be sized, placed and spaced however Windows wants under different resolutions. I was suggesting you document the locations of each control under each supported resolution, and hardcode them in the program (or read them from a flat file if you prefer)

Global $aResolutions[3] = ["1024x768","1280x1024","1440x900"]
Global $aSaveButtonCoords[3][2] = [[?,?],[772,?],[885,183]]

; determine resolution at program start
$CurrRes = @DesktopWidth & "x" & @DesktopHeight
For $x = 0 to 2
    If $CurrRes = $aResolutions[$x] Then
        $CurrRes = $x
        ExitLoop
    EndIf
Next
If $x = 3 Then
    MsgBox(0,"","Unknown resolution!")
    Exit
EndIf

; later processing
MouseClick($aSaveButtonCoords[$CurrRes][0],$aSaveButtonCoords[$CurrRes][1])

Edit: It's certainly not as clean a solution as direct interaction with the controls, or even a bunch of Send("{TAB}{TAB}{ENTER}") statements, but it may be a way that works?

Edited July 18, 2012 by Spiff59

[UnknownWarrior]

Yeah, that surely WILL work, but I was hoping to avoid that. I have programmed it in 1440x900 already, I was just hoping I could find a way to convert all those coordinates [properly] so I didn't have to go back and record 600 lines of code again (a bit sarcasm, but you understand the frustration of having to redo something that's already done -- isn't that the point of automation lol?)