Errors, bugs, questions - page 2815

[A100]

Error during execution:

class A {
public:
        A( int ) { Print( 1 ); }
        A( A&  ) { Print( 2 ); }
};
void OnStart()
{       
        int a = 5;
        {
                A a( a );         //(1)
        }
}

• Result in MQL: 2
• Expected in MQL: 1

In fact, this example is executed by C++ rules

void OnStart()
{
        int a = 5;
        {
                A a( a );         //(2)
        }
}

while the following example works in MQL by its (different from C++) rules

void OnStart()
{       
        int a = 5;
        {
                int a = a;         //(3)
                printf( "%d", a );
        }
}

• Result (3) in MQL: 5
• in C++: 0 (or random number)

A variable is considered declared either

• from the moment of appearing (*), or
• since the end of the declaration (**)

In С++ there is a single (*) approach, while in MQL in case of (2) it is (*), and in case of (3) it is (**). What is the fundamental difference between (2) and (3)?

This is the question why in MQL in one case a variable is considered declared from the moment of appearing and in the other case from the moment when declaration is finished?

[A100]

Compilation error:

#import "z.ex5"
#import
#define  MACRO1( x )    (x) //(*)
#define  MACRO2( x )    MACRO1(x)
int f( int z )
{
        return MACRO2( z ); //Error: '()' - operand expected
}

Otherwise:

#define  MACRO1( x )    x  //(**)

OK. What's the difference between (*) and (**)?

[Fast235]

Fast235:

I can't load the history in an empty terminal or in a previously unused symbol

When I run it on M1 it loads everything, on H1 it loads ~720 bars and that's it, the indicator needs much less to work, but loading of further bars stops and the indicator does not render correctly(if I check for about 900 bars, the indicator stops working at all),

.....

I have attached the script fromhttps://www.mql5.com/ru/docs/series/timeseries_access, I didn't want to use it for a long time because it was too cumbersome. I added it to the indicator, added a couple of lines and it works fine,

This script is well-designed and easy to integrate into a trading robot, it is a must for multicurrency and multitime timeframes! As it does not load or freeze depending on the working indicators,

The same thing you can get even with standard MA, but because of its peculiarities etc. many people will not notice it and just change the chart or period, and then it will reload...

[Andrey]

Good afternoon ! MT5 on Android 4.4 has stopped updating. Can't even open the app. If anyone has encountered it , I would be grateful for help.

Thank you!

[Stanislav Korotky]

fxsaber:

They can be obtained through Expert.mqh in OnTesterInit, as the Expert Advisor will run in the frame mode to set the parameters.

The call of EXPERT::Parameters has the string type for some reason. Is this a bug or a restriction?

[fxsaber]

Stanislav Korotky:

As a result of calling EXPERT::Parameters all parameters are of type string for some reason. Is this a bug or a limitation?

A better example.

[Vitaly Muzichenko]

Andrey:
Good afternoon ! MT5 on Android 4.4 has stopped updating. Can't even open the app. If anyone has encountered , would be grateful for help.

Thank you!

The minimum is Android5, that's what the developers wrote about recently.

[Stanislav Korotky]

fxsaber:

An example would be better.

Well the example is standard for this method, sort of:

    EXPERT::Parameters(0, parameters, names);
    for(int i = 0; i < ArraySize(parameters); i++)
    // здесь parameters[i].type всегда равно TYPE_STRING, вне зависимости от фактического типа параметра

This can also be seen from the source code of the Expert.mqh library itself.

PS. Moved the discussion to the library topic.

[Stanislav Korotky]

Another bug with ParameterGetRange/ParameterSetRange.

CallingParameterSetRange does not change the flag to include the parameter in the optimisation for the subsequentParameterGetRange call:

// параметр "name" изначально включен в оптимизацию
// в одной части кода...
ParameterSetRange("name", false, value, start, step, stop);
...
// в другой части кода финализация проверок
ParameterGetRange("name", enabled, value, start, step, stop); // получаем enabled=true, т.е. изменения внесенные ParameterSetRange не применились

[fxsaber]

Stanislav Korotky:

Another bug with ParameterGetRange/ParameterSetRange.

A call to ParameterSetRange does not change the flag to include the parameter in the optimization for the subsequent call toParameterGetRange:

I remember when I was getting into this subject, there were a lot of nuances. Something showed right or wrong, depending on the OnTester* function. Try to call it in different On-functions.