Move Stop Loss Based On Last Candle

[r2kTrader]

Hi,

I am trying to write code that will essentially move the StopLoss down to the next high or low of prior candle. So if I am short, move the stop to the high of the last candle, and if short, move the high to the low of the last candle.

Here is my starting point.

if (Position.MarketPosition == MarketPosition.Short)
{
SetStopLoss("", CalculationMode.Price, High[0], false);
}

I am not getting the behavior I expect. I don't want to set high to [1] because then the high of the last candle could have been lower than the high of current candle, then I am taken out which I don't want.

When I use the [0], I don't seem to get the behavior I expect, rather I get in the position, then right out.

I'm sure this is simple, so if anyone can help, I would appreciate it.

Also, I have tried adding BarsSinceEntry() to 1, etc.


Thanks,

[NinjaTrader_JoshP]

r2kTrader,

I guess I am not quite sure what you mean by this sentence:

"So if I am short, move the stop to the high of the last candle, and if short, move the high to the low of the last candle."

If you want to move the stop to the high of the last candle you will have to use [1]. [0] is the current candle. To address your concerns I suggest you ensure that current price is actually less than High[1] with enough distance.

[r2kTrader]

r2kTrader,

I guess I am not quite sure what you mean by this sentence:

"So if I am short, move the stop to the high of the last candle, and if short, move the high to the low of the last candle."

If you want to move the stop to the high of the last candle you will have to use [1]. [0] is the current candle. To address your concerns I suggest you ensure that current price is actually less than High[1] with enough distance.

If I have COBC = true, and I have High[0] as my price for stop, will it set it to the high of the current candle, after the first tick of the next bar?

What I am trying to do is say, "if the trade is going my way, but the signal that got me in the trade no longer applies, still stay in the trade, but move the stop down or up in conjunction with the last high or low. I want the stop to walk down or up based on the high in the case of a short, low in the case of a long".

Would this do it?

if (Position.MarketPosition == MarketPosition.Short
&& BarsSinceEntry() > 0)
{
SetStopLoss("", CalculationMode.Price, High[1], false);
}

I want the high of the current candle for this short, but only after the bar closes and IF it is lower than the last high.

My thinking is that when I enter the trade, I don't want to set a stop to the prior bar of the trade and I don't want to set the stop to the high of the entry bar, until after the bar has closed.

Thereafter, I want to only set the stop loss lower if the current bar closes with a high lower than the last stop value or bar.

The opposite of course for long trades.


Thanks,

[NinjaTrader_JoshP]

Using [0] with COBC = true means the processed bar is the last closed bar. This is NOT the last displayed bar as from a chart. There is a going to be a building bar that is not processed.

You need to be very clear exactly which bar you want to refer to then you can submit the appropriate []. Always [0] means latest in terms of what is being processed. [1] means previous.

For your conditions you just need to add them to your if-statements. Check current high vs previous high.

[r2kTrader]

Using [0] with COBC = true means the processed bar is the last closed bar. This is NOT the last displayed bar as from a chart. There is a going to be a building bar that is not processed.

You need to be very clear exactly which bar you want to refer to then you can submit the appropriate []. Always [0] means latest in terms of what is being processed. [1] means previous.

For your conditions you just need to add them to your if-statements. Check current high vs previous high.

Josh,

If I just want to start the processing of the stop after the close of the entry bar (perfectly content using the high of the entry bar to begin my process of walking down), could I set my if to check barsSinceEntry? If greater than zero, then I know my entry bar is closed???

So, I enter on say bar1 to get short. The high at time of enter was 1000.

Say we got in at 900. Whether or not the trade goes our way, I don't want the stop to be anything other than the default of x. I don't begin resetting stop until the close of the entry bar. I then want to be able to set the stop to the high of that bar, regardless of where it was at the time I entered, rather I want to set it to the close of the entry bar and then continue that pattern all the way down as long as each bar's high there after is successively lower.

Any help would be appreciated. I can't seem to get it to behave as I would like.

Thanks,

[NinjaTrader_JoshP]

Yes you can use BarsSinceEntry(). When you are > 0, the entry bar closed and you can update your stop value by calling SetStopLoss() again.

[r2kTrader]

Yes you can use BarsSinceEntry(). When you are > 0, the entry bar closed and you can update your stop value by calling SetStopLoss() again.

Josh,

My strange behavior was coming from multi-instrument issues. You have to explicity define the EntryName and you can't use the other two overloaded methods. It will never = true.

Also, as per the help:
Syntax
BarsSinceEntry()
BarsSinceEntry(string signalName)


The following method signature should be used when working with multi-time frame and instrument strategies:

BarsSinceEntry(int barsInProgressIndex, string signalName, int entriesAgo)

---
Notice in the syntax, "signalName", it should say EntryName. signalName implies you are labeling that instance (for lack of a better term).

It took me trial and error to discover that signalName should be the entryName of the position you want to test. And that was after realizing you have to use the specific signature when working in multi-time.

I hope this helps someone else.


Thanks,

[NinjaTrader_Bertrand]

r2kTrader, great you have it resolved - thanks for reporting back here.

[r2kTrader]

r2kTrader, great you have it resolved - thanks for reporting back here.

Bertrand,

Of course.

Also, check into signalName verses entryName. It is not consistent with the other signatures like ExitShortStop(), etc.

Please compare signatures and see how that could throw someone off when apply like-kind logic to the BarsSinceEntry() method. The signature description should say entryName, not signalName to be consisent with that label for other signatures, no?

This took me forever because I couldn't even really ask the right question to get help with. I don't like to post a question until I think I have narrowed down the possible reasons as to why something isn't working. I then try to strip down all the code to the bare minimum after isolating which method is causing the problem. For the life of me, it didn't occur to me to use signalName of the signature to pass the entryName. I was branching into advanced order handling and token management because I couldn't get the darn stop order to execute, lol! Not interested in going there (AOH) right now. Need to get basics down better.

Anyway, this might help someone else. I tried to explain using keywords others who run into this issue may use when searching for an answer.

Regards,

[NinjaTrader_JoshP]

Not quite following you. signalName is used throughout. entryName is not used. fromEntrySignal and signalName are two separate parameters.

[r2kTrader]

Not quite following you. signalName is used throughout. entryName is not used. fromEntrySignal and signalName are two separate parameters.

Josh,

Perhaps a bit of semantics.

Here is my point. If you look the signature for "signalName" with the other methods like ExitShortStop(), you will see they use the term signalName for the purpose of "labeling" the exit. Hence I concluded that signalName is used to label the called method if you will ?? (pardon the choice of words, probably not the best).

Anyway, when used in the context of BSE, I would assume signalName is used to "label" or "define" the instance of BSE being called. Instead, if I was referencing an "entry", it should say "entryName" in the signature description instead of "signalName".

It might be me, but it seems that we should have the same name to reference "entrySignal" as we do when firing a Stop method.

It though me for a loop and the logic paradigm didn't seem to flow consistantly.

It's minor, but major to a noob.

[NinjaTrader_JoshP]

For BarsSinceEntry(): signalName - The signal name of an entry order specified in an order entry For method. Pass in empty string "" for default signal.

Thank you for the suggestion.

[r2kTrader]

For BarsSinceEntry(): signalName - The signal name of an entry order specified in an order entry For method. Pass in empty string "" for default signal.

Thank you for the suggestion.

// signalName here implies a name for the EnterLongLimit Order
EnterLongLimit(int quantity,double stopPrice,string signalName,string fromEntrySignal)

// using the logic above in ELL, signalName would imply a "name" for the BSE instance. Yes, I know BSE doesn't "make" anything so why would it need a name, but wouldn't fromEntrySignal read better here, especially when using intellisense.
BarsSinceEntry(string signalName)

// same as ELL // Correction: signalName in proper context here.
EnterLong(string signalName)

// here we use fromEntrySignal, why not use same logic as BSE above??? Probably because fromEntrySignal is more descriptive and clear?
SetStopLoss(string fromEntrySignal, CalculationMode mode,double value,bool simulated)



Now, look at the examples above.

SetStopLoss says "fromEntrySignal", BarsSinceEntry instead says "signalName" even though they refer to same thing for the same purpose in the same way. It's not congruent.

Now look at EnterLong, "signalName" implies you use this to pass the name which will "label" this order. Whereas in BarsSinceEntry, you use the exact same signature description, but it is really saying "string fromEntrySignal"

signalName should be used in the signature to describe what you will "name/label" or whatever the object that is created. The order, or whatever.

where as fromEntrySignal should be used to tell the method what you referring to.

It is not consisent throughout the methods which are all working with entries and exits. BarsSinceEntry() is a great example as its signature is (non-overloaded I believe) is the same as EnterLong(), but in BSE version, you are referencing fromEntrySignal, whereas with EnterLong() you are naming the entrySignal.

If you apply the logic of EnterLong's sig when using BSE's method, one is lead to believe that signalName is used to name something, not receive a name.

I hope this explains it better. I am not saying you can't find the documentation as to how to use said, rather I am saying that the signatures should be consistent. signalName in the case of BSE is entirely different from when used in EnterLong(). Again, the documentation clearly states what you are to put in the signature, that is not my issue.

This is even more critical when using intellisense. Because you can only see the signature, so can you see why this is so confusing??

Also, I try to NOT USE THE F1 to get help, BECAUSE THE HELP STAYS OVER MY DANG CODE UNTIL I MANUALLY CLOSE IT AND I CAN'T EASILY TOGGLE BACK AND FORTH!! (annoying, up there with having to click "ok" after compiling and not being able to clear strategies from the strategy window withing removing each one manually (a real pain when testing because you keep hitting F5 to reload your chart, which in turn adds another strategy instance to the strategy tab. the only way to do it fast is to blow out the sim account by resetting, otherwise you spend the day right mouse clicking and removing strategies)

So again, it's about trying like hell NOT to use the help, because after "helping" you, it won't "get out of the way" gracefully.

So having a consistant label/description within signatures is important if you want to code faster. signalName is signalName and fromEntrySignal should be fromEntrySignal.

Thank you for taking the time to hear me out on this issue, I know you are busy. I just think it will pay a dividend for the next noob that comes across this. So my hope is your investment will give you a return


Thanks,,

[NinjaTrader_JoshP]

r2kTrader,

Thank you for the suggestion. We will look into it.

[r2kTrader]

r2kTrader,

Thank you for the suggestion. We will look into it.

Josh, do you agree or disagree?

Is it me, or is there something to what I am saying? I don't want to waste your time or mine in the future if this is just completely off base.

Had I not spent the time trying to correlate entrySignal and signalName in their respective contexts in relation to their usage, I would not be so concerned for the next noob. Again, the intellisense is key to avoiding the F1 button which in 6.5 is quite a nusance at times.


Thanks,