Support Board
Date/Time: Sat, 19 Apr 2025 08:01:27 +0000
Post From: Does anyone know what triggers printing StartDateTimeForLoadingOrderFills to message log?
| [2025-04-17 22:45:26] |
| User351137 - Posts: 14 |
|
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. |