• If this is your first visit, you will have to register before you can post. To view messages, please scroll below and select the forum that you would like to visits. Questions? Be sure to check out the Forum FAQ.

Announcement

Collapse
No announcement yet.

Partner 728x90

Collapse

Object rejection question.

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    Object rejection question.

    If we going to set it to be like this

    RealtimeErrorHandling = RealtimeErrorHandling.IgnoreAllErrors;

    What happens to the rejected order? It will not be cancelled? If that so then no need to clear the IOrder object and submit again right?

    #2
    Hello luxurious_04,
    Thanks for your post.

    Setting RealtimeErrorHandling to IgnoreAllErrors can have serious adverse affects on a running strategy unless you have programmed your own order rejection handling in the OnOrderUpdate() method.

    Help Guide - RealtimeErrorHandling
    JoshNinjaTrader Customer Service

    Comment


      #3
      Yes I know but what I want to ask is what will happen to the rejected order in that setting?It will be cancelled or not in that setup?

      Comment


        #4
        There is no way NinjaTrader knows what you want to do when an order is rejected and you are using IgnoreAllErrors. Your strategy would continue to submit orders without thinking about the rejection. You could also be left with an unprotected position and not realize it
        JoshNinjaTrader Customer Service

        Comment


          #5
          Originally posted by luxurious_04 View Post
          Yes I know but what I want to ask is what will happen to the rejected order in that setting?It will be cancelled or not in that setup?
          It won't be 'cancelled' in the strict coding sense, because OrderState.Cancelled and OrderState.Rejected are two different states. But, yes, both states are terminating states. So, for all intents and purposes, yeah, sure, you could sorta kinda say it was 'cancelled', but I wouldn't say it that way -- you will eventually confuse yourself.

          To be precise, the Rejected order is now terminated and not going any further, so it may appear to you like it was 'cancelled' -- but it was not Cancelled, it was Rejected.

          Cancelled and Rejected are two completely different states.
          Don't get them confused by saying the 'rejected order was cancelled'.
          Instead, think this way: the 'rejected order was terminated'.

          -=o=-

          A bigger obstacle to understanding and handling of the Rejected order is: part of the Rejected order may have been filled.

          For a Rejected entry order that has Filled > 0, you have to handle that situation, because you are no longer flat.

          Interestingly, both stop and profit target orders can also be Rejected, so you'll have to decide what to do about those, too.

          I believe the default behavior for NinjaTrader handling of Rejected orders is to cancel all remaining orders and flatten the position(*). In most instances, I have found this default behavior to make good sense (**).

          If you wish to bypass that default behavior, you should probably have a very good understanding of each OrderState as a beginning foundation.

          For NT7, there is a nice state diagram for OrderState here.

          Good luck!

          (*) I think the default behavior also stops the strategy, which I don't like.
          (**) My own OrderState.Rejected handler punts to this default behavior if the variety of special circumstances I'm looking for are not detected.

          Comment


            #6
            Originally posted by bltdavid View Post
            ...
            (**) My own OrderState.Rejected handler punts to this default behavior if the variety of special circumstances I'm looking for are not detected.
            And that might be the most important part of the post. Punt to the default, if none of the circumstances that you have been able to account for are true. We must always code in a manner that safeguards our equity if our coding cuteness fails us. Remember Murphy's Law.

            Comment


              #7
              Originally posted by koganam View Post
              And that might be the most important part of the post. Punt to the default, if none of the circumstances that you have been able to account for are true. We must always code in a manner that safeguards our equity if our coding cuteness fails us. Remember Murphy's Law.
              Yep, in essence I'm installing a 'filter' to watch for Rejected orders appearing in OnOrderUpdate. If the filter detects something it can handle, well, it handles it -- if not, the filter shouldn't just do nothing (because it can't defer to the default NT behavior, since it has been turned off) so the filter replicates the default behavior itself.

              Thus, in my OnOrderRejected filter, doing 'nothing' really meant writing code to do the default behavior.

              If it's safe (which it usually is), my default behavior replicates the cancel & flatten but bypasses the 'disable the strategy' part, since I want my strategy to continue running. (But, if for some reason OnOrderRejected decides it's 'unsafe' to continue, the strategy can also be disabled.)

              -=o=-

              One reason why coding a custom OnOrderRejected is very advanced is because you have to write the default behavior with an understanding of the messaging nature of NinjaTrader. That is, the default behavior in my OnOrderRejected is to cancel all orders, set a special RejectedInProgress flag (and perhaps the HaltingInProgress flag, too), and then return. So far, so good, right? Sure, but we're not done yet.

              The idea is that all the cancelled orders will automatically transition to OrderState.Cancelled, which will be detected in future calls to OnOrderUpdate. After all orders have transitioned to OrderState.Cancelled, only then is it safe to flatten the position. After a flat position is detected, such as in a future call to OnPositionUpdate, only then is it safe to disable the strategy (assuming HaltingInProgress is true).

              Replicating the default behavior of cancel+flatten+disable is actually rather complex. Two extra boolean flags help define the next actions to be taken when the current 'in-progress' state is detected in subsequent future calls to OnOrderUpdate and OnPositionUpdate.

              Comment

              Latest Posts

              Collapse

              Topics Statistics Last Post
              Started by Conall, Today, 06:11 AM
              0 responses
              2 views
              0 likes
              Last Post Conall
              by Conall
               
              Started by Vincere, Yesterday, 11:20 PM
              1 response
              9 views
              0 likes
              Last Post NinjaTrader_PaulH  
              Started by uday12, Yesterday, 10:07 PM
              1 response
              4 views
              0 likes
              Last Post bltdavid  
              Started by cnecorp, Today, 03:04 AM
              3 responses
              18 views
              0 likes
              Last Post cnecorp
              by cnecorp
               
              Started by bxl2019, Yesterday, 07:59 AM
              1 response
              24 views
              0 likes
              Last Post NinjaTrader_ChrisSch  
              Working...
              X