Can anyone fix it?
Code: Select all
winactivate, ahk_exe application.exe
winwaitactive, ahk_exe application.exe
MouseClick, left, 42, 214
Code: Select all
winactivate, ahk_exe application.exe
winwaitactive, ahk_exe application.exe
MouseClick, left, 42, 214
Code: Select all
f1::
winactivate, ahk_exe notepad.exe
winwaitactive, ahk_exe notepad.exe
MouseClick,, 42, 214
return
Test like thislabrint wrote: ↑14 Feb 2019, 08:04I 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
Code: Select all
xp := floor(A_ScreenWidth // 34)
yp := floor(A_ScreenHeight // 4.1)
msgbox, % xp "|" yp
ExitApp
Code: Select all
If WinExist("ahk_exe application.exe") AND WinActive("ahk_exe application.exe")
{
Send this key
Send that key
}
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.AHKStudent wrote: ↑14 Feb 2019, 15:59You 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
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
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
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?
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
}
}
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.labrint wrote: ↑15 Feb 2019, 04:22SOTE 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.)
This problem might be better solved by unconventional methods, which luckily AutoHotkey has some:labrint wrote: ↑15 Feb 2019, 04:43Even 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
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.
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
Users browsing this forum: Google [Bot] and 193 guests