Stop-loss-or-take-profit-on-same-bar

Your question is answered in the website FAQ, have you seen it?

"I want to test a strategy that buys and sells with stop/limit orders on the same bar."
https://www.wealth-lab.com/Support/Faq

And if you still find a way to get the intraday data for a lower time frame, your strategy could benefit from "Use Granular Limit/Stop Processing" (Advanced Strategy Settings). Quoting from the Wealth-Lab 7 Help:

QUOTE:
A realistic simulation when backtesting Stop / Limit Strategies require that higher priorities be assigned to trades that would have been filled earlier chronologically.

When Use Granular Limit/Stop Processing is checked, Wealth-Lab prioritizes (processes) transactions based on the time of day that the transaction would have been filled. It's accomplished by searching through intraday data at the specified Granular Scale.

Thinking about granular processing... it won't be helpful in this case (at least not yet).

Exit transactions don't have a precedence for backtesting other than Market orders are filled before a Stop or Limit order on the same bar, and these before a MarketClose order.

But use this as a test on SPY. With or without granular processing the exit is random. Subsequent runs on SPY will fill at the stop on some runs and at the limit on others. At a minimum, we need to make this worse case for backtesting - unless granular processing can be applied.

CODE:
using WealthLab.Backtest;
using System;
using WealthLab.Core;

namespace WealthScript123
{
    public class StopLimitFillTest : UserStrategyBase
    {
      DateTime _buyDate = new DateTime(2021, 7, 6);
      
        //create indicators and other objects here, this is executed prior to the main trading loop
        public override void Initialize(BarHistory bars)
        {
        }

        //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))
            {
                if (bars.DateTimes[idx] == _buyDate)
               PlaceTrade(bars, TransactionType.Buy, OrderType.Market);
            }
            else
            {            
               PlaceTrade(bars, TransactionType.Sell, OrderType.Stop, 427.75, "Stop");
                PlaceTrade(bars, TransactionType.Sell, OrderType.Limit, 431.50, "Tgt");
            //uncommented, the market order is filled even if it comes after the previous 2 orders
            //PlaceTrade(bars, TransactionType.Sell, OrderType.Market);
            }
        }
    }
}

QUOTE:
Thinking about granular processing... it won't be helpful in this case (at least not yet).

Good point Robert, I misread OP's question thinking about same-bar entries.

Eugene, this is written on your reference
"I want to test a strategy that buys and sells with stop/limit orders on the same bar.
You can't realistically backtest with stop and limit orders on the same bar as the intra-bar price dynamics is unknown. What is reliably known is that the open occurred before all the other prices and that the close occurred last."

And this does not give any answer to my question. It does not shed any light on the mechanics of WL behaviour in such a case. Random 50:50? Another random principle?

Cone, I did not understand you. You start position at Open = 433.78 and cannot reach Stop 427.75 on that day, because Low is 430.01 on July 6

Random principle is logical. But it can be 50:50 in probability terms. Or it can be M:N depending on the distances to High and Low

You'll understand if you run the example. The buy is on 7 July, but the exit is on 8 July.

Cone, ok thanks. Got you
But one guy tested it in WL6.
And the result depends on the prioriry of operators.
SellAtLimit( bar+1, p, 277.50 );
SellAtStop( bar+1, p, 275.00 );

gives different answer than
SellAtStop( bar+1, p, 275.00 );
SellAtLimit( bar+1, p, 277.50 );

Cone
and the best and logical solution is
Random rand = new Random()
...
if (rand.Next(100) <50 )
{SellAtLimit( bar+1, p, 277.50 );
SellAtStop( bar+1, p, 275.00 );}
else
{
SellAtStop( bar+1, p, 275.00 );
SellAtLimit( bar+1, p, 277.50 );}

Right, in a WL6 backtest, it's strictly the order of the operations, and your random solution would work there - but this is the wrong forum for that ;)

In WL7, It's already a random result, by logical design. We're discussing how to give users control (I prefer to see the most pessimistic result for a backtest unless I choose granular processing), but it's going to be thrown into the queue of enhancements.

We should add new Feature Requests here for proper prioritization.