ControlClick weird program-specific behavior Topic is solved

Get help with using AutoHotkey (v2 or newer) and its commands and hotkeys
Cyrano
Posts: 12
Joined: 29 Mar 2023, 17:03

ControlClick weird program-specific behavior

Post by Cyrano » 31 Mar 2023, 10:35

I'm running a program under Windows 10 whose UI makes use of sliders. In normal use of this program (i.e., without AHK), the user sees these behaviors:

(a) These sliders can be adjusted using keystrokes, but only after a single slider has been selected by a mouse click.

(b) After a slider has been clicked on, a message box appears identifying the selected slider and the keystrokes which can be used to adjust its numerical value.

(c) After each keystroke used to adjust the slider, a message box displays the new numerical value of the slider.

(d) After each keystroke, the slider thumb moves, and the results expected from changing the slider occur.

I'm attempting to use AHK to enable selecting a slider using the keyboard, rather than by using the mouse -- after which the normal keystrokes for slider adjustment will be active.

I'm using a script like this:

Code: Select all

b::
{
 ControlClick  "control B", "window title"
	return
}
When this script is run, the program shows behaviors (b) and (c), but not (d). The slider thumb does not move, nor do the expected results occur.

While this script is running, using the mouse to select a slider results in normal (d) behavior.

FWIW, this script code works OK in another program which has similar expected behaviors (a), (b), and (c).

I've tried adding delays, but no joy.

Cyrano
Posts: 12
Joined: 29 Mar 2023, 17:03

Re: ControlClick weird program-specific behavior

Post by Cyrano » 31 Mar 2023, 16:12

I believe I've found root cause here, but I haven't found a way to mitigate it.

As I want the code to be insensitive to varying screen dimensions and layouts, I'm using Mode 2 (Control). I've learned that ClassNN is not a robust method to identify controls (because the ClassNN value of a given control is not fixed over time and use conditions), so I'm using WinText.

Unfortunately, the program I'm trying to automate does not have unique text associated with each control. In some cases, multiple controls have exactly the same text assigned to them. This was not obvious to me, as I saw no such duplicated text in the program's UI. Using Windows Spy, I discovered that the program has many hidden controls, some of which share the same text.

With ClassNN and text eliminated, the only remaining method in Mode 2 to specify a control is HWND -- but I've found no automatable way to determine the HWND associated with a visible control other than by using its text. :cry:

Any suggestions for a workaround will be appreciated.

swagfag
Posts: 6222
Joined: 11 Jan 2017, 17:59

Re: ControlClick weird program-specific behavior  Topic is solved

Post by swagfag » 31 Mar 2023, 22:16

any suggestions for workarounds would be specific to that particular application, an application which is unknown to the reader. in the end it might turn out ControlClick is not the correct function to use to achieve whatever ure trying to achieve

Post Reply

Return to “Ask for Help (v2)”