Metatrader known bugs ... - page 5
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
strange bug in new build
I have not tested this on my own yet but one of my clients sent me an image showing that his indicator does not correctly plot lines for more than 3 days.
His version:
I have been unable to duplicate the problem.
He is on build 438 while I am on build 432.
My Version:
Robert
Been using build 445 today on a demo account
So far haven't noticed some new bugs
old bug, been there for years
There is another problem that can occur for programmers.
When you save an mqh file to the include folder you MUST use Save As and add .mqh to the filename.
Otherwise the file will be saved with .mq4.
This is a bug that should be easy to fix by metaquotes.
If a file is being saved to the include folder the default extension should be .mqh, not mq4.
Robert
In metatrader 4 editor, in file->compile it is written out that F5 is a shortcut for compilation. That is not true. F7 should be pressed for compilation, F5 does nothing in metaeditor
Been using build 445 today on a demo account So far haven't noticed some new bugs
One of my clients saw this bug in an EA I wrote for him.
There is a calculation done that allows the EA to wait for a breakout above or below a prior close.
I coded the EA to output text to the chart to show the progress.
It correctly showed the setup for a buy trade but the breakout price showed 0.0015.
This value was calculated using Close[1] + BreakOutPips * myPoint.
At another point the setup was for a Sell and showed the breakout price as -0.0015.
It appears the broker or MT4 is not correctly updating the Close array because it is returning a value of 0.
I have done EAs in the past with similar ideas and never saw this problem.
I changed the code to use iClose function and hope that will work.
Robert
Been using build 445 today on a demo account So far haven't noticed some new bugs
I have been working on a custom indicator for a client and he decided it was necessary to do all calculations at the pip level.
Part of this involves outputting lines on the chart for various price levels as well as text for the values.
I used NormalizeDouble using 2 or 4 digits for rounding at several places. The text output is correct but the lines still show 3 or 5 digit prices when the mouse is floated over them.
I wrote a stub of code to read the line values and output text showing the value to 3 or 5 digits and the values returned are correct showing a 0 for the 3rd or 5th digit and the correct rounding.
Robert
...
Interesting
I tried to reproduce that and I could not get that for any bar except that the first (oldest) bar on chart (when it behaves in exactly the same way as you described). And, contrary to what I expected Close[] and iClose() behaved the same way for that first bar (I was expecting that iClose will disregard chart and read directly from the history file, but then I found this line : "For the current chart, the information about close prices is in the predefined array named Close[]." in the help description of iClose(), so it means the all those are going to work the same way for the first bar on chart ).
Here is the code I used to test that :
#property indicator_buffers 2
#property indicator_color1 Red
#property indicator_color2 DodgerBlue
extern double DistanceInPips = 15;
extern bool UseiClose = false;
double Up[];
double Down[];
//------------------------------------------------------------------
//
//------------------------------------------------------------------
int init()
{
SetIndexBuffer(0,Up);
SetIndexBuffer(1,Down);
return(0);
}
int deinit()
{
return(0);
}
int start()
{
int counted_bars=IndicatorCounted();
if(counted_bars<0) return(-1);
if(counted_bars>0) counted_bars--;
int limit = MathMin(Bars-counted_bars,Bars-1);
double pipMultiplier = 1; if (Digits==3 || Digits==5) pipMultiplier = 10;
for(int i=limit; i>=0; i--)
{
if (UseiClose)
{
Up = iClose(NULL,0,i+1)+DistanceInPips*Point*pipMultiplier;
Down = iClose(NULL,0,i+1)-DistanceInPips*Point*pipMultiplier;
}
else
{
Up = Close+DistanceInPips*Point*pipMultiplier;
Down = Close-DistanceInPips*Point*pipMultiplier;
}
}
return(0);
}One of my clients saw this bug in an EA I wrote for him.
There is a calculation done that allows the EA to wait for a breakout above or below a prior close.
I coded the EA to output text to the chart to show the progress.
It correctly showed the setup for a buy trade but the breakout price showed 0.0015.
This value was calculated using Close[1] + BreakOutPips * myPoint.
At another point the setup was for a Sell and showed the breakout price as -0.0015.
It appears the broker or MT4 is not correctly updating the Close array because it is returning a value of 0.
I have done EAs in the past with similar ideas and never saw this problem.
I changed the code to use iClose function and hope that will work.
RobertLatest build 451 came in. So far, it is reported that MarketInfo(Symbol(),MODE_SPREAD) does not work in back-test.
Just an update : till now did not notice any "new" bugs. There was a situation when I though that it was causing an error with a dll that worked till then, but it turned out that it was my coding error in mql and not a bug, so, it seems that this version is rather stable
DoubleToString does not check to insure the value parameter is a scalar, not an array. The following code compiles cleanly. Prints as 0.000. I would assume there are a lot of other built in functions that exhibit the same error.
slope= 180./PI*MathArctan(macdup-macdup)/SlopeBars;
Create_Label("TLSf24",1,1,"Slope "+DoubleToStr(slope,3), 10, "Arial Black",Snow);Do you get the same results when the macd values are placed in local doubles?
You might also try multiplying slope by 10000 to move the decimal place before outputing the label.
Otherwise roundoff will show 0 for very small values of slope.
I worked on an EMA angle indicator years ago and that was the problem.
The angles were always very small. Even multiplying by 10000 showed angles often less than 1.
Robert