Support Board
Date/Time: Thu, 17 Apr 2025 22:47:43 +0000
[Programming Help] - Does anyone know what triggers printing StartDateTimeForLoadingOrderFills to message log?
View Count: 40
| [2025-04-14 00:42:45] |
| drinkcodejava - Posts: 24 |
|
I'm trying to get clarification on Working with ACSIL Arrays and Understanding Looping: When the Study Function is Called I have a custom study with an if (sc.IsFullRecalculation && sc.Index==sc.ArraySize-1) block that is getting executed twice when I recalculate a chart (Chart >> Recalculate). My understanding of the documentation is that when a study is recalculated, the study is called once for each bar of the chart starting from sc.Index=0 through sc.Index=sc.ArraySize-1. However, when I load the following test study, the study runs for each bar, then starts all over again and runs a second time for each bar. In between runs, I see a message printed to the log about StartDateTimeForLoadingOrderFills. I don't know if perhaps this is related to what the documentation describes as "rebuilding of the internal Trades List", but I cannot find any further documentation on either the message or the internal Trades List. It seems like whatever is triggering this message is also triggering another full recalculation. Can anyone help explain what is going on? Here is the code for the test study, and then the message log output for when I: - First add the study to a chart (20:05:56) - Click OK in the Chart Studies dialog window (20:06:10) - Recalculate the chart (20:06:44) - Reload and Recalculate the chart (20:07:09) Bottom line is I'm trying to figure out how to prevent the second round of full recalculation when a chart is recalculated. Thanks! #include "sierrachart.h"
SCDLLName("Full Recalculation Calls") SCSFExport scsf_FullRecalculationCalls(SCStudyInterfaceRef sc) { SCString msg; if (sc.SetDefaults) { sc.GraphName = "Full Recalculation Calls"; sc.AutoLoop = 1; // 1 = Automatic looping is enabled sc.AddMessageToLog("Set defaults called",0); return; } int& callCount = sc.GetPersistentInt(0); // FullRecalculation occurs when a study (or a collection that includes it) is added or when a chartbook is opened // A study function is called twice after data is loaded; once to set defaults, and once again for FullRecalculation // During FullRecalculation, the study function gets called once for each chart bar if (sc.IsFullRecalculation) { sc.AddMessageToLog("FULL RECALCULATION",0); if (sc.Index == sc.ArraySize-1) { callCount++; msg.Format("Call count: %d", callCount); sc.AddMessageToLog(msg,0); } } } 2025-04-13 20:05:56.304 | Chart: MESM25[M] 1 Min #5 | Study: Custom DLL Study | Set defaults called
2025-04-13 20:06:10.947 | Chart: MESM25[M] 1 Min #5 | Study: Full Recalculation Calls | FULL RECALCULATION | Number times message added: 1566 2025-04-13 20:06:10.950 | Chart: MESM25[M] 1 Min #5 | Study: Full Recalculation Calls | Call count: 1 2025-04-13 20:06:44.725 | Chart: MESM25[M] 1 Min #5 | Study: Full Recalculation Calls | FULL RECALCULATION | Number times message added: 1566 2025-04-13 20:06:44.726 | Chart: MESM25[M] 1 Min #5 | Study: Full Recalculation Calls | Call count: 2 2025-04-13 20:06:45.022 | MESM25[M] 1 Min #5 | StartDateTimeForLoadingOrderFills: 00:00:00 2025-04-13 20:06:45.097 | Chart: MESM25[M] 1 Min #5 | Study: Full Recalculation Calls | FULL RECALCULATION | Number times message added: 1566 2025-04-13 20:06:45.098 | Chart: MESM25[M] 1 Min #5 | Study: Full Recalculation Calls | Call count: 3 2025-04-13 20:07:09.319 | MESM25[M] 1 Min #5 | Reloading chart. 2025-04-13 20:07:09.513 | MESM25[M] 1 Min #5 | StartDateTimeForLoadingOrderFills: 00:00:00 2025-04-13 20:07:09.513 | Chart: MESM25[M] 1 Min #5 | Study: Full Recalculation Calls | FULL RECALCULATION | Number times message added: 1567 2025-04-13 20:07:09.514 | Chart: MESM25[M] 1 Min #5 | Study: Full Recalculation Calls | Call count: 4 2025-04-13 20:07:09.517 | MESM25[M] 1 Min #5 | Chart data loading complete. 2025-04-13 20:07:09.580 | Chart: MESM25[M] 1 Min #5 | Study: Full Recalculation Calls | FULL RECALCULATION | Number times message added: 1567 2025-04-13 20:07:09.581 | Chart: MESM25[M] 1 Min #5 | Study: Full Recalculation Calls | Call count: 5 |
| [2025-04-17 22:45:26] |
| User351137 - Posts: 12 |
|
Hello drinkcodejava, Confirming your observation regarding the multiple full recalculation passes when triggering Chart >> Recalculate or Reload and Recalculate. We've noticed a related behavior in our own custom studies that might shed some light on the process occurring between those recalculation cycles. You correctly pointed out the StartDateTimeForLoadingOrderFills: 00:00:00 message appearing between the recalculation runs. Our findings suggest that this marks a critical phase where Sierra Chart explicitly reloads or rebuilds its internal trade data structures (the order fill list, which impacts position and trade statistics). Specifically, during the interval initiated by StartDateTimeForLoadingOrderFills (after the first recalculation pass but potentially before the second one fully completes and stabilizes), we've observed that ACSIL functions retrieving trade-related data – such as sc.GetOrderFillArraySize(), sc.GetTradePosition(), and sc.GetTradeStatisticsForSymbolV2() – can return transient inconsistent values (often zero or default states), even if there are existing fills or positions. Our hypothesis is that the internal trade data structures (like the fill list or position data derived from it) might not be fully populated or stabilized immediately after the first recalculation phase but before the subsequent one (triggered after fill loading) completes. This can lead to issues in studies that rely on comparing the current trade state (obtained via these functions) with a state saved just before the reload/recalculate action, potentially causing false triggers or incorrect logic execution in that very brief intermediate window. Currently, the only way we've found to mitigate this is by implementing a workaround: intentionally waiting or skipping the initial few calculation cycles after detecting such a reload event, specifically waiting until after the second recalculation phase (or subsequent updates) seems to have fully stabilized the trade data access functions. While this workaround helps manage the symptom, it doesn't address the root cause or the reason for the double recalculation. We hope Sierra Chart support can provide insight or perhaps a more direct ACSIL mechanism to reliably determine when all chart data, including internal trade lists and statistics, is fully loaded and stable after a reload or recalculation event. This would allow for more robust and efficient custom study development involving trading logic. Hope this shared observation and context is helpful. |
To post a message in this thread, you need to log in with your Sierra Chart account: