Cancel-placed-order-at-broker-via-code

The absence of the order in the subsequent batch of signals is enough to have the order get canceled in the order manager. Just give it a try in the dummy broker for example to test it out.

Hi Glitch. It still puzzles me

CODE:

            if (!HasOpenPosition(bars, PositionType.Long))
            {
                // running 1 minute strategy time frame."s_" is synchronized 15 minute data.
                // 1. What happens with the placed signals from the first 5 minutes?
                if (   idx % 15 < 5 // check first 5 minutes
                    && bars.Close[idx] > s_ema4[idx]
                    && s_ema4[idx] > s_ema8[idx]
                    && s_hh[idx] * 0.99 > s_ll[idx])
                {
                    PlaceTrade(bars, TransactionType.Buy, OrderType.Limit, bars.Close[idx] * 0.9975, "Buy Limit 0%");
                }
            }

This code checks signals for the first 5 minutes of a 15-minute block.
The price from the 1-minute time frame is compared with the synchronized data.
A sell signal can be generated every minute. Now there are different statuses.

1. a placed order from the first 5 minutes is placed and should not be cancelled until 10 minutes of this block have passed. (10 is arbitrarily chosen now) Checking the condition again from minute 6 would already happen based on a different price. So, I don't want a new signal, I want the existing signal to stay alive.

2. after 10 minutes I am no longer interested in opening the position in this block. Now i want to cancel the placed order. I want to give some room between the buy signal, or filled position and the coming sell signals

3. from minute 5-15 no more signals are generated.

So the conflict, as I understand your answer, is that the order would be cancelled immediately, but I don't want that.
It should remain in place until the strategy triggers an active cancellation.

I did not test your suggestion until now, but isn't there a conflict between my first two points?

Ok, your reply is clear and i know how to handle it.

I need to buffer the data, in the example 5 minutes of price data, to repeat the signals.
I then control the cancellation by not sending any signals.

The principle is clear and also requires further logic to implement.
Using the buffer with additional logic (possibly an additional buffer for signal status) I can generate the signals again. Not too complicated.

Your reliance on bar numbers is misplaced. Please don't do that in a real trading strategy where you need to have consistent results. Index numbers aren't aligned with minute intervals. Bar 0 could be a bar at 09:37. And, these indices will change depending on missing bars (zero volume), when you start loading data, etc. Just don't!

Here's one way to solve it. This creates a list of "times" that you can check to keep an order alive or not. (fwiw, in 25 years, I've never seen anyone do it this way!)

CODE:
using WealthLab.Backtest;
using System;
using WealthLab.Core;
using WealthLab.Indicators;
using System.Collections.Generic;

namespace WealthScript3 
{
    public class MyStrategy : UserStrategyBase
    {
        //create indicators and other objects here, this is executed prior to the main trading loop
        public override void Initialize(BarHistory bars)
        {
         //set up the times
         int interval1 = 15;      // this is the main interval
         int interval2 = 10;      // this is number of minutes to keep your exit order live
         TimeSpan ts = new TimeSpan(9, 29, 0);
         TimeSpan tsMinute = new TimeSpan(0, 1, 0); 
         while (ts < bars.Market.GetCloseTimeMarketTime().TimeOfDay)
         {
            for (int n = 0; n < interval2; n++)
            {
               ts = ts.Add(tsMinute);
               _keepAlive.Add(ts); 
            }
            for (int n = 0; n < interval1 - interval2; n++)
               ts = ts.Add(tsMinute);
            
         }

           //time check
         foreach (TimeSpan timeSpan in _keepAlive)
            WriteToDebugLog(timeSpan);
         
        }

        //execute the strategy rules here, this is executed once for each bar in the backtest history
        public override void Execute(BarHistory bars, int idx)
        {
            if (!HasOpenPosition(bars, PositionType.Long))
            {
                //code your buy conditions here
            }
            else 
            {
            //code your sell conditions here
            if (_keepAlive.Contains(bars.DateTimes[idx].TimeOfDay))
            {
               //repeat exit orders
            }
            }
        }

      List<TimeSpan> _keepAlive = new List<TimeSpan>();

    }
}

Ultimately, the main thing for me at the moment is to advance my learning curve and simply try out many things.
(Tools, software, programming, trading, etc.) I let myself drift a bit through the topics.

By trying things out, I finally get feedback that helps me move forward, as in this case.
The argumentation with the missing bars is plausible and also very important. Thanks for the hint.

Whether your code does what I have in mind, I can only try in a few days. Thanks for this as well.

QUOTE:

(fwiw, in 25 years, I've never seen anyone do it this way!)

In this case, I was initially curious and reformulated a pure 15 minute based strategy as a 1 minute strategy. I was expecting similar results, of course. Since that worked I just started playing around wildly to see if anything was missed in the granular area or could be optimized otherwise. That's the story ...

Although i did not know how to implement it (the idea we are talking about), because i wasn't aware how the general rules work, the idea keeps the same. Regardless of whether it would really improve anything, I was then simply interested in implementation details and the question of how to control to delete an order.

Finally, I want to improve a "working" strategy in its granular timeframe when the time comes and have the appropriate knowledge to be able to implement that then.

May i ask what you mean with "it" (mixing time frames) ?

"it" is the example above. If you put your ClosePosition() in the _keepAlive exit condition, it will keep triggering the order for the first 10 minutes of that 15 minute period. After that, the order will be canceled.

I would like to add something. The point was not to keep something alive in the beginning. Finally this is only a workaround because the concept of GTD orders is not available in the given framework/design. The algorithm would look different and simpler.

1. Make a GTD order (max 10...5 minutes)
2. An explicit cancel would not be needed for orders that aren't filled

I'm sure other people have been doing that for the last 25 years too.
I guess if you read it that way, it will certainly seem familiar to you.

So, the idea was that i cancel the order explicitly. Because that does not work by design, i needed to keep the others alive, exactly the other way around. If you only look at the (your) result, it is not clear why this is done.

We already had a topic recently where the change in perspective also caused confusion. It was when using the compressor. The idea was to work in a high time frame and check granular data. In the end, the implementation was reversed because the technical resources allow to compress the granular data.

All in all, this is not unusual, imho.
My impression is that the framework and design do not always fit, which is completely normal.
And the ideas need to be adapted to the existing framework/design.

I wish everyone a nice weekend