Errors, bugs, questions - page 1781

 

Unstable performance

  • Indicator location path: \Indicators\Test_i.ex5
  • Destination path of the Expert Advisor: \Experts\Test.ex5
  • Script location path: \Scripts\Test_s.ex5

Sequence of steps: Connect the 'Test_s.ex5' script several times to the M15 chart (EURUSD symbol)

Result:

2017.02.05 15:17:59.076 OnStart 1st time attached
2017.02.05 15:18:03.293 OnStart 2nd time attached
2017.02.05 15:18:07.760 OnStart 3rd time joined
2017.02.05 15:18:07.778 OnInit
2017.02.05 15:18:07.781 OnDeinit:1
2017.02.05 15:18:16.891 OnStart 4th time joined

The results of the joins are different. They are not expected to be different, but the result is random: the line with OnInit\OnDeinit may appear from the 1st time, or from the 10th time

//Test_i.mq5 //Индикатор
void OnInit()                    { Print( __FUNCTION__ ); }
void OnDeinit( const int reason ) { Print( __FUNCTION__, ":", reason ); }
int OnCalculate( const int, const int, const int, const double& [] ) { return 0; }
//Test_s.mq5 //Скрипт
#import "..\\Experts\\Test.ex5"
        void OnInit();
#import
void OnStart()
{
        Print( __FUNCTION__ );
        OnInit();
}

Expert file attached (actually used as a library), code here https://www.mql5.com/ru/forum/1111/page1801#comment_4059227

Ошибки, баги, вопросы
Ошибки, баги, вопросы
  • www.mql5.com
Форум алго-трейдеров MQL5
Files:
Test.mq5  1 kb
 

I don't understand if the error is mine or the terminal's

At the 5th digit
void OnStart()
  {

double A=1.11111;
double B=1.11111;
double C=1.11111;

long CalcX=
NormalizeDouble(A,Digits)*MathPow(10,(Digits+1)*3-1)+
NormalizeDouble(B,Digits)*MathPow(10,(Digits+1)*2-1)+
NormalizeDouble(C,Digits)*MathPow(10,(Digits+1)*1-1);

Print ("CalcX=",CalcX);  
  }

Prints CalcX=1111111111111111111104 expected value CalcX=111111111111111111

 
A100:

Incorrect order of function calls when changing chart period

  • Indicator location path: \Indicators\Test_i.ex5
  • Path of Expert location:\Experts\Test.ex5

Sequence of Actions:

  1. Attach the Expert Advisor 'Test.ex5' to the M5 chart (symbol GBPUSD)
  2. Change the chart period to M15
  3. Change the chart period to M30
  4. Remove the Expert Advisor from the chart

Show logs. So that you can see the time frame.

It remains to add here that adding an indicator to the chart and removing an indicator from the chart are non-synchronous operations.

In addition, when the timeframe is changed, the indicator is not immediately unloaded from this timeframe. And it creates a new copy of the indicator on the new timeframe. I see your prints in the constructor-destructor, do you think that the destructor is called immediately? No, you are mistaken. The destructor is called when the indicator is unloaded, and the indicator is unloaded only in a few seconds after the indicator is deleted
 
Slawa:
Show the logs. So you can see the timing.
It remains to add that adding an indicator to a chart and removing an indicator from a chart are nonsynchronous operations.
In addition, when you change the timeframe, the indicator will not be immediately unloaded from this timeframe. And it creates a new copy of the indicator on the new timeframe. I see your prints in the constructor-destructor, do you think that the destructor is called immediately? No, you are mistaken. The destructor is called when the indicator is unloaded and the indicator is only unloaded a few seconds after removing the indicator

It is assumed that there is enough time between steps (graph period changes)

2017.02.05 19:49:49.984 I::I->M5 #step 1: join
2017.02.05 19:49:49.984 OnInit->M5

2017.02.05 19:51:39.853 I::I->M15 #step 2: period change M5 ->M15
2017.02.05 19:51:39.853 OnInit->M15
2017.02.05 19:53:29.813 OnDeinit->M15:3 #step 3: period change M15->M30
2017.02.05 19:53:29.813 I::~I->M15
2017.02.05 19:53:29.864 I::I->M30
2017.02.05 19:53:29.864 OnInit->M30

2017.02.05 19:54:03.245 OnDeinit->M30:3 #step 4: period change M30->H1
2017.02.05 19:54:03.245 I::~I->M30
2017.02.05 19:54:03.286 I::I->H1
2017.02.05 19:54:03.286 OnInit->H1
2017.02.05 19:55:02.984 I::I->H4 #step 5: H1 ->H4 period change
2017.02.02.05 19:55:02.984 OnInit->H4
2017.02.05 19:55:02.984 OnDeinit->H1:3
2017.02.05 19:55:02.984 I::~I->H1

2017.02.05 19:55:50.697 I::I->D1 #step 6: period change H4 ->D1
2017.02.05 19:55:50.697 OnInit->D1
2017.02.05 19:55:50.697 OnDeinit->H4:3
2017.02.05 19:55:50.697 I::~I->H4
2017.02.05 19:56:11.122 OnDeinit->M5:1 #step 7: delete
2017.02.05 19:56:11.122 I::~I->M5

2017.02.05 19:56:11.122 OnDeinit->D1:1
2017.02.05 19:56:11.123 I::~I->D1

The non-simultaneousness only affects different order of function calls within a step (as seen in steps #3 and #5)

As you can see, all subsequent chart period changes, except for the first (step#2:two output lines), are expected (similar to step#3:four output lines). And why should the first chart period change be different from all the others? How is it better/worse? Why did the two missing output lines from step#2(and only that one) move to step#7 (highlighted in red)?

 
-Aleks-:

I don't understand if the error is mine or the terminal's

Prints CalcX=1111111111111111111104 expected value CalcX=111111111111111111

If the number of significant decimals in double is > DBL_DIG=15, normal rules do not work
 
A100:

It is assumed that there is enough time between steps (graph period changes)

2017.02.05 19:49:49.984 I::I->M5 #step1: join
2017.02.05 19:49:49.984 OnInit->M5

2017.02.05 19:51:39.853 I::I->M15 #step 2: period change M5 ->M15
2017.02.05 19:51:39.853 OnInit->M15
2017.02.05 19:53:29.813 OnDeinit->M15:3 #step 3: period change M15->M30
2017.02.05 19:53:29.813 I::~I->M15
2017.02.05 19:53:29.864 I::I->M30
2017.02.05 19:53:29.864 OnInit->M30

2017.02.05 19:54:03.245 OnDeinit->M30:3 #step 4: period change M30->H1
2017.02.05 19:54:03.245 I::~I->M30
2017.02.05 19:54:03.286 I::I->H1
2017.02.05 19:54:03.286 OnInit->H1
2017.02.05 19:55:02.984 I::I->H4 #step 5: H1 ->H4 period change
2017.02.02.05 19:55:02.984 OnInit->H4
2017.02.05 19:55:02.984 OnDeinit->H1:3
2017.02.05 19:55:02.984 I::~I->H1

2017.02.05 19:55:50.697 I::I->D1 #step 6: H4 ->D1 period change
2017.02.05 19:55:50.697 OnInit->D1
2017.02.05 19:55:50.697 OnDeinit->H4:3
2017.02.05 19:55:50.697 I::~I->H4
2017.02.05 19:56:11.122 OnDeinit->M5:1 #step 7: delete
2017.02.05 19:56:11.122 I::~I->M5

2017.02.05 19:56:11.122 OnDeinit->D1:1
2017.02.05 19:56:11.123 I::~I->D1

Non-simultaneousness only affects different order of function calls within a step (as seen at steps #3 and #5)

As we can see, all the subsequent period changes of the chart, except for the first one (step #2), take place as expected (similar to step #3). Why should the first period change be different from all the others? How is it better/worse?

Let me try to explain again

There is some kind of indicator on the M5 chart. When you change timeframe from M5 to M15 a second copy of the same indicator is created. A command is sent to both indicators - the first one to M5 Deinit, the second one to M15 Init. At the same time, we do not know which of these commands will be executed before the other one - there is a classical race between the different threads.

After that the first indicator will have its usage counter decreased. In several seconds after the usage counter becomes zero, the indicator will be unloaded from the chart. At that destructors of global objects of this indicator will be called
 
Slawa:
Let me try to explain again

There is a certain indicator on the M5 chart. When you change timeframe from M5 to M15 a second copy of the same indicator is created. A command is sent to both indicators - the first one to M5 Deinit, the second one to M15 Init. At the same time, we do not know which of these commands will be executed before the other one - there is a classical race between the different threads.

After that the first indicator will have its usage counter decreased. In several seconds after the usage counter becomes zero, the indicator will be unloaded from the chart. The destructors of global objects of this indicator will be called

I assert (and propose to check it) that when the timeframe is changed from M5 to M15 no M5 Deinit command is sent to the first indicator (and only to it - in this case M5) and it is not unloaded from the chart until the user removes the EA

If struct I in 'Test_i.ex5' is excluded (no effect), the output is simplified:


2017.02.05 20:49:06.842 OnInit->M5

2017.02.05 20:49:21.253 OnInit->M15(*) period change M5 -> M15: M5 indicator is not unloaded
2017.02.05 20:56:40.001 OnDeinit->M15:3 period change M15 -> M30:M15 indicator is unloaded immediately
2017.02.05 20:56:40.132 OnInit->M30

More than 5 minutes have passed since (*), but the M5 indicator is not unloaded

Removing the Expert Advisor from the chart

2017.02.05 20:57:35.176 OnDeinit->M5:1 the M5 indicator is unloaded only after removing the Expert Advisor
2017.02.05 20:57:35.177 OnDeinit->M30:1

 
Slawa:
Let me try to explain again

There is a certain indicator on the M5 chart. When you change timeframe from M5 to M15, the second copy of the same indicator is created. A command is sent to both indicators - the first one to M5 Deinit, the second one to M15 Init. At the same time, we do not know which of these commands will be executed before the other one - there is a classical race between the different threads.

After that the first indicator will have its usage counter decreased. In several seconds after the usage counter becomes zero, the indicator will be unloaded from the chart. At that the destructors of global objects of this indicator will be called
Can you explain which threads we are talking about? Don't all indicators of one symbol work in one thread?
 
Vladimir Gribachev:

Glitches when installing Bill Williams indicators

I put fractals - it does

set AO - ADX is set

build 1031

Hundreds of years old bug with menu not updating when changing /MQx/Indicators directory structure :-) The bug is so old that it's already perceived as a feature, get used to it... the usability is sledgehammered with a square bolt, but the number pi counts the fastest :-)
 
A100:
If the number of significant decimal places in double > DBL_DIG=15, then normal rules do not work

Which ones work?

In the Help file it says that the maximum value for long is9223372036854775807 - I obviously don't reach it.