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 

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 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.