Window-Relative Auto Clicking on Windows

On this page

Pick, bind and test a window with three clicks

This test uses Free Auto Clicker 8.1.0 and the mouse-button test pad in a normal browser window. Keep only one browser window with that exact page title open. Arrange the browser and clicker so the chosen part of the pad remains uncovered, including when the clicker is in front.

1. Start clean. Click the pad once manually, check its Left counter, then select Reset. In Free Auto Clicker, use Profiles → Save for a setup you want to keep, then New. Leave pixel conditions, timing variance and after-click keyboard actions off for this first test.
2. Set a short single-point run. In Quick setup, use Hours = 0, Minutes = 0, Seconds = 1, Milliseconds = 0, Mouse button = Left and Click type = Single. Select Repeat this many times and enter 3. Use Start delay (seconds) = 0; if enabled, set maximum clicks to 3 and maximum runtime to 1 minute.
3. Pick while still using screen coordinates. Choose Fixed point → Pick position. The default F7 shortcut also opens the picker. Move to the middle of the uncovered test pad, then press Space to confirm. Esc cancels. Do not move the browser after picking.
4. Bind the window at that saved point. Open Smart automation. Under the Window-aware target controls, choose Window-relative, then select Bind at selected point. The saved screen position must still lie over the browser, not over the clicker or another window.
5. Check the captured target. Read Bound window: it should show the browser's process and the exact test-page window title. The field is read-only. If the wrong window was captured, stop and return to screen coordinates, arrange the windows again, then repeat the pick and bind steps.
6. Run the first three clicks. Check the summary and the Start/stop shortcut in Global hotkeys. Bring the browser to the foreground and use that shortcut, F6 by default. Leave the pointer alone. The pad's Left counter should go from 0 to 3. Use F8 if a click lands elsewhere.

Now stop, move and repeat. Once the run ends, move the browser window to a different desktop position without resizing, scrolling, changing zoom or changing tabs. Select Reset on the same pad and run again with the same bound point. Expect Left = 3 again, at the new window position.

Move the window between runs, not while input is being sent. If either test fails, use the matching checks below. For basic controls, first complete the five-click setup guide.

Screen coordinates and client coordinates

For example, a client-area origin at screen (400, 200) and a point at screen (520, 280) produce relative coordinates (120, 80). If the origin later moves to (700, 300), the same relative point maps to screen (820, 380). This works only while the intended control remains at that offset inside the window.

The client area excludes the window's outer frame; it is not necessarily the same as a web page's content area. Browser toolbars or other controls can also be inside that client area. Binding does not inspect HTML elements or search for a button by its label.

Add or recapture a point after binding

With the intended window bound, open the picker, move to a point inside its client area and press Space. The app converts the captured screen position to the bound window's coordinate system. A point outside that area is rejected; capture inside the intended target instead of copying unrelated desktop coordinates.

To return to desktop positions, keep the bound window available and select Use screen coordinates. This converts stored positions back using the current window geometry. Do not merely copy relative X/Y numbers into an unbound profile and expect the same target.

Use one bound window for a sequence

Build and check a short sequence using the multi-point guide. In screen-coordinate mode, select a row whose point is inside the intended window, then bind at that selected point. All stored sequence points, and any stored fixed point, must fit inside the same target's client area for conversion. Even an unused point outside the window can prevent binding.

Rows retain their own Delay ms, Repeat and enabled state. The profile's Mouse button, Click type and Mouse action apply across the sequence; rows do not have separate button overrides.

For one pass, enable only the intended rows, set each row's Repeat to 1, enable Repeat the entire sequence and then select Repeat this many times = 1. Check the summary and make sure the independent click/runtime limits allow that small pass. Do not assume a repeat limit of 1 always means one complete sequence.

A pixel condition checks a separate visible state

After the movement test works, an optional Wait for a pixel condition before each action can wait for a selected color condition. In window-relative mode the pixel also uses the bound coordinate reference. Configure a timeout and test a stable pixel; an animation, hover effect or theme change can alter its color.

Keep the condition off while diagnosing a basic binding problem. It does not identify a control, verify that a task succeeded or provide hidden-window input. Read the pixel-color condition guide before adding it.

Check what changed when a bound point fails

The window moves

Stop between tests, move the same window without changing its contents and repeat the three-click check. If the point stays at the old desktop location, confirm that Target mode still says Window-relative and Bound window shows the intended target.

The window resizes or its contents scroll

A relative offset follows the window, not a responsive layout. Resizing or scrolling can move the button inside it. Restore the layout or capture a new point, then test again.

Display scale, zoom or monitor layout changes

Recheck the target after a scale, zoom, resolution or monitor change. Do not assume a point tested on one display still reaches the same control after it is rendered differently.

The title changes, or more than one window matches

Window matching uses the captured process name and exact title. Changing a document name or browser tab may change the title. Inspect the target, use screen coordinates while the previous bound window is available, then pick and bind the intended window again.

If several windows have the same process and exact title, the target is ambiguous and the action is stopped. Close the duplicate test window or otherwise make the intended title unique, then retest. If the old target is gone and coordinate conversion cannot complete, preserve its profile and start a new profile for the new target.

The target runs as administrator

Windows may block input from a lower-integrity process into an elevated target. First check whether the target can run normally. Use the troubleshooting guide for a required permission mismatch and test a small run afterward. A binding match does not guarantee that the target accepts automated input.

Binding still uses the foreground and the real pointer

The app resolves the target and attempts to activate it before window-relative input. If the matching window is minimized, it may try to restore it first. If activation fails, input is stopped. This cannot keep the target hidden while clicking it; the background-clicking explanation compares that with hiding the clicker's own controls.

Binding is available with Fixed point or Point sequence. Follow pointer requires screen coordinates and disables target binding. Use the mouse clicker task selector if you are deciding which mode fits the job.

Before reusing a bound profile

• Check the displayed process/title and keep only one exact matching target.
• Keep the target available for foreground activation and leave the pointer alone during the run.
• Recheck points after layout, zoom or display changes.
• Use a finite repeat limit, review enabled rows and keep F8 available.
• Use Save for the tested local profile, or Export for a .fac file; revalidate after Import or a move to another PC.

Download Free Auto Clicker for Windows

Frequently asked questions

Does window-relative clicking work when the app is minimized?

The clicker does not send input while the target stays minimized. For a matching bound window, it can try to restore and activate the target before clicking. If Windows does not allow activation, the run stops. Keep the target visible for predictable testing; this is not hidden-window input.

Will it survive an application redesign?

Not automatically. Window-relative coordinates track an offset inside the window, not the identity of a button. Scrolling, resizing, changing zoom or display scale, or rearranging the interface can move a control away from that offset. Pick and test the point again after those changes.

Why use exact target matching?

Free Auto Clicker resolves the captured process name and exact window title before window-relative input. A missing match or more than one matching window stops the action. If the title changes, inspect the intended target and bind it again rather than assuming the previous point still identifies it.

Can I combine relative points with pixel conditions?

Yes. Window binding establishes the target and client-coordinate reference. A pixel condition checks a selected visible pixel before each action and can wait until its condition matches or the timeout is reached. It does not recognize controls or enable clicking inside a hidden window.

Do I type the process name and window title into Bound window?

No. Bound window is read-only. First pick a point inside the target while using screen coordinates. Then choose Window-relative in Smart automation and select Bind at selected point. Check that the displayed process and title belong to the intended window.

Can I combine window-relative mode with Follow pointer?

No. Follow pointer uses screen coordinates and disables target binding. Use Fixed point or Point sequence for a bound window. To return to screen coordinates, keep the bound target available and use Use screen coordinates; the app converts the stored positions back.