Skip to content
All posts

Detection6 min read

How TradeClip detects a trade on your screen

TradeClip reads the pixels of one chart window to notice entries and exits. Here is what that needs, how it avoids false positives, and what it never does.

By TradeClip Team · Published

Cover card with the TradeClip mark and the title: How TradeClip detects a trade on your screen
On this page
  1. One window, read as pixels
  2. What it needs from you
  3. Telling a trade apart from everything that looks like one
  4. Two recording modes behind one detector
  5. Facts it saw, and only those
  6. What TradeClip never does
  7. Seeing it for yourself

TradeClip records each trade you take without a record button. People reasonably ask how that works, and the honest answer is more interesting than "it is automatic": the app looks at one window on your screen and reads what the chart is showing. Nothing else. This post explains what that involves, what it needs from you, where it can be wrong, and the list of things it deliberately does not do.

One window, read as pixels#

When you set TradeClip up, you pick a source. The app lists the windows it can capture and puts the ones it recognises as TradingView or WealthCharts first, because those are the charts it knows how to read. Once you choose one, a small native helper called TradeClip Capture streams that window through the operating system's screen capture API. The helper is the only part of the app that ever touches video frames; the rest of TradeClip receives short text messages such as "a position was read" or "a fragment was written".

Detection runs on those frames. The helper looks for the platform's active-position label, the small readout that appears on the chart when you are in a trade, and reads it with on-device text recognition together with a pixel and layout check of the surrounding area. From that label TradeClip extracts the facts it can actually see: the symbol, whether the position is long or short, the size, and the profit or loss as it is displayed on the chart.

The two platforms draw that label differently, so the helper has a reader for each. TradingView's is a filled chip. WealthCharts draws an outlined box on a dashed line, and its label does not say whether you are long or short, so there the helper also reads the Limit and Stop bracket labels. They start with Buy or Sell, and because a bracket closes the trade, a Sell bracket means you are long and a Buy bracket means you are short. The same rows give the target and the stop. With no bracket on the chart, the side is shown as unknown rather than guessed.

That is the whole input. There is no broker connection, no TradingView API, no DOM injection and no browser extension. If the chart does not show it, TradeClip does not know it.

What it needs from you#

Because detection is visual, TradeClip's needs are the needs of a screen recorder.

  • A Screen Recording grant. On macOS the helper appears in System Settings under Privacy and Security as "TradeClip Capture". macOS applies a new grant only to a process started after it, so quit and reopen the app once after you enable it. The diagnostics panel shows whether frames are arriving.
  • The chart window itself. TradeClip captures a window, not a region of the desktop. TradingView, in its desktop app or in a browser window, and WealthCharts are the two platforms the detector is tuned for. WealthCharts runs in a browser, an installed browser app or the iPad app on an Apple-silicon Mac; when the chart lives in a browser, you pick that browser window and keep the chart tab in front.
  • The position label in view. TradingView keeps that label hard against the right edge of the chart, and WealthCharts draws its box on the position's dashed line. If you choose a Mobile 9:16 capture region for clips, the recording stream itself is still the whole window, precisely so the label stays readable; the region is applied later, when a clip is rendered.

Nothing here requires an account with your broker, a login to TradingView, or any change to how you place orders.

Telling a trade apart from everything that looks like one#

A chart is full of things that resemble a position: the Buy and Sell quote buttons, resting stop, limit and target orders, the stop row attached to a position, the Long Position and Short Position drawing tools, and the toasts that appear when an order fills. The detector keeps an explicit rejection table for each of these. When a candidate reading is thrown out, the reason is recorded, and you can see it in the diagnostics panel next to the text that was read and where on the frame it came from.

Text recognition on a small, low-contrast label is also not perfect. It does not read the label on every scan, and it occasionally misreads a digit. So the readings are not trusted one at a time. A debounced state machine sits on top of them and only reports an event once the evidence is stable: entry, adding to a position, a partial exit, a sign-flip reversal, and a confirmed close.

The close is the case that needed the most care. Early on, a run of missed reads on an unchanged position could look like the position had gone flat, and the app would finalize a clip mid-trade. TradeClip now holds the first flat reading for twelve seconds. If the position is read again inside that window the flat is discarded and the session continues; if it stays flat, the close is confirmed and dated to the moment flat was first seen, so the exit marker and the post-roll do not drift with the hold. There is also a Finish button on the floating overlay for the case the detector never reports as closed.

Two recording modes behind one detector#

Detection decides when something happened. What gets kept on disk is a separate choice.

In the default on-trade mode, the helper analyses frames continuously but only starts writing video once an entry is confirmed, and stops after a short post-roll following the confirmed close. Nothing is written while you are flat.

In the optional rolling mode, the helper keeps a short ring buffer on disk while capture is running. When an entry is detected, the clip can start before the entry, so the setup is part of the recording. Both modes write an atomic per-trade manifest, which is what lets an interrupted recording be recovered after a crash or a forced quit.

When a trade ends, its fragments and any camera recording are moved into their own folder under ~/Movies/TradeClip/Clips/. The automatic save keeps every retained second at real speed; the market moved at the pace it moved, and the record of the trade should too.

Facts it saw, and only those#

TradeClip has one rule for the numbers it shows you: never report a value it did not observe. The profit-and-loss timeline in a clip is built from the readings the detector actually made, stamped in source time. A caption variable such as {upnl} shows the last value read at or before that instant and holds it; it never interpolates between readings, and an unobserved fact renders as an em dash rather than a plausible number.

This matters for trust, and it also shapes what the app can and cannot do. TradeClip cannot tell you your fill price if the chart never showed one, and it will not guess. When the detector's reading was uncertain, the clip carries that uncertainty rather than hiding it.

What TradeClip never does#

It is worth saying plainly, because "automatic" can sound like "connected".

  • It never connects to your broker, and it never asks for broker credentials.
  • It never places, modifies or closes an order. The helper's contract forbids it, and there is no code path for it.
  • It never reads anything outside the window you chose.
  • It never uploads a live recording. Recording stays on this computer; clips are uploaded only if you enable cloud sync or cloud rendering. Rendering sends finished-trade segments and edit instructions for temporary processing.
  • It never sends what it read from the chart to our servers as part of counting your clips. Clip-count records hold an opaque clip identifier and a capture time, nothing more.

Seeing it for yourself#

Open the diagnostics panel while capture is running. It shows the permission state, the helper's identity, the capture frame rate and the age of the last frame, every text observation with its bounding box, each candidate's rejection reason, the debounce counters and the buffer state. "Save diagnostic frame" writes the current frame to disk so you can look at exactly what the detector saw. When something does not behave as you expect, that frame is usually the fastest way to understand why.