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, consuming bar data and producing 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, and 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.