Support Board
Date/Time: Mon, 25 Nov 2024 14:24:32 +0000
ACSIL - Increase the number of sub-graphs
View Count: 1624
| [2014-02-05 05:10:10] |
| ejtrader - Posts: 688 |
|
SC Team - Trying to consolidate few of the custom studies into a single study and running into limitation of number of sub-graphs available. Would it be possible to increase this from current 40 to 60 (or preferably 75)? PS: Please note that I have optimized enough on this aspect and really in need of higher number of sub-graphs. thanks Date Time Of Last Edit: 2014-02-05 06:18:49
|
| [2014-02-05 09:46:49] |
| |
|
Do you need these for drawing? Keep in mind that each Subgraph contains additional internal data arrays.
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, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2014-02-05 14:42:50] |
| ejtrader - Posts: 688 |
|
SC team - Yes, I do need this for drawing (though most of the time only few of them would be drawn - conditionally). I am already using internal data arrays ( sg.Array[] for intermediate calculations). Thanks |
| [2014-02-05 17:19:39] |
| |
|
We do not see this change coming anytime soon. This is not simple to increase the number of arrays and we have a lot of other things to do. It is already very high. Please do not put reliance on an increase in the number of study Subgraphs.
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, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2014-02-05 17:22:21] |
| ejtrader - Posts: 688 |
|
If it is not simple to change - It's understandable. Would look for alternate ways to do this - probably with couple of studies rather than single study - which would have been more helpful. However - would you please keep this in your to-do list to get this done at some point rather than discarding it completely. Edit - I would bring this up once in every few weeks - just as a reminder so that this is not forgotten completely. Hope you don't mind. Thanks Date Time Of Last Edit: 2014-02-06 17:35:05
|
| [2014-02-06 15:16:19] |
| ejtrader - Posts: 688 |
|
SC Team - Wondering how many internal arrays are available. sg.Array[0] sg.Array[1] .. sg.Array[N] - What's the Max N here? Thanks Date Time Of Last Edit: 2014-02-06 15:17:18
|
| [2014-02-11 05:50:09] |
| ejtrader - Posts: 688 |
|
SC Team - Whenever you get to increasing the number of sub-graphs, would you please see the possibility of adding few persistent vars for floats in this form ? sc.PersistVars->floats[N] You currently have for integers & doubles but not floats in this specific form. Thanks Date Time Of Last Edit: 2014-02-11 05:51:05
|
| [2014-02-11 05:50:59] |
| |
|
A double is better than a float because it has more precision. There are 64 doubles. Is that not enough?
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, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2014-02-11 05:55:11] |
| ejtrader - Posts: 688 |
|
Fair enough. Thought of storing the current price values in their original form rather than converting them to doubles. the current number of 64 floats is good enough. But the floats[N] etc would allow me to use dynamic variable name to define them to avoid any kind of potential conflicts with the reuse and at the same time keeping the code clean. This is not so critical feature request though. Just thought of asking in case if you are ever going to visit this area for any changes in the near future. Thanks // Integers - convenient to use in this form int ivars=0; int& i1=sc.PersistVars->Integers[ivars++]; int& i2=sc.PersistVars->Integers[ivars++]; .. // Floats - no such option int fvars=0; float& f1=sc.PersistVars->floats[fvars++]; float& f2=sc.PersistVars->floats[fvars++]; .. Date Time Of Last Edit: 2014-02-11 06:06:02
|
To post a message in this thread, you need to log in with your Sierra Chart account: