To repeat (what we have been researching in that referenced topic) the problem is that whenever strategy creates order and it is passed with the "Submitted" state order is into OnOrderUpdate (where we can detect this "Submitted" event), however after that the orders were lost without any further traces. We tested override OnOrderTrace() to monitor the orders and found there are MANY DIFFERENT SCENARIOS when the order action is not being passed to `OnOrderUpdate`. (The above referenced topic mentioned some example scenarios when this happens)
After enabling TraceOrders, it turned out that those orders' consequences were being revealed inside `OnOrderTrace` events (Thanks for that, we found that after "submitted" state, some logical criterias lead orders to cancel. HOWEVER, THEY WERE NOT BEING PASSED INTO `OnOrderUpdate` and we only detected that fact using TraceOrders).
However, there are 2 major problems for which we submit feature request and hope that you take seriously the vendor-programmers critical request, as many of our clients are affected for this reason in their trading.
(Problem 1)
TraceOrder logs are in PLAIN STRING Messages. Currently, that method just passes STRING MESSAGES:
protected override void OnOrderTrace(DateTime timestamp, string message)
PLEASE IMPLEMENT A NEW OVERLOAD for that method to provide `order object` instead of the string message. AT THIS MOMENT, WE ARE DOING REGEX PARSING OF THE STRING MESSAGE TO UNDERSTAND THE REAL EVENTS AND ORDER DETAILS, to find out what happened to order and what is its status. This is so critically important, and just a ridicilous.
(Problem 2)
After you fix the problem1, that is not enough for algoritmic programmers. WE SHOULDNT BE BUILDING TRADING LOGIC for strategies which are dependent on `OnOrderTrace` events (we shouldnt be producing strategies which depends on customers to have TraceOrders enabled in their strategies, so as without enabling that, our strategies will just fail logically and lead to incorrect failure trading).
So, PLEASE PASS all events inside `OnOrderUpdate`. After debugging in Visual Studio, it seems there are many cases, somewhere probably within `SubmitOrderManaged` method, there happens OnTraceOrder events (giving logs that order was canceled due X reason), but then it returns from `SubmitOrderManaged` method right away. IT IS NOT CORRECT BEHAVIOR, because on every case of `OnOrderTrace`, there should be `OnOrderUpdate` events too, which will trigger our strategies `OnOrderUpdate` event, so we can control by our codes, whatever happen to order. PLEASE DONT ANYWHERE use `if (TracOrders) OnTraceOrder(..)` events without consequent `OnOrderUpdate` (or create alternative `OnOrderUpdateAll` overloaded method, which will be called always) so, we have every possible scenario controlled for order , and our orders wont be lost in abyss status and our strategies will not collapse. So, to repeat, offering to use `OnOrderTrace()` events to manage our strategies logic (to react when order is cancelled, ignored etc) is NOT A SOLUTION, as CLIENTS ARE NOT USING "TraceOrders=true" at all in their strategies and `OnOrderTrace` is not even a considerable method to build an entry/exit logic depending on it. `OnOrderTrace` is merely a quick debugger to output some messages, and cant be a LOGICAL part of strategy.
(Problem 3)
There are also many places, when NinjaTrader logs and prints (probably by method LogAndPrint) from `SubmitOrderManaged` however, OnOrderTrace doesnt happen. That is not correct also, as whatever logs are outputed into client's NT, those logs should be also available programatically in OnOrderTrace, so we have our hook to collect/analyze those logs, without SEPARATELLY grabbing LOGS from NT folders and then adding our TraceOrder messages, and thus, the combined bucket gives the complete scenario. INSTEAD, EVERYTHING whatever is passed in LogAndPrint (related to orders/submitodermanaged/etc) should be also available in OnOrderTrace events too.
Request:
I know that your response (whoever reads this) will be very formal "thank you for reporting" kind with undetermined unpromising reply, but please from NT SUPPORT DEVS, once again carefully consider that this is not a feature request for indicator, visuality or some candy features and attributes of platform, instead THIS IS DETRIMENTAL PROBLEM affecting MANY REAL TRADER clients of mine. You can check that we are NT Vendor programmers, and also we are providing services for NT programming to many SERIOUS clients (can be checked our profiles over different freelancing sites too) and we are meeting this problem already numerous times and our clients are affected for this, causing us to FAIL IN CODING the robust NT strategies and we are just suffering, while numerous clients are complaining about problematic orders several times in a day.
Comment