BreakEven & Trailing Profit: complete function

Forums ProRealTime English forum ProOrder support BreakEven & Trailing Profit: complete function

  • This topic has 132 replies, 23 voices, and was last updated 14 hours ago by avatarWim.
Viewing 13 posts - 121 through 133 (of 133 total)
  • #249381
    Wim

    Great snippet Roberto. But . . . am I wrong that this code still allows for a loss, even if the Trailing Stop has been in positive area already? The screen capture should help here. On the far left is the position entry, white line gives entry price, red line is initial StopLoss. The orange circle is where the Trailing Stop enters the positive area for the first time. And since the candle close is above this level, it will be a Stop order. We feel safe. But at the next step of the Trailing Stop, due to a bigger Step size, we end up above the candle close, blue circle. This time, therefore, it will be a Limit order. If price will go down from now on, we will end up at the original StopLoss! That should not happen, given that we already decided once to trail into positive area. Maybe a “set stop …”  in stead of the pending stop orders (dying at the end of the candle) would be better, it is like lifting the thin red line (original StopLoss) to the level of the thick red line in the capture.

    1 user thanked author for this post.
    #249384
    Wim

    @Roberto I found an exemple of a situation where indeed the returning of the price resulted in a loss, despite the Trailing already adjusted several times in positive area. So when flipping from Stop Order to Limit Order, I think it is necessary to adjust the level of the original StopLoss.

    1 user thanked author for this post.
    #249397

    Can you post the whole code, or the link to my snippet?

     

    #249406
    Wim

    Sure. The code is identical to your original snippet. Only the settings of StartPercentageLong etc. are modified by me, to fit with MicroGold futures.

    #249408
    Wim

    Forgot to notice: there is also the situation that the first Trailing is immediately a Limit type of order. In that case there is no previous Trailing Stop order in the positive. Do you accept that price can return to the original StopLoss, or do you “invent” a safety net at for instance halfway current close and entry price?

     

    #249442

    Replace this line:

    with this one:

    or 20, etc…

    The value 0.01 is so tiny that it raises issues in calculations.

     

     

     

     

    #249451
    Wim

    Hello @Roberto. My guess is that you checked another version than the one I attached to my post. The attached version has the following section for Trailing stop settings:

    In your original version, Il-Mio-Sistema3.itf, StepPerCent is set to 0.5 (according to the comment this means 50%). I lowered this to 0.15, not 0.01. But whatever value you enter here, this doesn’t prevent the problem I mentioned. So let’s forget about calculation issues.

    The problem is a design problem, and here follows the code that causes it:

    As long as “close >= SellPrice” you’re safe, a Stop order is issued in positive area, once Trailing has been activated of course. But … if “close < SellPrice”, and this can happen (!), the Stop order is no longer re-animated at candle end, but a Limit order is issued above current price. There is no longer a Stop order in positive area to prevent the price from falling back to the original StopLoss (the biggest loss allowed per trade).
    Sending a Limit order alone to the broker is not enough. There has to be a Stop order in positive area also. You could use the most recent Stop order. But in case the first Trailing stop is immediately a Limit order, you have to come up with another idea (half the limit value, half the close value???)
    Have another look at my last screen capture, should clarify what I am trying to express here. Afraid I wasn’t clear the first time.

    #249455

    I used the file you attached to your post.

    Anyway, I’ll check again tomorrow, but to make a thorough check, please attach again the sane ITF file you used and tell me the instrument, date and time of an incorrect trade.

     

    #249456
    Wim

    As requested, itf and another screen capture of a losing trade after activation of trailing.
    Date and time of trade: 2025-07-11 @ 17:39:00
    Instrument: MicroGold 1025, future with IB.
    The current code allows for this to happen. But I am pretty sure that this is not what you want to happen.

    #249528

    I don’t have IB, sorry. I can only test with IG and PRT.

    In any case, I will do my utmost to find where your issue may come from.

    I’ll be back to you next Monday.

     

     

    #249678

    I slightly modified the code, try this one (I am also attaching the ITF file):

     

    #249686
    Wim

    Thanks for the effort @Roberto. But I am not sure you sent the right version. This ….WW.itf is slightly different from the ….W.itf I sent you. Only some comments are modified (lines 55 and 79) and some blanks have been added in formulas to align “=”s and “*”s on consecutive lines (lines 29 and 32). And at the end all is commented out that only served for displaying levels with graphonprice commands, not affecting calculations at all. So, the results of …WW and …W are identical, problem still there.

    The problem will be there as long as the following part of the code stays the same, because when switching to Limit orders, there currently is no remaining Stop order to protect against return to negative areas.

    #249786
    Wim

    I fixed the problem @Roberto! The solution requires a variable StopIssued that has to be reset at every new position (like your Y1, y2 etc.). And next to that some code to detect whether the Limit order has been preceded by Trailing Stop Order(s) or not. If preceded by at least 1 Stop order, we retain the last Stop level as a SafetyNet. If not preceded by a Stop order, we have to invent our own SafetNet level. I have chosen to pick the level halfway tradeprice and the Limit order. The variable safetyMult (from Multiplier) allows to optimise this value if you wish. I just set it at 0.5, meaning halfway.
    For Longs the code is:

    See the 2 screen captures for both situations, Limit order preceded by Stop and immediate Limit order. The example with the preceding Stop order would have reached the original StopLoss without the SafetyNet adaptation! The .ITF is attached also.

Viewing 13 posts - 121 through 133 (of 133 total)

Create your free account now and post your request to benefit from the help of the community
Register or Login