I'm using one of the community components to exit using a stop limit order. So far I've been experiencing problems when I attempt to exit on the next bar using this statement:

this.SellAtStopLimit(bar+1, LastPosition, stopLimitValue, "StopLimitOrder");

the code reference documentation seems to exit on the same bar like this:

this.SellAtStopLimit(bar, LastPosition, stopLimitValue, "StopLimitOrder");

In the later case I do not get any out of bound index errors. Does anybody here have experience in a real-time trading system with this method of exit?

In general, neither one of those functions can be used in real-time trading. They are strictly for backtesting. A note has been added to the online guide and code examples have been updated to reflect it. To avoid the exception, condition your code with a statement like in Cone's post #4 in a related discussion (click). Sorry for the inconvenience.

QUOTE:
the code reference documentation seems to exit on the same bar like this:

Thanks for pointing out an error in the documentation. Certainly this usage of a stop/limit order is a no-no as this peeks into the future.

I appreciate your response and clarification and I will modify my code as recommended, however, this is very troubling since stop limit orders are fully supported by Fidelity. It should be possible to execute a stop limit order in real time on the next bar, although I can see certain problems with backtesting. Perhaps the functionality needs to be two staged. First a stop is triggered when the price falls below the stoplimit value,followed by a limited order with some built in slippage for a more realistic simulation.

For those following this discussion I wish to confirm that modifying the for loop as follows:

CODE:
Please log in to see this code.

did in fact fix the exception error issue. I'm also hoping that it will also fix another problem that I see when charts update, that being the sudden display of the edit page. This often happens when an arbitrary time frame is selected like say 8 min. The chart will update OK for a while then stop displaying the chart and display the code edit page instead.

Upon further testing and review of the changes to the online guide I see that this will not work for real time trading so have been thinking about this and have come up with this approach to implementing a stop limit order on the next bar that I hope will work for real-time trading:

CODE:
Please log in to see this code.

So the way this works is when the condition for a stop limit exit is met the stopLimitValue is set to the stop limit value. If the low of the next bar falls below the stopLimitValue then a limit order on the same bar is triggered. If the condition is not met on the next bar the whole thing is cancelled using the stopLimit bool. The "bar > barCnt + 1" is there to prevent same day exit, where barCnt = bar; set by the buy conditional. The slippageValue is there to provide a more realistic backtest simulation. In practice Fidelity has excellent order execution and the filled order may well be at or better than the stopLimitValue,

This will not work for real-time trading because accessing "bar" by any order type except AtClose peeks into the future:

CODE:
Please log in to see this code.

You can not evaluate the bar's low (Low[bar]) and then execute an order on that same bar because that Low price only becomes known when the bar has closed i.e. at the start of the next interval. In other words, there is no way to know the "Low[bar]" until we're in "bar+1".

Please read more about this in the WealthScript Guide > Programming Trading Strategies > Peeking and in this Wiki article: The Dangers of Looking Ahead (Peeking) in Trading System Development.

I understand fully what you are saying. The way WLD is built all trade decisions are based on the close of the current bar, a legacy from when this was a EOD platform I assume. However, other platforms have a real-time method that allows you to get the "Last" price (also Bid and Ask), and with that value you can fire a limit or market order instantaneously. The last price is known since a real time bar is being printed. Is there a method that enables you to get this value? Is there a way to send a trade instantaneously without waiting for the bar to close?

If this is not doable would executing the order in the lowest 1 min time frame have any benefit?

QUOTE:
Is there a way to send a trade instantaneously without waiting for the bar to close?

I'm afraid there isn't (one exception to get the partial bar's data is GetSessionOpen but that's different story). Here's how the process works in Wealth-Lab:

Is it necessary to have access to intra-bar tick data to daytrade with Wealth-Lab?

QUOTE:
If this is not doable would executing the order in the lowest 1 min time frame have any benefit?

Yes, you probably could do that using intraday data.

I have real time tick data from Fidelity presently. My real-time algorithm runs using 2 to 8 min bars. What I dearly need are details on the methods used to update the last chart bar (partial bar) and that handle order placement. I can then program this for myself.

I also see that the ability to trigger events using partial bar data was something that was being ask for some time back if I understand what you said correctly here:
http://www.wealth-lab.com/Forum/Posts/Automated-trade-execution-on-the-Ghost-Bar-OR-scanning-multiple-timeframes-simultaneously-31010

#2

Update:

I did find this as a possible way to get the "Last Price" of the partial bar: Bars.Close.PartialValue;

If this does as I hope then have to immediately trigger a limit or Market order before the bar closes??

QUOTE:
I also see that the ability to trigger events using partial bar data was something that was being ask for some time back if I understand what you said correctly here:

I forgot about this. Glad you found this yourself. Hope this Wiki solution works for you.

QUOTE:
I did find this as a possible way to get the "Last Price" of the partial bar: Bars.Close.PartialValue;

To tell the truth, I don't remember having experimented with Close.PartialValue (or Low.PartialValue which is closer to your purpose) or not. What I know for sure is that many data providers implement the Open.PartialValue property for use with GetSessionOpen. Can't recall having programmed any support for the other .PartialValues in my data providers. At any rate, a script is not being re-evaluated during the bar (see the FAQ pointer in my post #8 above) so I'm not sure what do you mean.

QUOTE:
My real-time algorithm runs using 2 to 8 min bars.

The best you can do is place an order at 15:59 using 1-Minute bars. (1600 is too late to place an order.)

Consequently, use 1 Minute bars and Intraday scaling method (SetScaleCompressed) for indicators. The script with execute every minute, but indicators won't change during the compressed period and therefore they (by themselves) won't trigger a signal. However, you'll need to add logic to execute order(s) on the 1559 bar (or the 1259 bar for short days).

Here's an example of a 2-min strategy that assumes that you want to sell an open position 1 minute before the end of day (normally at 1559 or 1259 for short days).

Note! Requires that you have Community.Components installed for the integer time-of-day function

CODE:
Please log in to see this code.

Eugene and Cone:

Thanks for the support guys. To summarize:

QUOTE:
At any rate, a script is not being re-evaluated during the bar (see the FAQ pointer in my post #8 above) so I'm not sure what do you mean.

This is basically the nub of the whole issue. WLD does not have an OnTickUpdate Method like other real-time platforms do. So like you say Cone the best that you can do is drop down to 1 min bars as the lowest time resolution and use intraday scaling method (SetScaleCompressed) for indicators. I started the recode in this direction yesterday. And like you say the higher time frame indicators will always lag behind since that do not update during the "intra-scale" period. So to get closer to implementing a RT Stop Limit order system I'm thinking that perhaps one could project forward those higher time frame indicators using LineExtendY. Since we are only projecting forward one intra-day scale period the error between projected and actual will I hope be relatively small. So to just to give a quick example of how this might work:

You calculate a stop level at which you wish to say enter the market using an 8min timed indicator , but you wish to buy based on a limit price below the stop price. Using LineExtendY you project forward the value of the limit price using the previous two data points from the 8min time frame. Should that limit value be penetrated in the 1 min time frame you execute an AtMarket order on the open of the next 1 min bar. Clearly this hake will result in greater slippage relative to the 8min time frame, but at least the algorithm does not have to wait until the end of the 8 min period to execute an order, during which time considerable price movement could occur. I let you guys know is this idea has any merit to it.

As a quick aside are details on the method used to update the partial-bar (ghost bar) during stream update available me?

Re: ...details on the method used to update the partial-bar (ghost bar) during stream update...

Sorry, any details of the implementation are closed source.

QUOTE:
at least the algorithm does not have to wait until the end of the 8 min period to execute an order, during which time considerable price movement could occur.

I think, but I'm not sure, that this is a misunderstanding of order entry and time frames. If you use 8 minute bars, orders can be generated every 8 minutes (period), just like in the backtest. Market orders are executed immediately. Stop/limit orders remain "working" until either 1) their trigger price is hit, or, 2) the end of next 8 minute period, at which time the price is changed by the strategy or the order is canceled. A strategy cancels a stop/limit order by not placing it again.

There is no "projecting" an order price. If you want to do that, then you're trading in the wrong time frame. Nonetheless, as you said, the strategy can be modified and backtested using 8-minute compressed bars and projected prices... but that's a different strategy altogether!