Screen Resolution Issues

[labrint]

A simple code such as the one below is not working on some systems (few). Windows 10 and no antivirus. Why is this?

Can anyone fix it?

Code: Select all

winactivate, ahk_exe application.exe
winwaitactive, ahk_exe application.exe
MouseClick, left,  42,  214

[AviationGuy]

Try to run as administrator.
Or use a hotkey like so,

Code: Select all

f1::
winactivate, ahk_exe notepad.exe
winwaitactive, ahk_exe notepad.exe
MouseClick,, 42, 214
return

PS. Mouseclick is left by default so you can leave the left parameter out.

[labrint]

I figured out the problem but not entirely.

The mouse wasn't clicking my fixed co-ordinates because some clients had a large discrepancy in screen resolution.

Does anyone know a mathematical formula that converts co-ordinates based on screen resolutions?

Example I have a co-ordinate of 42,219 with a screen resolution 1440x900 and I need to get the co-ordinates for a screen resolution of 1920 x 1080

[AHKStudent]

I figured out the problem but not entirely.

The mouse wasn't clicking my fixed co-ordinates because some clients had a large discrepancy in screen resolution.

Does anyone know a mathematical formula that converts co-ordinates based on screen resolutions?

Example I have a co-ordinate of 42,219 with a screen resolution 1440x900 and I need to get the co-ordinates for a screen resolution of 1920 x 1080

Test like this

Code: Select all

xp := floor(A_ScreenWidth // 34)
yp := floor(A_ScreenHeight // 4.1)
msgbox, % xp "|" yp
ExitApp

[SOTE]

In situations where you want a script to run on multiple computers, it's often best to look at using the keyboard or commands like ControlSend, ControlClick... The ControlSend and ControlClick often make for the most transportable type of automation scripts between computers.

ControlSend [, Control, Keys, WinTitle, WinText, ExcludeTitle, ExcludeText]
ControlClick [, Control-or-Pos, WinTitle, WinText, WhichButton, ClickCount, Options, ExcludeTitle, ExcludeText]

At the very least...

Code: Select all

If WinExist("ahk_exe application.exe") AND WinActive("ahk_exe application.exe")
{
Send this key
Send that key
}

The next layer of reliability is often using the keyboard, as oppose to MouseClicks, because the different computers will have different screen resolutions. Keyboard automation, is often the same keys, regardless of computer.

And if you must do MouseClicks, at least try to specify the correct window, where you can get Relative Coordinates of the active window. So even if you are forced to do MouseClicks, it's not for the entire screen, but specific to that application and it's windows.

[labrint]

I use them SOTE. This is a particular situation where it is impossible to use ControlSend/Click, because the Table Cell I need to click does not have a ClassNN.

Interesting AHK Student. Can you tell me how you arrived at 34, and 4.1?

[AHKStudent]

I use them SOTE. This is a particular situation where it is impossible to use ControlSend/Click, because the Table Cell I need to click does not have a ClassNN.

Interesting AHK Student. Can you tell me how you arrived at 34, and 4.1?

You mentioned "Example I have a co-ordinate of 42,219 with a screen resolution 1440x900" and according to my math that means for example that if you do 1440 / 34 is about 42 so I figured maybe you try doing the same for larger monitor, not reliable way to do things as mentioned but if this is what you need maybe it will work

[SOTE]

I use them SOTE. This is a particular situation where it is impossible to use ControlSend/Click, because the Table Cell I need to click does not have a ClassNN.

Interesting AHK Student. Can you tell me how you arrived at 34, and 4.1?

You mentioned "Example I have a co-ordinate of 42,219 with a screen resolution 1440x900" and according to my math that means for example that if you do 1440 / 34 is about 42 so I figured maybe you try doing the same for larger monitor, not reliable way to do things as mentioned but if this is what you need maybe it will work

Hmmmm.... Since this is a kind of math problem. This does seem like the basis of a script or function that calculates the screen, and auto adjusts X and Y. Seems like Sysget (SysGet, OutputVar, SubCommand [, Value]) or A_ScreenWidth and A_ScreenHeight would do it, but have never "stress tested it" against multiple computers with different screen resolutions. After knowing the monitor size, relative to the original computer and the mouse coordinates used, some funky math could be applied so that those mouse coordinates would work on the new computer.

I have done GUI resizing for multiple computers (applying some math), using A_ScreenWidth, A_ScreenHeight, A_GuiWidth, A_GuiHeight, and WinGetPos. Which worked pretty well. Though this situation is different, as your goal is to click that same area on an application with MouseClick. I'm mentioning this, because even if you can not get the ClassNN, maybe you can get WinGetPos [, X, Y, Width, Height, WinTitle, WinText, ExcludeTitle, ExcludeText]. But if you are really stuck with only screen resolution, at least make sure you are getting A_ScreenWidth, A_ScreenHeight for each computer and then applying a math formula that works on that resolution for the X and Y.

It might be interesting to see how accurate AHKStudent's method would be, across many computers. Personally, I have never taken MouseClick that far, but maybe it can be done. I'm wondering if the formula needs to be tweaked or not, so that it works universally.

[labrint]

I have written a simple code (below). 1440 and 900 is the resolution of my computer. If your resolution is the same, pressing the button press me would press the executor button. But if your resolution is different it will not work, even though the math is supposed to adjust the coordinates.

Code: Select all

#SingleInstance force

Gui, Add, Button, x190 y250 w30 h30, Executor
Gui, Add, Button, x310 y250 w30 h30, PressMe
Gui, Show, x0 y0 w385 h319, Win1
Return

ButtonPressMe:
xHomePC := 206
yHomePC := 289

xCorrect := (1440 / xHomePC)
yCorrect := (900 / yHomePC)

xCurrentPc := floor(A_ScreenWidth / xCorrect)
yCurrentPc := floor(A_ScreenHeight / yCorrect)

;MsgBox, % xCurrentPc ", " yCurrentPc

MouseClick, Left, xCurrentPc, yCurrentPc
Return

ButtonExecutor:
MsgBox, Pressed
Return

If you change the 1440 and 900 to your resolution, it will work. This means that the button coordinates did not change from one PC to another with different resolutions. The problem is that with my other software which is connecting to another program, the coordinates of a button is not the same in some PCs. Why is this? How can I solve it?

[labrint]

I've tried the SysGet, to get monitor size and use it instead of resolution. Didn't work either. The coordinates of the buttons were the same location on both PCs with different resolutions! Then I have some client PCs which the button coordinates do not match.

[labrint]

I ran a code to check the position of the button across two resolutions.

Screen Resolution 1440 by 900 control is 193,276
Screen Resolution 1024 by 768 control is 193,272

Why does Y change but X did not change?

Code: Select all

#SingleInstance force

Gui, Add, Button, x190 y250 w30 h30, Executor
Gui, Add, Button, x310 y250 w30 h30, PressMe
Gui, Show, x0 y0 w385 h319, Win1
Return



ButtonPressMe:
ControlGetPos , X, Y, Width, Height, Button1, A
MsgBox, % X ", " Y ", " Width ", " Height
Return

ButtonExecutor:
Return

[SOTE]

I've tried the SysGet, to get monitor size and use it instead of resolution. Didn't work either. The coordinates of the buttons were the same location on both PCs with different resolutions! Then I have some client PCs which the button coordinates do not match.

I'm a bit confused to exactly what you are doing, because we are lacking important information. What kind of GUIs and buttons are these, that you are not getting control names and shortcut keys won't work on them either?

Usually an application has a window title (for the Windows OS) and control names that can be got from WindowSpy.ahk (usually located at Program Files\AutoHotkey in a regular install). When you have the window title or control names, you can act upon it. Like get the control name of the button, and then do ControlClick or ControlSend.

Even if you can't get the control name of the button, you usually will be able to use keyboard shortcuts or the keyboard to activate the button. Even if this is a non-standard GUI. So you just have to make sure you are acting upon the correct window, which is why I suggested the below type of code (which Loop or Sleep commands can be added to). This has a ControlClick or ControlSend like effect, where you are making sure you are acting on the correct window.

Pseudo Code

Code: Select all

If WinExist("ahk_exe application.exe")
{
	WinActivate, ahk_exe application.exe (or whatever the WinTitle)
	If WinActive("ahk_exe application.exe")
	{
	Send this key
	Send that key
	}
}

You might want to use some variation of WinGet (WinGet, OutputVar [, SubCommand, WinTitle, WinText, ExcludeTitle, ExcludeText] or WinGet, OutputVar, ControlList [, WinTitle, WinText, ExcludeTitle, ExcludeText]), to see if your script can pull some information about the window you are dealing with, that you can then use for automation.

It might be better for you to focus on the window size of the application you are trying to automate, as oppose to the entire screen, then figure out relative coordinates of where the button is located. But if the button is in different places, it might mean that different PCs have a different versions of the software. I still find it surprising that no shortcut keys or keyboard keys won't trigger the button.

[labrint]

SOTE I have used the above methods extensively. But I have a situation where I need to press locations without controls, as well as controls which are unnamed and changing ClassNN changing all the time. It would be very hard to use controls in that situation. Believe me, I have been using them for years. It is simply the wrong direction for this project. I cannot use controls in this example, and I need fixed coordinates that can be changed according to the situation (because I still don't know what is causing the offset.)

[SOTE]

SOTE I have used the above methods extensively. But I have a situation where I need to press locations without controls, as well as controls which are unnamed and changing ClassNN changing all the time. It would be very hard to use controls in that situation. Believe me, I have been using them for years. It is simply the wrong direction for this project. I cannot use controls in this example, and I need fixed coordinates that can be changed according to the situation (because I still don't know what is causing the offset.)

Got it. Wanted to be sure. You might want to check if AHKStudent's math trick (or some other funky math) will work for the size of the window, relative to the location of the button. Can you get the dimensions of the window that needs to be acted upon? And this way, you are more sure about acting upon the correct window. Maybe from there, it's possible to figure out where the button will usually be.

If that doesn't work, then does seem that a math formula that works across the different computers and on screen resolution, will be the last best trick.

[labrint]

Even if I get the control co-ordinates, I have a problem. There is a control with 5 buttons in it. I need to use ControlClick with the control address and the X Y offset to trigger each button. The X Y coordinates vary in these PCs. So even using controls or getting coordinates from controls are not enough.

Tried AHKStudents method, tried monitor size, tried SYSGET (16, 17 SM_CXFULLSCREEN, SM_CYFULLSCREEN: Width and height of the client area for a full-screen window on the primary display monitor, in pixels)... I just can't get it

[SOTE]

Even if I get the control co-ordinates, I have a problem. There is a control with 5 buttons in it. I need to use ControlClick with the control address and the X Y offset to trigger each button. The X Y coordinates vary in these PCs. So even using controls or getting coordinates from controls are not enough.

Tried AHKStudents method, tried monitor size, tried SYSGET (16, 17 SM_CXFULLSCREEN, SM_CYFULLSCREEN: Width and height of the client area for a full-screen window on the primary display monitor, in pixels)... I just can't get it

This problem might be better solved by unconventional methods, which luckily AutoHotkey has some:

ImageSearch (https://autohotkey.com/docs/commands/ImageSearch.htm)
PixelSearch (https://autohotkey.com/docs/commands/PixelSearch.htm)

You might want to study up on 2 particular scripts:

FindText by Feiyue
https://www.autohotkey.com/boards/viewtopic.php?f=6&t=17834

Pixel Predator by Hellbent
https://www.autohotkey.com/boards/viewtopic.php?f=6&t=60949&p=261346

Though the above 2 scripts are a bit elaborate, there have been a number of simpler scripts with similar themes that can be found when doing a search. The main point was finding a group of pixels or image. Though in your case, I learn towards you needing possibly 2 or 3 images, and doing an ImageSearch of a particular area on the screen. You could include the images in your script or convert them into data (which is stored in the actual text of the script itself). However, the advantage of PixelSearch, would be speed. Some of these ideas might help:

Pixel/location storer v1.0
https://autohotkey.com/board/topic/123934-pixellocation-storer-v10/

Pixel search in diffeent coordinates
https://www.autohotkey.com/boards/viewtopic.php?f=5&t=56196

Get nearest black pixel
https://autohotkey.com/board/topic/94114-get-nearest-black-pixel

[Hellbent]

Another, very simple approach is to just get the user to update the actual coords for their screen when they run the script for the first time and then save it to a text file for later use. Also include a possible shortcut to update the positions if they are working on the same computer but different monitor.

Code: Select all

IfNotExist, position.txt
{
	Set_Positions() ; function to set coords and write to a file
}
fileRead,temp,position.txt
positions:=StrSplit(temp,delimiters) ; in this case if you had 1 position, position[1] would be the " X "  position[2] would be the " Y "
blah blah blah, boring stuff.

[labrint]

I am currently approaching this problem by mapping the coordinates of all the controls in the software.

I calculate the distances between these controls and multiply with constants to deduce the coordinates that vary from pc to pc

[labrint]

I have solved it using this method.

Step 1; Get the position of four arbitrary controls in the target window. Preferably situated Top Left, Top Right, Bottom Left, Bottom Right to be able to account for the stretch with different resolutions and screen sizes.

Use WinGet, ActiveControlList, ControlList, WinTitle,
ControlGetText, ControlText, %A_Loopfield%, WinTitle,
and ControlGetPos , X, Y, Width, Height, Control, WinTitle,

Step 2; Get the position of the control you need to click. The position of the control is the Top Left of the control and we want it to click exactly in the middle to be sure.
Step 3; Find the middle X and middle Y of the control by using control click with the X Y offset and trial and error.
Step 4; Subtract the X coordinate the Top Right arbitrary control with the Top Left arbitrary control to get a number which would act as an arbitrary constant.
Step 5; Arbitrary Constant / Middle X of Control = Z. We know the arbitrary constant and middle X of control
Step 6; In the program, you intend to distribute, you can now obtain the 4 arbitrary controls, the constants position and use the predetermined Z to calculate the exact middle position of the control.

I know I did a poor job of explaining, but I tried my best. If someone can explain better, please do so.

This is a good method to use when the ClassNN refers to a group of buttons or a table, where a click needs to be perfectly positioned in order to work.

[jeeswg]

- Here's some code to click the centre of a control.

Code: Select all

q:: ;click centre of control (e.g. Notepad's Edit control)
ControlGet, hCtl, Hwnd,, Edit1, A
WinGetPos, vCtlX, vCtlY, vCtlW, vCtlH, % "ahk_id " hCtl
ControlClick, % Format("X{:i} Y{:i}", vCtlW/2, vCtlH/2), % "ahk_id " hCtl
return

- Acc could be another approach. I.e. inspect the window using AccViewer, and if you can get useful information, write code using Acc functions.
jeeswg's Acc tutorial (Microsoft Active Accessibility) (MSAA) - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=7&t=40590