sc.Input

What it is

sc.Input is the mechanism by which a Sierra Chart study exposes user-editable parameters. Anything a user can configure from the study settings dialog — a length, a color, a boolean toggle, a time of day, a file path — is declared as an input inside the study's SetDefaults block. The platform then renders the corresponding form control in the settings UI and persists the user's choice in the chartbook.

Inputs are stored in an array on the study interface: sc.Input[0], sc.Input[1], and so on. Each input has a name, a type, and a value. The name is what the user sees in the settings dialog. The type determines the form control — a numeric input, a checkbox, a color picker, a dropdown, a path picker, a time-of-day field, etc. The value is what the runtime body of the study reads on each pass.

Inputs are also the natural unit for backwards compatibility. Each input lives at a fixed integer index, so old chartbooks can re-open against newer versions of a study as long as the indices stay stable. Reordering inputs is a breaking change for users with saved chartbooks.

Why it matters

Inputs are how a generic study becomes useful to many users. Without inputs, a moving average study is fixed at length 20; with inputs, every user picks their own length. The full range of Sierra Chart input types — including ranges, drop-down lists, custom strings, datetimes, file paths, and color pickers — covers nearly every kind of configuration a study needs.

For SCS, inputs are also how clients customize a study without having to touch source code. A trader buying Trade Manager configures risk percentage, take-profit multiple, max position cap, and directional filter entirely through the inputs panel — no recompilation, no support ticket.

How it's used in ACSIL code

In SetDefaults, the study declares each input by calling its Name, SetInt, SetFloat, SetYesNo, SetColor, SetTimeAsSCDateTime, SetPathAndFileName, or one of the other typed setters, plus optional bounds for numeric inputs. In the runtime body, the study reads the current value with the corresponding GetInt, GetFloat, GetYesNo, etc.

The settings dialog renders inputs in index order, not in declaration order in the source file. The two usually match, but if you assign sc.Input[5] before sc.Input[3] in code, the dialog still shows index 3 above index 5. This is also why inserting a new input means choosing its index deliberately: appending to the end is always safe, but inserting in the middle shifts every later index by one — a chartbook-breaking change.

Common patterns / pitfalls

• Never reorder inputs after release — chartbooks reference inputs by index. Reordering scrambles every user's saved settings silently.
• Append, don't insert — if you need a new input on a shipped study, give it the next free index, even if the dialog ordering becomes a little awkward.
• Sensible defaults — every input should have a default that makes the study functional out of the box.
• Bounds for numeric inputs — set SetIntLimits / SetFloatLimits so users cannot enter nonsensical values.
• Use enums via SetCustomInputStrings — for discrete choices (mode A / B / C), a dropdown is friendlier than asking the user to remember integer codes.

Related SCS studies

Trade Manager has the largest input surface of any SCS study — risk mode, position sizing parameters, take-profit multiple, max contracts cap, directional filter, ACS button configuration. CVD Filled Area uses inputs for reset mode, fill colors, transparency, outline mode. Every SCS study exposes its behavior through sc.Input.