Support Board
Date/Time: Thu, 21 Nov 2024 17:51:53 +0000
Post From: Optimized ACSIL Studies: Strategies for Combining Studies and Reducing Manual GUI Effort?
| [2024-11-07 02:51:58] |
| User133994 - Posts: 80 |
|
Experts, I have numerous custom ACSIL studies, labeled as a, b, c, d, etc., totaling hundreds. I can currently apply studies a, b, and c to a chart independently. However, as the number of these studies grows, it would be more efficient to combine a, b, and c into a single study. The objectives are to: 1) reduce the number of custom studies needed on the chart to achieve the same output; 2) ensure each custom study operates independently, not requiring any existing study on the chart; 3) maintain the ability to use and update a, b, c separately as needed, and then integrate any updates into the combined version. Assume study c relies on studies a and b. I understand that I can integrate the code from studies a and b into c, but this integration requires adjusting the output/input indices to prevent overlap (e.g., Output #1 is shared among a, b, and c, so it would need to be reassigned to Subgraph 1, then 2, then 3). An alternative to avoid this re-indexing is to use .Arrays[] for a subgraph. This approach allows me to directly remap the outputs into the additional arrays tied to an output subgraph, like this: SCFloatArrayRef o_s_Shaved_UP = E_Subgraph_ExtraArrays.Arrays[2]; SCFloatArrayRef o_s_Shaved_DOWN = E_Subgraph_ExtraArrays.Arrays[3]; instead of //{{{ o_s_Shaved_UP
SCSubgraphRef o_s_Shaved_UP = sc.Subgraph[o_s++]; if (sc.SetDefaults) { o_s_Shaved_UP.Name = "o_s_Shaved_UP"; o_s_Shaved_UP.DrawStyle = DRAWSTYLE_COLOR_BAR_CANDLE_FILL; o_s_Shaved_UP.PrimaryColor = COLOR_AQUA; o_s_Shaved_UP.LineWidth = 5; o_s_Shaved_UP.DrawZeros = false; } //}}} //{{{ o_s_Shaved_DOWN SCSubgraphRef o_s_Shaved_DOWN = sc.Subgraph[o_s++]; if (sc.SetDefaults) { o_s_Shaved_DOWN.Name = "o_s_Shaved_DOWN"; o_s_Shaved_DOWN.DrawStyle = DRAWSTYLE_COLOR_BAR_CANDLE_FILL; o_s_Shaved_DOWN.PrimaryColor = COLOR_PINK; o_s_Shaved_DOWN.LineWidth = 5; o_s_Shaved_DOWN.DrawZeros = false; } //}}} This method allows me to maintain the existing logic that assigns values to o_s_Shaved_UP[sc.Index] (or DOWN) because I can keep using the same variable names but redirect them to an extra array. Assuming these outputs originate from custom study 'a', I want to reuse this logic in a new custom study as is. I can copy and paste the logic blocks, remap the outputs to the extra arrays, and voila, I have the outputs of 'a' accessible in 'b' without needing to add 'a' as an 'input study'. However, I have noticed differences in the behavior of study b (or c, or d) when using 'a' as a separate compiled input study versus integrating its logic into a new study and using extra arrays. It seems there might be a difference in how Sierra Chart processes logic structures designated as outputs versus those designated as extra arrays. For example, outputs can be set to hidden, ignore, or other statuses, while an extra array is never visible in the GUI, potentially affecting its execution. Does anyone have insights or examples of using extra arrays instead of output subgraphs to maintain identical logic? Perhaps Sierra Chart has a mechanism I'm unaware of that facilitates this approach without requiring multiple studies to be compiled and connected in a specific order through the GUI. Any thoughts or working examples that align with these objectives would be greatly appreciated. I'd like to avoid utilizing `sc.Input[]` to access the logic of other custom studies, as this method necessitates compiling and connecting numerous studies in a precise sequence through the GUI. This results in significant manual effort, which grows exponentially, particularly when dealing with hundreds of custom studies, each potentially having multiple inputs and outputs. All of the questions above are seeking help in managing the substantial manual effort required for integrating hundreds of studies. Is there an entirely different approach within ACSIL that could alleviate these exponentially growing manual efforts, which currently can only be managed through the GUI without introducing inconsistent behavior or necessitating extensive refactoring? Thanks in advance for your input and any working examples. |