Hi All,

Does anyone know how Wealth Lab evaluates its limit orders?

Are they evaluated before control is passed to my execute method of after?

I am updating my limit orders on every iteration of a bar while my position is open (IsLastPostionOpen == true):

CODE:
Please log in to see this code.

However I believe I am being stopped out a bar later than expected.

Has anyone experienced this?

Wealth-Lab evaluates each order as described in the online manuals. Unexpected behavior might be a sign of a somewhat incorrect script construction, but not enough details are provided to decide (i.e. just two lines of code which uses bar instead of bar+1 for some reason).

CODE:
Please log in to see this code.

The orders are evaluated on the bar that you pass the signal. You must expect that!

However, I can see from your code snippet that you are not creating orders the correct way. You should create orders for the next bar (bar + 1) based on prices that have closed on the current bar. In other words, the snippet should be written (probably) like this:

CODE:
Please log in to see this code.

The result should be [approximately] the same, however, now the code will correctly alert.

I think iam facing abit of a dilema.

QUOTE:

You should create orders for the next bar (bar + 1) based on prices that have closed on the current bar.

I agree that with backtesting, if the signal bar is defined on the close of that bar, and i enter at the next bar's open for instance.
However, i think iam trying to accomplish something else.
lets assume an ohlc time series. lets place keltern channels around them. I am constantly offered on the upper band, and bid on the lower band.
If the high of a current bar is > than the upper keltner channel[-1], i can safely assume that my limit order to go short (current bar) has been triggered. So i go short at the upper keltner channel value which is keltner[-1]. (The [-1] is because the last stable keltner value is generated on the prior bar's close).

So i enter at the current bar (at limit price), based on a value generated by the previous bar's closing value, [-1].

(jcranwellward and akardar1 are used interchangeably here, apologies for any confusion)

You're not trying to do something else, you're just trying to do it the wrong way. First the standard explanation: Bars, Loops, and Bar + 1

Just think about how you trade in real life. The bar interval closes, the indicators are calculated and you place the bid and offer orders. These are based on the most-recent OHLC bar information, but the orders are live for the next bar, i.e., bar + 1.

When trading live "the next bar" is the one that is currently forming. We call it the "ghost bar". If the ghost bar crosses your order, the order would be filled by the broker. However, you don't see it in the chart yet because the script only processes complete bars. When the interval closes and the bar is added to the chart, the fill will show on the chart when the script executes again.

Hope this helps.

This makes sense, thanks for this.
We use the current bar to generate orders for the next bar (ghost bar).
This works fine with entries.

With the exits, where I exit during a ghost bar on a limit order generated from an moving average (so defined by the previous bar's close), using your:

CODE:
Please log in to see this code.

doesnt seem to "get me out" on the correct bar.
Your document says:

QUOTE:

hough this discussion should be enough to convince you to use bar + 1 in trading signals (exceptions may exist)

I wonder whether this is one of the exceptions ?

CODE:
Please log in to see this code.

I'm quite sure it works properly, so if you can produce a complete script (as small as possible) and identify a symbol/scale that would demonstrate your doubts, then we can go through it in detail.

It's possible to construct a script in a way that distorts normal operation. Just show your code to prove/disprove.

Ok to continue via a support ticket so I can send sample data too ?

It would be much better if you can provide a stripped down version of your script demonstrating the issue.

Sure, but do you need to look at the same data ohlc series as me ?

If we determine that the problem could somehow be connected to the data/provider you're using, then it would make sense.

Thanks, sending with detail in ticket