Andrus Lauringson 

Untested (AI Solution) but...

ControlSetChecked "&Match case", 1, "Find and Replace"
ControlSetChecked "M&atch whole word", 1, "Find and Replace"
ControlSetChecked "&Target", 1, "Find and Replace"

In AutoHotkey v2.0, ControlSetChecked expects the control identifier first, then the checked state value, then the window title.  By putting 1 first and the control name second, AutoHotkey is interpreting the control name as a non-numeric checked value, which causes it to toggle instead of explicitly setting the state.

Thanks, but according to Autohotkey 2.0 documentation, the command syntax is:
ControlSetChecked NewSetting, Control , WinTitle

Changing the order results in an error message.

Andrus Lauringson 

Just goes to show AI isn't right for everything!!  Maybe something in this will be helpful?

Given that your syntax is correct, the issue is likely that ControlSetChecked with value 1 is somehow toggling rather than explicitly setting the checkbox state. This could happen if:

1. The control isn't being properly identified - The "&Match case" text might not be consistently recognized
2. Trados Studio has custom checkbox behavior - Some applications implement non-standard checkbox controls

Here are better solutions:

Solution 1: Check the current state first

WinActivate "Trados Studio - "
WinWaitActive "Trados Studio - ", , 4
Send("^f")
WinWaitActive "Find and Replace", , 4

; Only check if currently unchecked
if !ControlGetChecked("&Match case", "Find and Replace")
    ControlSetChecked(1, "&Match case", "Find and Replace")

if !ControlGetChecked("M&atch whole word", "Find and Replace")
    ControlSetChecked(1, "M&atch whole word", "Find and Replace")

if !ControlGetChecked("&Target", "Find and Replace")
    ControlSetChecked(1, "&Target", "Find and Replace")

Solution 2: Use ClassNN identifiers instead Use Window Spy to get the actual ClassNN of each checkbox (like Button1, Button2, etc.):

ControlSetChecked 1, "Button1", "Find and Replace"  ; Replace with actual ClassNN
ControlSetChecked 1, "Button2", "Find and Replace"
ControlSetChecked 1, "Button3", "Find and Replace"

Solution 3: Force uncheck then check

; Force uncheck first
ControlSetChecked 0, "&Match case", "Find and Replace"
ControlSetChecked 0, "M&atch whole word", "Find and Replace"
ControlSetChecked 0, "&Target", "Find and Replace"
Sleep(50)
; Then check
ControlSetChecked 1, "&Match case", "Find and Replace"
ControlSetChecked 1, "M&atch whole word", "Find and Replace"
ControlSetChecked 1, "&Target", "Find and Replace"

The most reliable approach is probably Solution 1 or getting the proper ClassNN identifiers with Window Spy for Solution 2.

None of these solutions worked, it's still a toggle.
With solution 3, due to Sleep(50) it was visible how on first use, the script added the checkmarks, and on the second use removed them.

 Andrus Lauringson 

ok - I played with this a bit this morning.  The problems you have are these:

• Chrome-Rendered UI: Trados Studio's Find and Replace dialog uses Chrome/Chromium rendering (Chrome_RenderWidgetHostHWND) rather than standard Windows controls.c This means AutoHotkey's standard control commands like ControlSetChecked cannot access or manipulate the checkboxes - they're rendered inside a web-like container that AutoHotkey sees as a single opaque element.
• Persistent State Issue: Even if the controls were accessible, Trados Studio remembers checkbox states between uses. The original assumption was that ControlSetChecked 1 would set a checkbox to "checked", but in practice it was toggling the state. First run would check them, second run would uncheck them.

So after playing around a bit I think the most reliable solution for you is to use tab navigation because it simulates actual keyboard input that the Chrome-rendered interface can interpret.  And using a Double Space technique ({Space}{Space}) ensures checkboxes always end up checked regardless of their initial state:

• First space: Unchecks if currently checked (or checks if unchecked)
• Second space: Always checks (since after first space it's definitely unchecked)

This approach bypasses both problems because it doesn't need direct control access, and it handles the persistent state issue by ensuring a consistent end state rather than toggling.

The script that seems to work for me is this:

;------------------------------------------------------------------------------
; Set up find & replace with a couple of preset options
;------------------------------------------------------------------------------

WinActivate "Trados Studio - "
WinWaitActive "Trados Studio - ", , 4
Send("^f")
WinWaitActive "Find and Replace", , 4
Sleep(200)

; Navigate to Match case - uncheck then check
Send("{Tab 4}")
Send("{Space}{Space}")  ; Two spaces: first unchecks (if checked), second checks

; Navigate to Match whole word - uncheck then check
Send("{Tab}")
Send("{Space}{Space}")  ; Two spaces: first unchecks (if checked), second checks

 Andrus Lauringson 

ok - I played with this a bit this morning.  The problems you have are these:

• Chrome-Rendered UI: Trados Studio's Find and Replace dialog uses Chrome/Chromium rendering (Chrome_RenderWidgetHostHWND) rather than standard Windows controls.c This means AutoHotkey's standard control commands like ControlSetChecked cannot access or manipulate the checkboxes - they're rendered inside a web-like container that AutoHotkey sees as a single opaque element.
• Persistent State Issue: Even if the controls were accessible, Trados Studio remembers checkbox states between uses. The original assumption was that ControlSetChecked 1 would set a checkbox to "checked", but in practice it was toggling the state. First run would check them, second run would uncheck them.

So after playing around a bit I think the most reliable solution for you is to use tab navigation because it simulates actual keyboard input that the Chrome-rendered interface can interpret.  And using a Double Space technique ({Space}{Space}) ensures checkboxes always end up checked regardless of their initial state:

• First space: Unchecks if currently checked (or checks if unchecked)
• Second space: Always checks (since after first space it's definitely unchecked)

This approach bypasses both problems because it doesn't need direct control access, and it handles the persistent state issue by ensuring a consistent end state rather than toggling.

The script that seems to work for me is this:

;------------------------------------------------------------------------------
; Set up find & replace with a couple of preset options
;------------------------------------------------------------------------------

WinActivate "Trados Studio - "
WinWaitActive "Trados Studio - ", , 4
Send("^f")
WinWaitActive "Find and Replace", , 4
Sleep(200)

; Navigate to Match case - uncheck then check
Send("{Tab 4}")
Send("{Space}{Space}")  ; Two spaces: first unchecks (if checked), second checks

; Navigate to Match whole word - uncheck then check
Send("{Tab}")
Send("{Space}{Space}")  ; Two spaces: first unchecks (if checked), second checks

Andrus Lauringson 

I would add that this won't help when you run the script prior to having set the options.  In essence there is little point in having this at all since all it's doing is exactly what Studio does in the first place!!  You might be able to do it by using pixel colour detection inside the box at the coordinates on your machine... or something like that.  But we're getting into the realm of effort to create the solution vs effort without it, and it may not be worth it.

The problem you have here is that pure AutoHotkey cannot reliably ensure these checkboxes are always checked in a Chrome-rendered interface where state persists between sessions.

Of course Jesús Prieto is a good person to look at this as he has a lot more experience with AHK in Studio and might have a solution to your problem.

 Andrus Lauringson 

I was quite intrigued by this exercise so I used AI to create a script that could capture everything AHK could pick up under a mouse position and copy it to my clipboard.  Then tested a checked box and a non-checked box to see if anything there could be accessible.

Checked:

========== WINDOW SPY CAPTURE ==========
Capture Time: 20250807105616

--- MOUSE POSITION ---
Screen: X: 25 Y: 178

--- WINDOW INFORMATION ---
Title: Find and Replace
Class: WindowsForms10.Window.8.app.0.ea119_r8_ad1
Process: SDLTradosStudio.exe
PID: 15872
ID: 266550

Window Position: X: 1043 Y: 131
Window Size: W: 283 H: 371

--- CONTROL UNDER MOUSE ---
ClassNN: 7475458
Text: &Match case
Control Pos (relative): X: 21 Y: 169
Control Size: W: 82 H: 17
Enabled: Yes
Visible: Yes
Checked: No
Style: 0x5601000B

--- PIXEL INFORMATION ---
Color at cursor: 0xFFFFFF (Hex: 0xFFFFFF)

--- ALL CONTROLS IN WINDOW ---
Total Controls: 23
1: WindowsForms10.SysTabControl32.app.0.ea119_r8_ad11
2: WindowsForms10.Window.8.app.0.ea119_r8_ad11 - Text: Find
3: WindowsForms10.Window.8.app.0.ea119_r8_ad12
4: WindowsForms10.Window.8.app.0.ea119_r8_ad13
5: WindowsForms10.STATIC.app.0.ea119_r8_ad11 - Text: &Find what:
6: WindowsForms10.Window.8.app.0.ea119_r8_ad14 - Text: Find &options
7: WindowsForms10.Window.8.app.0.ea119_r8_ad15
8: WindowsForms10.Window.8.app.0.ea119_r8_ad16
9: WindowsForms10.BUTTON.app.0.ea119_r8_ad11 - Text: &Match case
10: WindowsForms10.BUTTON.app.0.ea119_r8_ad12 - Text: M&atch whole word
11: WindowsForms10.COMBOBOX.app.0.ea119_r8_ad11 - Text: Wildcards
12: WindowsForms10.BUTTON.app.0.ea119_r8_ad13 - Text: &Use:
13: WindowsForms10.BUTTON.app.0.ea119_r8_ad14 - Text: Search u&p
14: WindowsForms10.COMBOBOX.app.0.ea119_r8_ad12 - Text: driven
15: Edit1 - Text: driven
16: WindowsForms10.STATIC.app.0.ea119_r8_ad12 - Text: &Look in:
17: WindowsForms10.COMBOBOX.app.0.ea119_r8_ad13 - Text: Current Document
18: WindowsForms10.Window.8.app.0.ea119_r8_ad17
19: WindowsForms10.BUTTON.app.0.ea119_r8_ad15 - Text: &Source
20: WindowsForms10.BUTTON.app.0.ea119_r8_ad16 - Text: &Target
... and 3 more controls

--- WINDOW TEXT (first 500 chars) ---
Find
&Find what:
Find &options
&Match case
M&atch whole word
Wildcards
&Use:
Search u&p
driven
driven
&Look in:
Current Document
&Source
&Target
Find &Next
&Close
&Help


--- SPECIAL DETECTIONS ---
⚠ .NET Windows Forms detected
⚠ Unusual numeric ClassNN detected - control may not be properly accessible

Unchecked:

========== WINDOW SPY CAPTURE ==========
Capture Time: 20250807105543

--- MOUSE POSITION ---
Screen: X: 25 Y: 174

--- WINDOW INFORMATION ---
Title: Find and Replace
Class: WindowsForms10.Window.8.app.0.ea119_r8_ad1
Process: SDLTradosStudio.exe
PID: 15872
ID: 266550

Window Position: X: 1043 Y: 131
Window Size: W: 283 H: 371

--- CONTROL UNDER MOUSE ---
ClassNN: 7475458
Text: &Match case
Control Pos (relative): X: 21 Y: 169
Control Size: W: 82 H: 17
Enabled: Yes
Visible: Yes
Checked: No
Style: 0x5601000B

--- PIXEL INFORMATION ---
Color at cursor: 0xFFFFFF (Hex: 0xFFFFFF)

--- ALL CONTROLS IN WINDOW ---
Total Controls: 23
1: WindowsForms10.SysTabControl32.app.0.ea119_r8_ad11
2: WindowsForms10.Window.8.app.0.ea119_r8_ad11 - Text: Find
3: WindowsForms10.Window.8.app.0.ea119_r8_ad12
4: WindowsForms10.Window.8.app.0.ea119_r8_ad13
5: WindowsForms10.STATIC.app.0.ea119_r8_ad11 - Text: &Find what:
6: WindowsForms10.Window.8.app.0.ea119_r8_ad14 - Text: Find &options
7: WindowsForms10.Window.8.app.0.ea119_r8_ad15
8: WindowsForms10.Window.8.app.0.ea119_r8_ad16
9: WindowsForms10.BUTTON.app.0.ea119_r8_ad11 - Text: &Match case
10: WindowsForms10.BUTTON.app.0.ea119_r8_ad12 - Text: M&atch whole word
11: WindowsForms10.COMBOBOX.app.0.ea119_r8_ad11 - Text: Wildcards
12: WindowsForms10.BUTTON.app.0.ea119_r8_ad13 - Text: &Use:
13: WindowsForms10.BUTTON.app.0.ea119_r8_ad14 - Text: Search u&p
14: WindowsForms10.COMBOBOX.app.0.ea119_r8_ad12 - Text: driven
15: Edit1 - Text: driven
16: WindowsForms10.STATIC.app.0.ea119_r8_ad12 - Text: &Look in:
17: WindowsForms10.COMBOBOX.app.0.ea119_r8_ad13 - Text: Current Document
18: WindowsForms10.Window.8.app.0.ea119_r8_ad17
19: WindowsForms10.BUTTON.app.0.ea119_r8_ad15 - Text: &Source
20: WindowsForms10.BUTTON.app.0.ea119_r8_ad16 - Text: &Target
... and 3 more controls

--- WINDOW TEXT (first 500 chars) ---
Find
&Find what:
Find &options
&Match case
M&atch whole word
Wildcards
&Use:
Search u&p
driven
driven
&Look in:
Current Document
&Source
&Target
Find &Next
&Close
&Help


--- SPECIAL DETECTIONS ---
⚠ .NET Windows Forms detected
⚠ Unusual numeric ClassNN detected - control may not be properly accessible

Analysed the differences with AI:

The Control State Isn't Being Read Properly

Even though you can see the checkbox is checked visually, AutoHotkey's ControlGetChecked is returning "No" (unchecked). This explains everything:

1. Why ControlSetChecked appears to toggle: It's not actually reading the current state correctly, so it can't make intelligent decisions about whether to check or uncheck
2. Why the mysterious ClassNN 7475458: There might be a rendering layer or wrapper control that's intercepting the actual checkbox state
3. Why Tab+Space works but control commands don't: The keyboard input goes through the proper UI layer, but the control commands are trying to interact with a control that isn't properly exposing its state

This is a classic symptom of:

• Custom-drawn controls that don't properly implement Windows accessibility APIs
• Overlay/wrapper controls that visually show checkboxes but don't expose standard checkbox properties
• .NET Windows Forms controls that have custom rendering

Bottom line: The checkbox control exists (WindowsForms10.BUTTON.app.0.ea119_r8_ad11) but it's not properly reporting its checked state to AutoHotkey. This makes it impossible to reliably use ControlGetChecked or ControlSetChecked - which is why the Tab navigation solution ended up being necessary.

Thank you for looking into this and for explaining the root cause, much appreciated!

I reached to a bit similar conclusion deep into the night after trying all kinds of suggestions from AI.

But I noticed that although the state of the checkboxes is not available, the state of the button "Regular expressions" is.

So if the button "Regular expressions" is inactive, the script marks checkbox "Use", enters the search word into textbox and applies "Match case" and "Match whole words" functionality through regex search while ignoring the state of those checkboxes altogether (or just enters the regex search if the regex button is active):

word := "misSpelledWord"
ControlSetText("(?-i)\b" . word . "\b", "Edit1", "Find and Replace")
ControlGetEnabled("WindowsForms10.COMBOBOX.app.0.ea119_r9_ad11", "Find and Replace") || Send("!u")
Send("!n")

I needed that functionality because it is a part of a larger script which takes a word from a spellchecker's list and finds it in Trados.
An exercise and a nightmare, now works like a charm though.

 Andrus Lauringson 

Some comments about your script:

1. Be careful with the ClassNN name, as it may vary… In fact, in order to work for me, I needed to change it from:

WindowsForms10.COMBOBOX.app.0.ea119_r9_ad11

to:

WindowsForms10.COMBOBOX.app.0.ea119_r8_ad11

Highlighted in bold the difference.

I saw this behaviour years ago, and back then, I thought that this name could change not only after installing an update of Trados Studio, but even after restarting the application.

I’ve seen it in the past, and I believe it worked for you and Paul, but I promise it didn’t for me (both in Trados Studio 2024 SR1 - 18.1.2.6370 and in Trados Studio 2022 SR2 - 17.2.12.19268), so the script may stop working some day.

_________________

2. Instead of the line:

Send("!n")

you can use UIA to click on that specific button. I haven’t tested this particular button, but UAI worked with other buttons in Trados Studio, so I bet it works here as well. You can download the UAI v2 library from here (note that this version is needed for AutoHotkey v2): https://github.com/Descolada/UIA-v2/blob/main/Lib/UIA.ahk 

_________________

3. Just in case you asked, I think UIA won’t help to get the state of the check boxes either.

1. Thank you, good suggestion. I thought using ClassNN would make it more robust, but that would make it more version independent and intuitive. 
2. Are there any advantages to using UAI? I'm afraid it would make things more complicated and possibly slower because the library seems to be over 7000 lines of code.
3. It's fine, the script does exactly what's needed.

Andrus Lauringson 

In this case I don’t think there are big advantages.

In general, UIA is more resilient. For example, you can press a button in the ribbon both with UIA and the Send command, but if you add buttons to the ribbon, the Send command will stop working until you chage the code. Another example: with UIA you can get the text of the target segment (only in Trados Studio 2024) without using the Clipboard, which is slow and quite unreliable.

Getting the target segment text more reliably sounds very interesting, and I am trying to make sense of the UIA code.
Is it possible with UIA to copy ALL the target segments to clipboard at once?

I am currently using the following hotkey with "Sleep" in my script, but it's not perfect: if the text is very long, the delay might not be enough.
But if the text is very short, then the wait may be too long:

F12::
{
A_Clipboard := ""
Sleep 100
Send("^{Home}")
Send("{Down}")
Send("!{Space}+^{End}")
Sleep 500
Send("^c")
Sleep 100
Send ("{Right}")
}

(sending the right arrow key at the end is just to deselect the segments)

Andrus Lauringson 

Andrus Lauringson said:

Is it possible with UIA to copy ALL the target segments to clipboard at once?

I don't know, never tried. I’ve been successful with UIA here:

• Getting the text in segment target (only Trados Studio 2024).
• Getting the text of the control under the mouse.
• Clicking on buttons and check boxes (Trados Studio, web browers).