Erros, bugs, perguntas - página 2815

[A100]

Erro durante a execução:

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

• Resultado em MQL: 2
• Esperado em MQL: 1

De facto, este exemplo é executado pelas regras de C++

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

enquanto o exemplo seguinte funciona em MQL pelas suas regras (diferentes de C++)

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

• Resultado (3) em MQL: 5
• em C++: 0 (ou número aleatório)

Uma variável é considerada declarada ou

• a partir do momento em que aparece (*), ou
• desde o fim da declaração (**)

Em С++ há uma abordagem única (*), enquanto que em MQL no caso de (2) é (*), e no caso de (3) é (**). Qual é a diferença fundamental entre (2) e (3)?

Esta é a questão porque é que, num caso MQL, uma variável é considerada declarada a partir do momento em que aparece e, no outro caso, a partir do momento em que a declaração é concluída?

[A100]

Erro de compilação:

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

Caso contrário:

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

OK. Qual é a diferença entre (*) e (**)?

[Fast235]

Fast235:

Não posso carregar o histórico num terminal vazio ou num símbolo anteriormente não utilizado

Quando o corro em M1 carrega tudo, em H1 carrega ~720 barras e pronto, o indicador precisa de muito menos para funcionar, mas o carregamento de mais barras pára e o indicador não renderiza correctamente(se eu verificar cerca de 900 barras, o indicador deixa de funcionar),

.....

Anexei o guião dehttps://www.mql5.com/ru/docs/series/timeseries_access, não o quis usar durante muito tempo porque era demasiado pesado. Adicionei-o ao indicador, adicionei um par de linhas e funciona bem,

Este guião é bem desenhado e fácil de integrar num robô comercial, é um must para multi-moeda e multi-tempos! Como não carrega ou congela em função dos indicadores de trabalho,

O mesmo que se pode obter mesmo com o MA padrão, mas devido às suas peculiaridades, etc. muitas pessoas não o notarão e apenas mudarão o gráfico ou o período, e então ele recarregará...

[Andrey]

Boa tarde! O MT5 no Android 4.4 deixou de ser actualizado. Nem sequer é possível abrir a aplicação. Se alguém o tiver encontrado, ficaria grato por ajuda.

Obrigado!

[Stanislav Korotky]

fxsaber:

Podem ser obtidos através de Expert.mqh no OnTesterInit, uma vez que o Expert Advisor funcionará no modo frame para definir os parâmetros.

A chamada de EXPERT::Parametros tem o tipo de string por alguma razão. Trata-se de um insecto ou de uma restrição?

[fxsaber]

Stanislav Korotky:

Como resultado de chamar EXPERT::Parâmetros todos os parâmetros são de tipo string por alguma razão. Isto é um insecto ou uma limitação?

Um exemplo melhor.

[Vitaly Muzichenko]

Andrey:
Boa tarde! O MT5 no Android 4.4 deixou de ser actualizado. Nem sequer é possível abrir a aplicação. Se alguém tiver encontrado , ficaria grato por ajuda.

Obrigado!

O mínimo é o Android5, foi sobre isso que os criadores escreveram recentemente.

[Stanislav Korotky]

fxsaber:

Um exemplo seria melhor.

Bem, o exemplo é padrão para este método, mais ou menos:

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

Isto também pode ser visto a partir do código fonte da própria biblioteca do Expert.mqh.

PS. Transferiu a discussão para o tópico da biblioteca.

[Stanislav Korotky]

Outro bug com ParameterGetRange/ParameterSetRange.

A chamada deParameterSetRange não altera a bandeira para incluir o parâmetro na optimização para a chamada subsequente deParameterGetRange:

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

[fxsaber]

Stanislav Korotky:

Outro bug com ParameterGetRange/ParameterSetRange.

Uma chamada para ParameterSetRange não altera a bandeira para incluir o parâmetro na optimização para a chamada subsequente paraParameterGetRange:

Lembro-me que quando estava a entrar neste assunto, havia muitas nuances. Alguma coisa se mostrou certa ou errada, dependendo da função OnTester*. Tente chamá-lo em diferentes funções.