So I am trying to figure out a problem with this simple buy code. First of all, this is a strategy that uses the zig zag and retrace points to setup an entry. Entering on a pivot from the highest low....but the problem is with the executing code.
In the charts, bar 1 is the highest low, with bar 2 completing a zigzag (pullback) based on a user defined retrace points/pips. Once that condition sets up, any bar after that should buy at low of bar 1 (also the cyan horizontal line). Here is the code:
if MP <> 0 or TT < TT then BuyBelow = 0;
if BuyBelow > 0 and BuyBelow - low >= retracepnts then Buy Size Contracts next bar at BuyBelow stop;
So BuyBelow is the low of bar 1. Fairly simple stuff. As you can see in chart 1 (current.jpg) it does not trigger like it should on bar 3, but will on the next bar. This only happens when a setup completes the zigzag and triggers the next bar....for some reason it waits one more bar. Otherwise, the code works (more than one bar after setup before a trigger).
So, I made [IntraBarOrderGeneration = true] and now it seems to work (chart 2). It buys at that pivot low, but that is not what I want for other situations. So I am stuck...maybe something to do with BarStatus, but I can't figure it out.
Hope this is not too confusing. According to my code, if the condition is true (it is after bar 2), then if it triggers bar 3 it should be no problem from my reading of the code. Again, it works fine when there are more than 1 bar after a setup. In fact I'll post a chart of that too (charts 3 (working.jpg)) to show.
from your screenshots it appears that the buy condition is fulfilled on the bar after bar 2. Without intrabar order generation the code is evaluated at the end of the bar. Then the order is send for the next bar - which seems to be what happens in the first screenshot. With IOG enabled the code can be executed intrabar and the order is send at the moment the conditions are fulfilled.
There are not too many options - either find a way to have your order send on the bar before the entry would occur (this will likely be problematic or impossible) or use IOG and make sure that the orders that you don't want to get filled intrabar will only send at the end of a bar.
The following user says Thank You to ABCTG for this post:
Thanks for your reply! I see what you are saying, but I am trying to get my brain wrapped around this. I'm not an expert at EL, but better than a newbie ;-).
My issue seems that at the close of bar 2 (in picture one), all the conditions are met (we have the highest low (bar 1) established now by the zigzag down (bar 2)), thus I can't understand why or how the code wouldn't be ready to buy the "BuyBelow" point starting at the opening of bar 3 (if it hits the trigger point). Again, this is only problematic when a highest low is established (1) by a zigzag down(2) then triggers immediately on the next bar(3)...which is about 15% of the time.
If you have any other insights, I would be greatly appreciated.....going to dig/study more on the problem
you are welcome. It's hard to tell what is going on with having only the small code snippet that doesn't give a clue about the values for all variables. However if you are using the build in zig zags or one that relies on the pivot function and using it's values, I am almost certain that it's impossible to get the low of point 2 at the close of that bar.
These functions work in a way that they only fix a swing point after a sufficient move in the opposite direction.
if it's the standard code or uses the pivot function (which the swing high, swing low and many others do, too), then there is no need for that, as you will likely receive the value with a delay. That might explain the delay you are seeing, too.
You can wrap CODE tags around code to make it easier to read, but you'd still have to copy and paste it.
you can check when the zig zag updates using market replay for example. This will show you how "late" it actually is in realtime, compared to what it looks like on a historical chart. This might give you some ideas about how to change the logic with something else. In my opinion using these functions you'll have to live with the delay. One work around would be to create your own custom zig zag that is able to detect swing points in realtime, but this might have other disadvantages (like more development time and "false" entries when you act on non confirmed swing points).
It seems I need to create a way for the zig/zag to be drawn in realtime, instead of waiting for the highest low next bar to draw it. I actually use this with pesavento patterns in Ensign that draws in realtime (zigzag lines) that I could never recreate it in TS/MC or Ninja. I assume my next step is learning more code....C#/Python? Still think there is something I am not yet thinking about.