Login Page - Create Account

Home >> Support Board

Support Board

Date/Time: Sun, 15 Feb 2026 09:25:39 +0000

How to Post a Message for Support

Input DisplayOrder breaks with non-contiguous inputs

View Count: 584

[2025-12-31 00:14:21]
[Go To First Post]
User719512 - Posts: 417
Hi Sierra Chart Engineering,

Use case is defining non-contiguous Inputs for internal use, turning some off between debug/release, dev/prod, and also saving room for new Inputs without having to make breaking changes and shift these into new IDs.

Code is below, and the screenshot attached that demonstrates the issue.

Expectation is both studies display all 4 inputs.


#include "sierrachart.h"

//SCDLLName("InputDisplayOrder");

namespace ns_InputDisplayOrder
{

SCSFExport scsf_InputDisplayOrder1(SCStudyInterfaceRef sc)
{
SCInputRef Input_a = sc.Input[0];
SCInputRef Input_b = sc.Input[1];
SCInputRef Input_c = sc.Input[2];
SCInputRef Input_d = sc.Input[3];

if (sc.SetDefaults)
{
sc.GraphName = "InputDisplayOrder1";
sc.AutoLoop = 0;
sc.DrawZeros = 0;
sc.GraphRegion = 0;
sc.DrawStudyUnderneathMainPriceGraph = 0;
sc.UpdateAlways = 1;

Input_a.Name = "Input_a";
Input_a.SetInt(1);
Input_a.DisplayOrder = 1;

Input_b.Name = "Input_b";
Input_b.SetInt(1);
Input_b.DisplayOrder = 2;

Input_c.Name = "Input_c";
Input_c.SetInt(1);
Input_c.DisplayOrder = 3;

Input_d.Name = "Input_d";
Input_d.SetInt(1);
Input_d.DisplayOrder = 4;

return;
}

for (int barIndex = sc.UpdateStartIndex; barIndex < sc.ArraySize; barIndex++)
{
// do work...
}
}

SCSFExport scsf_InputDisplayOrder2(SCStudyInterfaceRef sc)
{
SCInputRef Input_a = sc.Input[0];
SCInputRef Input_b = sc.Input[1];
SCInputRef Input_c = sc.Input[58];
SCInputRef Input_d = sc.Input[59];

if (sc.SetDefaults)
{
sc.GraphName = "InputDisplayOrder2";
sc.AutoLoop = 0;
sc.DrawZeros = 0;
sc.GraphRegion = 0;
sc.DrawStudyUnderneathMainPriceGraph = 0;
sc.UpdateAlways = 1;

Input_a.Name = "Input_a";
Input_a.SetInt(1);
Input_a.DisplayOrder = 1;

Input_b.Name = "Input_b";
Input_b.SetInt(1);
Input_b.DisplayOrder = 2;

Input_c.Name = "Input_c";
Input_c.SetInt(1);
Input_c.DisplayOrder = 3;

Input_d.Name = "Input_d";
Input_d.SetInt(1);
Input_d.DisplayOrder = 4;

return;
}

for (int barIndex = sc.UpdateStartIndex; barIndex < sc.ArraySize; barIndex++)
{
// do work...
}
}

} // ns_InputDisplayOrder
imageInputDisplayOrder.png / V - Attached On 2025-12-31 00:13:18 UTC - Size: 138.06 KB - 56 views
[2025-12-31 17:00:10]
[Go To First Post]
Sierra_Chart Engineering - Posts: 22861
Yes we are aware of this. This is because there is a large skip of indexes at this point:
SCInputRef Input_b = sc.Input[1];
SCInputRef Input_c = sc.Input[58];
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, use the Teton service:
Sierra Chart Teton Futures Order Routing
[2025-12-31 17:32:50]
[Go To First Post]
User719512 - Posts: 417
Is this a bug/issue/quirk that Sierra will address? Declaring a reference to an arbitrary sc.Input[] array does not seem like the issue, I would guess it's more about which ones have been used where .Name or .SetInt()/etc have been called in SetDefaults, and somehow the "DisplayOrder" logic is not scanning all SC_INPUTS_AVAILABLE to build and sort the inputs for rendering.
[2025-12-31 17:40:08]
[Go To First Post]
Sierra_Chart Engineering - Posts: 22861
This is just how it is. We do not want to make any changes. The way this works is for performance reasons.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, use the Teton service:
Sierra Chart Teton Futures Order Routing
[2025-12-31 18:09:27]
[Go To First Post]
User719512 - Posts: 417
Thank you Sierra for the confirmation. Fully respect your decision and explanation for the design.


For other readers of this thread who might stumble upon this thread:

I did find a workaround (which may or may not be Sierra-approved, nor guaranteed to work in the future) -- Caveat emptor.

I see no (measurable^^) side effects in my studies by adding the following in SetDefaults before the study's normal input default settings


// workaround for Sierra display ordering quirk
for (int index = 0; index < SC_INPUTS_AVAILABLE; ++index)
{
sc.Input[index].SetInt(0);
}

^^NOTE: I am sure there is some impact from this (nothing is ever free), extra allocations, class constructors, or something. Not here to pick that apart or turn this into a performance thread/etc.

This is simply making the study use all available inputs and the costs that come with that, and like normal, inputs hidden from users do not set the Name field.

So, I would expect a study configured like this to have perf of a study using all 128 inputs which may or may not be slower than a study using 4 inputs.
[2025-12-31 19:06:28]
[Go To First Post]
Sierra_Chart Engineering - Posts: 22861
We determined a solution to the problem. In the next release there will be this ACSIL variable:
sc.ProcessStudyUnsetInputs

You will want to set it like this in the sc.SetDefaults code block:
sc.ProcessStudyUnsetInputs=1;
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, use the Teton service:
Sierra Chart Teton Futures Order Routing
Date Time Of Last Edit: 2025-12-31 19:06:47
[2026-01-02 22:27:28]
[Go To First Post]
seandunaway - Posts: 375
int input = 0;
SCInputRef a = sc.Input[input++];
SCInputRef b = sc.Input[input++];
#ifdef DEBUG
SCInputRef c = sc.Input[input++];
SCInputRef d = sc.Input[input++];
#endif
SCInputRef e = sc.Input[input++];
SCInputRef f = sc.Input[input++];
Date Time Of Last Edit: 2026-01-02 22:48:43
[2026-01-19 01:35:32]
[Go To First Post]
User509533 - Posts: 95
The following is not working in the latest version (Ver 2865)

sc.ProcessStudyUnsetInputs=1;

The following is also not working for me,


int input = 0;

SCInputRef a = sc.Input[input++];

SCInputRef b = sc.Input[input++];

#ifdef DEBUG

SCInputRef c = sc.Input[input++];

SCInputRef d = sc.Input[input++];

#endif

SCInputRef e = sc.Input[input++];

SCInputRef f = sc.Input[input++];
[2026-01-24 17:58:07]
[Go To First Post]
User509533 - Posts: 95
Version 2868 has resolved the issue, provided that sc.Input[] uses sequential indices. Thank you, Sierra Chart Engineering, for an excellent product.
[2026-01-24 23:13:50]
[Go To First Post]
Sierra_Chart Engineering - Posts: 22861
We would have to check in what version this was implemented in, but definitely it is implemented in version 2868:
sc.ProcessStudyUnsetInputs=1;
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, use the Teton service:
Sierra Chart Teton Futures Order Routing
Date Time Of Last Edit: 2026-01-24 23:14:09
[2026-01-26 06:51:32]
[Go To First Post]
User509533 - Posts: 95
Just FYI, I'm not using the ACSIL variable: sc.ProcessStudyUnsetInputs. Version 2868 has resolved the issue, provided that sc.Input[] uses sequential indices starting from 0.
[2026-01-30 21:35:01]
[Go To First Post]
ForgivingComputers.com - Posts: 1194
You will want to set it like this in the sc.SetDefaults code block:
sc.ProcessStudyUnsetInputs=1;

What is this undocumented function that breaks studies built on older versions if not set? Multiple DLLs are now broken due to some recent change. Do I now have to check every study ever released for hidden study settings?

Backwards compatibility should be preserved. Developers should not have to go through every released study in order to add this code so the study settings don't disappear when a user updates to the current version.

Isn't there a simpler solution?
[2026-01-31 06:42:20]
[Go To First Post]
Sierra_Chart Engineering - Posts: 22861
We apologize for this. We will write up complete documentation about this .

Also, it is not a case of hidden Study Inputs. This is a case of consecutive unset Study Inputs. When there is a certain number of unset inputs, further processing of inputs stops for efficiency reasons. This makes the processing of studies faster which is very important.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, use the Teton service:
Sierra Chart Teton Futures Order Routing
Date Time Of Last Edit: 2026-01-31 06:42:37
[2026-01-31 10:06:44]
[Go To First Post]
Sierra_Chart Engineering - Posts: 22861
Here is the documentation about this:
ACSIL Interface Members - sc.Input Array: ACSIL Study Input Processing Notes
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, use the Teton service:
Sierra Chart Teton Futures Order Routing

To post a message in this thread, you need to log in with your Sierra Chart account:

Login

Login Page - Create Account