Announcement

Collapse
No announcement yet.

Partner 728x90

Collapse

API Part 1 - Order methods consistency

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

    API Part 1 - Order methods consistency

    Hello,

    One of an interface success (usability, etc.) is or should be its consistency. This is as much for Graphical User "Interface" or Application Programming "Interface".

    Every plane flies, has wings, engine (1 or more), tail and landing gear. The ****pit of a Cessna 172 (small 4-seater) has the same basic instruments as a Boeing 767 and a space shuttle.
    Why? Because they all perform the same basic functionality: fly!
    The difference comes in extras: engine, size, capabilty (weight, take off speed, landing speed, etc.).

    Problem 1.
    ------------
    The order methods in NT6.5 however are by their interface, divided in two groups:
    - those that return "void" (SetSopLoss(), SetTarget() ) and
    - those that return "IOrder" (Enter...(), EXit..() )

    "SetStopLoss()" works great, does all the orders management under the hood:
    - Finds its related Open Orders (Entry and StopLoss)
    - Does all the required cancellation and placing of new orders.

    Until one wants to implement one of the "OnOrder/Position Update()" method, then there is nothing. No information available to the programmer about the orders created and managed by the "SetStopLoss()" method!

    In the case of using the "OnOrder/Position Update()" methods, one has to dramatically change his/her code and replace the "SetStopLoss()" method with the "supposed to be equivalent" "ExitLong/ShortStop()" method!!!

    In other words, if I want to take off on a Boeing 767 instead of a Cessna 172, the yoke/stick (equivalent of driving wheel) is suddenly on the roof or hidden to the pilot. Even Discovery/Columbia/Endeavour all have the yoke/stick at the expected place of a fixed-wing aircraft.

    Problem 2. (related to use of "ExitLong/ShortStop()"
    ----------------------------------------------------
    When implementing the "OnOrder...", "OnPosition..." methods, one has to check the "Token" (ID) of the orders. Meaning that every generated order has an ID, which is great.

    However, when one wants to set a StopLoss to an existing open order, one has to store, manage and remember something called an 'fromEntrySignal' (A string Created by the programmer).

    "ExitLongStop(int barsInProgressIndex, bool liveUntilCancelled, int quantity, double stopPrice, string signalName, string fromEntrySignal)"

    Although this might appear to be harmless, it makes the program more error-prone.
    One of OO good practice is re-usability. Why no re-use the Token or ID already generated and is guaranteed to be unique?

    Suggestions:
    --------------
    If ALL order handling methods used the IOrder class, there would be one place and one place only to set and/or retrieve orders info: IOrder.

    This will make the API easier to use, consistent and introduce re-usability, which will increase maintainability of our code (and yours in some extent) and productivity of the API users (us).

    Direct Benefit for you: Less support (on related items)!
    Direct benefit to us: Plenty.

    Cheers,
    Obi

    #2
    Obi,

    The Set() methods are generally for people who don't want to mess around with advanced order handling. It is designed for use with quick use rather than complex use. If you have needs for more advanced handling you should be using IOrders right off the bat.
    Josh P.NinjaTrader Customer Service

    Comment


      #3
      Hello,

      That's what I was told and so I did. But here is the problem:

      In my code, I do the following:
      Global Vars
      -----------
      private string _entrySignalName = null;
      private string _stopSignalName = null;

      ...

      // Set the signal Entry Order Signal Name
      _entrySignalName = "SELL " + _orderQuantity.ToString() + " @ " + entryPrice.ToString();
      // Send a Market Order
      _entryOrder = EnterShort( _PrimaryBars, _orderQuantity, _entrySignalName );

      ...

      // Set the Stop Order signal name
      _stopSignalName = "Trailing_Stop";

      // Now set the Trailing stop
      _stopOrder = ExitLongStop( _PrimaryBars, true, _stopOrder.Quantity, stopPrice, _stopSignalName, _entrySignalName );

      Nothing wrong so far, untill I realised that my Trailing Stops were not being executed. A trace through the program reveals the following:

      When created, this is what the "_entryOrder" has as properties:

      Action : SellShort
      AvgFillPrice : 98.26
      Filled : 1
      FromEntrySignal : ""
      Instrument : {$USDJPY Default}
      LimitPrice : 0.0
      LiveUntilCancelled : false
      Name : "SELL 1 @ 98.27"
      Oco : ""
      ...

      Clearly the property 'FromEntrySignal' which should equal my 'entrySignalName' is not, instead, the 'Name' property has the 'entrySignalName' value !!!!

      So, my "ExitLongStop()" calls are not tied to any "Entry Order"!!!

      How do I solve this unexplained 'feature'?

      Cheers,
      Obi

      Comment


        #4
        Also, although, the "SetStop/Target/Trail" methods are intended for 'simple' users, they can still set the IOrder properties, so that, if a 'not-so' simple users would like to access these properties, they have the ability to.

        That doesn't change anything for the other users, but adds accessibility and features for the second group of users.

        The "SetStop/Target/Trail" methods are already internally manipulating/generating/populating the IOrder object anyway, you just have to make it visible to the second group of users and this is transparent to the former group!

        What I am saying is that the API should cater for simplicity (Which you are doing), but too much simplicity can become cumbersome and counter-productive.
        You will make NinjaTrader a much better and sought after platform by allowing those with development/mathematical background to harness the power of NT in combination with pure OOP and a higher progr. language.

        Cheers,
        Obi

        Comment


          #5
          Obi,

          There are many implications and as such Set() do not provide IOrders.
          Josh P.NinjaTrader Customer Service

          Comment

          Latest Posts

          Collapse

          Topics Statistics Last Post
          Started by aa731, Today, 02:54 AM
          0 responses
          4 views
          0 likes
          Last Post aa731
          by aa731
           
          Started by thanajo, 05-04-2021, 02:11 AM
          3 responses
          470 views
          0 likes
          Last Post tradingnasdaqprueba  
          Started by Christopher_R, Today, 12:29 AM
          0 responses
          10 views
          0 likes
          Last Post Christopher_R  
          Started by sidlercom80, 10-28-2023, 08:49 AM
          166 responses
          2,237 views
          0 likes
          Last Post sidlercom80  
          Started by thread, Yesterday, 11:58 PM
          0 responses
          4 views
          0 likes
          Last Post thread
          by thread
           
          Working...
          X