Posts made by james

OK. I'll re-edit the EA with local build 054 and then run it on a live feed again to test. I'll get back to you if I encounter the issue again.

Thank you so much for your full reply. If I was more conversant with what goes on behind MT4 and the brokers I'm sure I'd have understood it in detail. As it is, I think - hope - I get the idea.

I was aware I'd made a mistake in http://fxdreema.com/shared/0uYNJ9m3c, so amended it in http://fxdreema.com/shared/6yxLH5G9c, which I hope is correct. But I'm sure you'll keep me right if not!

Also I'm not trying to scalp, unless my interpretation of scalping is wrong! I'm trying to place a stop at the 55 day EMA level, which, on average on the S&P500 is always something like 30 pips away from the current price at the points when I place a trade.

Therefore I do understand that fxDreema will now check the stop is acceptable, and if not change it to the minimum allowed by the broker - which is great! - thank you. But I'm not sure if local build 054 answers my original query. Maybe it does.

As far as I can see, and looking at http://fxdreema.com/shared/6yxLH5G9c, block 5 "Set BuySL" places the price level of the 55 day EMA in the variable "BuySL"; then block 3 "Buy now" uses that value to place a "Dynamic level (price input)" stop loss at the price currently held in variable "BuySL".

In the MetaTrader Tester this all works fine, and places my stops at the 55 day EMA, which is, as I say, always around 30 pips away on trading.

This placing of the stop at the 30 pip, 55 day EMA price level was the bit which seemed not to be working in the live environment. Have I got this wrong? Does local build 054 fix this?

Yes, I think the web version produces something similar. Journal log says:
__15:00:32 '58032744': instant order buy 10.37 US500.U at 1687.25 sl: 1668.44 tp: 0.00
15:00:33 '58032744': order buy 10.37 US500.U opening at 1687.25 sl: 1668.44 tp: 0.00 failed [Invalid S/L or T/P]
15:00:33 '58032744': instant order buy 10.37 US500.U at 1687.25 sl: 1668.44 tp: 0.00
15:00:33 '58032744': order buy 10.37 US500.U opening at 1687.25 sl: 1668.44 tp: 0.00 failed [Invalid S/L or T/P]
15:00:33 '58032744': instant order buy 10.37 US500.U at 1687.25 sl: 1668.44 tp: 0.00
15:00:33 '58032744': order buy 10.37 US500.U opening at 1687.25 sl: 1668.44 tp: 0.00 failed [Invalid S/L or T/P]
etc.[/quote:31u5kg1w]
Experts log says:
__15:00:33 US500 TrendFollow 2PointFormat type 2 v2 web US500.U,H4: New trade error: Invalid Sl or TP (130). Retrying..
15:00:33 US500 TrendFollow 2PointFormat type 2 v2 web US500.U,H4: New trade error: Invalid Sl or TP (130). Retrying..
15:00:33 US500 TrendFollow 2PointFormat type 2 v2 web US500.U,H4: New trade error: Invalid Sl or TP (130). Retrying..
etc.[/quote:31u5kg1w]
The problem seems to be that the EA's instruction to place the stop at a given price (in this case the 55 day EMA level) is misunderstood by the broker's server. Even using the method I adopted of saving the SL price into the variable BuySL does not seem to get around the issue.

Incidentally, I've also tried using a formula block, (candle low(1) - EMA 55 candle close(1)) store in variable BuySLPips, and using BuySLPips in fixed pips mode for the stop loss in the "Buy now" block.

As I say, this doesn't seem to be a problem in the tester.

I have re-created the EA from the web version, and am now running it live. Will let you know as soon as it does anything.

Heck! More of my mistakes!

Error in my "Buy now" block. Here's the link with a refreshed setup:

http://fxdreema.com/shared/6yxLH5G9c

Oops! Forgot to say (again!) I'm on local build v053.

Sorry. Me again!

This time I'm experiencing a problem with placing and modifying a stop loss on a live feed. I've tried several methods, but keep getting an error. The most recent error is:
__Alert: Modify error: Array index is out of range (4002)[/quote:dg7otuwc]
I'm trying to place a stop loss below a buy at the 55 day EMA, and then run it as a trailing stop. This all seems to work fine in the tester, but not on the live feed.

See here: http://fxdreema.com/shared/0uYNJ9m3c

Should this work? Or is it me doing something wrong?

Sorry. Forgot to say, local build v053. Maybe you already uploaded the fix.

I'm having difficulty with the "Indicator fall" block. When I use it I get the following compilation error in MetaEditor:
__'RiseCandles' - variable not defined C:\MetaTrader 4\experts\a quick data run.mq4 (666, 13)
[/quote:qkeoe0i3]
The compilation works for the block if it isn't attached to any other block, but as soon as it is, the above error seems to appear.

Help!

OK. Thanks. I'll bear those tips in mind.

True - but your English is really excellent! Better than many of my fellow Scots!

The initial project was started several months ago; 3 or 4 I think. I didn't keep a log, so I'm relying on memory - not always good with me! However, I think I began noticing block numbering jumping from the 90's to maybe the 200's, then up to 400's and 600's, then another jump to the thousands, and just in the last day or so, the hundreds of thousands.

Maybe the thing you are missing in attempting to replicate is copying and re-importing {project_name}.mq4 files.

This happens in two instances:

ONE: When you produce a new local version. Rather than over-installing it, I put each one in its own sub-directory. I mentioned this a little while ago in an earlier posting. Therefore I have, on my disc:

*C:\fxdreema_037
C:\fxdreema_044
C:\fxdreema_047
C:\fxdreema_048
C:\fxdreema_052
C:\fxdreema_053[/list:u:r0o5j2ld]

All my projects are stored in C:\MetaTrader 4\experts, regardless of which version created them originally.

So, when you release a new local version, I install it as above, and then do a "Load project from file" within the new version. Thus the {project_name}.mq4 file arrives in the database of the new local version.

TWO: When I want to move a project on to another version, preserving an older version as a {project_name}.mq4 file, I copy it thus on the hard disc:

*{project_name_v1}.mq4
{project_name_v2}.mq4
{project_name_v3}.mq4
etc.[/list:u:r0o5j2ld]

Then I import the newest version into fxDreema using "Load project from file". I might do this several times. So far I seem to have gone up to 9.

Maybe this importing of the .mq4 file is the missing link with which you'll be able to replicate the issue.

I'm glad you like the idea of a blocks re-numbering routine! I did have one further thought just to mention on this - and I'm sure you've already thought of it, but here goes, just in case! - I have a couple of "Turn ON/OFF" another block blocks, and somehow this would need to be picked up by a re-numbering routine. As I say, I'm sure you are ahead of me on this!

Many thanks.

Aah, got it now!

But, I think that the terminology used in the block is confusing. "Undefined" might be "Any method", and "Manually / Automatic" might be "All except TP & SL".

It might also be a good idea to include a "hint" mouse-over pop-up over the "Closed by" field label explaining this.

I have 108 blocks in my EA. I've been doing quite a bit of editing on it, and have let the block numbering take care of itself.

The lowest numbered block currently is 13, and the highest is now up at 260243 - although I'm sure I haven't done that many edits!

Oddly, when I click on it to edit, I see this:

The last 2 digits seem to be missing.

This isn't really causing me too much trouble just now, but I did wonder, would you be able to produce an automatic re-numbering option in fxDreema, just in case it ever did?

Thanks again.

......
Clipboard02.jpg
Clipboard03.jpg

I'm having a problem when using the "On trade" blocks in local build 053.

I have the "Buy now" and "Sell now" block "Group #" fields set at empty.

In the "On trade" block in the "On trade" event page I have to set the "Closed by" to "Undefined" for the block to pick these trades up, as in this picture:

I'm wondering if this is correct, as I'd have thought the right setting for "Closed by" in this circumstance should be "Manually/Automatic" so that no trades are missed.

The reason for me asking earlier today for an update on the fixes in 053 was because I thought this might have been included, and I didn't want to waste your time with this query if it was!

Many thanks, as always.

......
Clipboard02.jpg

Could you update the Version History on the web site, please? I'd just like to know what's changed before I move on.
Thanks.

Hey! What can I say, except thank you! Brilliant! That seems to do the job nicely. FxDreema just goes on improving!

You'll see from the following picture, that a setting of block "indicator is visible" candle ID 1, and 3 additional candles, with exception of 2 candles, produces the expected result (the brown line is the "logic points tester" block):

The three candles at the right are ignored in the overall bullish trend.

In the next picture, where exception of only 1 candle is used, the result correctly shows this (again, the brown line is the "logic points tester" block):

One red candle is ignored, but two are not, and the trend is considered incomplete.

Thank you again!

......
Clipboard02.jpg
Clipboard05.jpg

Many thanks for the update on the "Indicator moves within limits" block!

OK. So for my item numbered 1 above, "making the "Indicator is visible" block allow for a number of contra trend signals to appear", consider the following:

*Close[0]>MA[0]
Close[1]<MA[1]
Close[2]>MA[2]
Close[3]>MA[3]
Close[4]>MA[4]
Close[5]>MA[5]
[/list:u:12zx6jot]

You'll notice straight away that although the trend is bullish, there is one contra indicator. However, we still want to accept this as a bullish trend. This is the same principle as using the indicator with blue and red bars (see mine of Wed Aug 28, 2013 11:09 pm).

The block needs what I called a "fuzziness" factor. In the picture below of the "Indicator is visible" block, I've added a field called "Contra indicator" which would allow the entry of a number of reverse trend candles to be ignored, or 0 for no contra indications.

*[/list:u:12zx6jot]

This "fuzziness" factor would probably be useful in the "Indicator rise" and "Indicator fall" blocks also.

Does this make sense? What do you think? Good idea, or bad idea?

(By the way - and its very minor! - you'll notice from the picture of the block that the X at the top left corner is partially obscured. This seems to happen in a few blocks. It isn't a problem, though! )

......
Clipboard01.jpg

__I thought you want to check if Close is above MA, but for every candle - Close[0]>MA[0] and Close[1]>MA[1] and Close[2]>MA[2]... which is still possible, but with multiple blocks... It's not beautiful I like that concept [/quote:3vxe94p6]
Yes. This is the thought behind my number 2 item. But isn't this achievable by using the "Indicator moves within limits" block?

__Number 1 - what if you use indicator with bigger period. I think you want to filter those situations where the price goes back and returns back quickly.[/quote:3vxe94p6]
Not quite. Its about making the "Indicator is visible" block allow for a number of contra trend signals to appear. Therefore in my picture of blue and red bars, the overall trend is blue, but there are a few random red bars.

You are, of course, right - as always! - about my number 2 item above (my post of Wed Aug 28, 2013 11:09 pm).

Using the "Indicator moves within limits" block, its quite easy to do a "pass if the close price of the last n candles is above moving average y". So we can forget about number 2! Sorry!

I'll get back to you about number 1 after I've given it some more thought.