Closed jmscraig closed 3 years ago
Yep design the code flow and calls so that it doesnt bump into that issue at that time. No need to make orders null until new ones are sent for example and swap to prior or put them in a structure for each trade etc so you can refer back and forth to each trade op --
Dictionary of Proposed Trade as structure to include a generic structure class TradeOperationGeneric { IEnumerable OrdersEntry IEnumerable OrdersExitStopsLoss IEnumerable OrderExitsTargets
bool IsOrderEntryAnyActive bool IsOrderExitsStopLossAnyActive bool IsOrderExitsTargetAnyActive bool IsOrdersActve } or 3) class TradeOperation { Order OrderEntry1 Order OrderEntryOcoLong Order OrderEntryOcoShort
Order OrderStoploss1 Order OrderStoploss2 Order OrderStoploss3 Order OrderStoploss4
Order OrderTarget1 Order OrderTarget2 Order OrderTarget3 Order OrderTarget4 }
will close this to allow focus on the core as that is design caveat of the derived system not an engine issue
This is just an interesting observation .. oh the joy of multithreading.
A tight try-catch around this will make this problem a non-issue but shows the challenge of our multi-threaded design work.
I was warming up an old strategy to use to test AlgoSystemsBase.
So only a few nano-seconds after if(scalpEntryXBOrder != null was true it was now false.
An this was running after hours .. .not very fast
Your Thoughts?