scsf_ function

What it is

An scsf_ function is the C++ entry point of a Sierra Chart custom study. Every study you write in ACSIL declares one (or more) functions whose name starts with the scsf_ prefix — for example, scsf_TradeManager or scsf_VolumeProfile. Sierra Chart's loader scans every DLL it loads, finds all exported symbols matching this naming convention, and exposes each one as a selectable study in the platform's UI.

The signature of every scsf_ function is the same: it takes a single argument, a reference to an SCStudyInterfaceRef object — conventionally named sc — through which the study reads bar data, configures itself, and writes outputs. The function returns void. There are no other valid entry-point shapes.

Conceptually, an scsf_ function plays two roles. On its very first invocation (when sc.SetDefaults is true), it acts as the study's configuration block — it declares the display name, the subgraphs it will plot, the inputs the user can edit, and various behavioral flags. On every subsequent invocation, it acts as the study's runtime body — it consumes bar data and produces outputs.

Why it matters

The scsf_ prefix is what makes a study discoverable. If you compile a DLL with a function named MyStudy instead of scsf_MyStudy, Sierra Chart will load the DLL successfully but the study will not appear in Analysis → Studies → Add Custom Study. The convention is enforced by the loader, not by the compiler — there is no warning at build time if you get it wrong.

The function name (minus the prefix) is the default identifier the platform uses to reference the study internally — in chartbooks, in study collections, in cross-study references. Renaming an scsf_ function in production is a breaking change for any chartbook that already references it.

How it's used in ACSIL code

A single .cpp file can host multiple scsf_ functions — one per study. They all share the same SCDLLName (the DLL identity) but each appears as its own selectable study. This is how a single DLL can ship a family of related studies — for example, an order-flow toolkit might expose scsf_DeltaCandles, scsf_FootprintGrid, and scsf_CVD from the same DLL.

Inside an scsf_ function, the standard flow is: check sc.SetDefaults; if true, write the configuration block and return; if false, fall through to the runtime body that reads sc.Close[], sc.Volume[], etc., and writes to sc.Subgraph[i][bar].

Common patterns / pitfalls

• One function per study — do not try to share an scsf_ function across multiple studies. Each study needs its own function.
• SetDefaults must return early — once the configuration is written, return immediately. Falling through and trying to access bar data when sc.SetDefaults is true will read uninitialized memory.
• Don't rename after release — chartbooks reference studies by name. Renaming an scsf_ function in a shipped DLL silently breaks every chartbook that uses it.
• Naming hygiene — keep the suffix descriptive and stable. The suffix is what users see in the study list and what they reference in support tickets.
• Linkage — scsf_ functions must have C linkage (Sierra Chart expects un-mangled names). The pattern of including sierrachart.h and using the macros handles this automatically.

Related SCS studies

Every SCS ACSIL study — Trade Manager, the CVD and footprint overlays, Alert Log Monitor, and client-specific Custom Studies — is built around one or more scsf_ functions.