Erros, bugs, perguntas - página 2107

[fxsaber]

Vladislav Andruschenko:

Concordo. temos de o mudar.

Há um ramo sobre esta regra.

[Vladislav Andruschenko]

fxsaber:

Há um ramo sobre esta regra.

sim li trechos sobre a função de acesso à história apenas quando o ambiente é alterado, e vi as suas ligações em outros tópicos.

até ao ponto, o erro apareceu depois de ler a sua opção.

[Andrey Khatimlianskii]

fxsaber:

Esta é uma lógica incorrecta. Depois de OrderSend falhar e OrderSend ser bem sucedida, o actual ambiente comercial tem de ser lido completamente de novo. Esta regra deve estar sempre em vigor.

Sobre os códigos de retorno. Não os analiso nos meus EAs. Penso que a lógica comercial não deve depender deles.

Teoricamente, pode ocorrer um timeout durante uma perda de ligação com o servidor do corretor.

Neste caso, é melhor não fazer nada até que seja restaurado e o ambiente comercial esteja totalmente sincronizado com o servidor.

Como se pode evitar entrar numa situação destas sem analisar o código de retorno?

[fxsaber]

Erro de compilação.

Ficheiro Test.mqh.

int Tmp = 1;

Código principal

#include "Test.mqh"

void OnStart()
{
  Print(Tmp);
  Print(Tmp2); // 'Tmp2' - undeclared identifier
}

#define  Tmp Tmp2
#include "Test.mqh"

Acontece que os aluviões repetidos são ignorados. Mas é errado nesta situação!

Precisamos dessa construção para os seguintes fins. Um consultor especializado está contido num ficheiro .mqh. Mas preciso de ser capaz de a executar numa conta real (primeiro incloud) e no meu testador (segundo incloud).

[fxsaber]

Andrey Khatimlianskii:

Teoricamente, um timeout pode acontecer durante uma perda de comunicação com o servidor do corretor.

Neste caso, é melhor não fazer nada até que seja restaurado e o ambiente comercial esteja totalmente sincronizado com o servidor.

Como se pode evitar entrar numa situação destas sem analisar o código de retorno?

Enviámos um OrderSend e não esperámos por uma resposta do servidor, obtendo um timeout no log e _LastError. Ignoramos _LastError e recebemos apenas falsos.

Depois disso, se tivermos uma ligação, reagrupamos o ambiente comercial e tomamos uma decisão.

Naturalmente, é sempre desejável verificar o ambiente seleccionado antes de recolher informação.

[Andrey Khatimlianskii]

fxsaber:

Enviou OrderSend e não esperou por uma resposta do servidor, obtendo um timeout no log e _LastError. Ignoramos _LastError e recebemos apenas falsos.

Depois disso, se tivermos uma ligação, reagrupamos o ambiente comercial e tomamos uma decisão.

Naturalmente, é sempre desejável verificar o ambiente seleccionado antes de recolher informação.

Isto é possível se estivermos a trabalhar com a OnTick. E se não?

Como verificar a ligação?

[fxsaber]

Andrey Khatimlianskii:

Isto funcionará se trabalhar no OnTick. E se não?

Como se verifica a ligação?

TerminalInfoInteger(TERMINAL_CONNECTED);

[Andrey Khatimlianskii]

fxsaber:

TerminalInfoInteger(TERMINAL_CONNECTED);

Historicamente, não confio nisso. Terei de o testar em 5...

[Vladislav Andruschenko]

O problema com os prazos não é que não haja ligação, mas que o pedido tenha recebido um prazo de espera.

Por um lado, vejo as coisas desta forma: há um sinal para abrir uma troca, fazemos um pedido, obtemos um timeout - mas a troca é aberta.

embora o Conselheiro Especialista tenha recebido um erro.

verificar o ambiente comercial - vemos um negócio aberto.

mas como compreender que o acordo foi aberto por este sinal? se existissem, por exemplo, 10 sinais?

ou seja, verificar se um novo negócio apareceu na história (no terminal).

ainda não compreendi a ideia

@A100

que solução vê?

[Renat Fatkhullin]

fxsaber:

Acontece que o reincódigo é ignorado. Mas isto é errado nesta situação!

Preciso de uma tal construção para a seguinte. Um Consultor Especialista está contido num ficheiro mqh-. Mas preciso de ser capaz de a executar numa conta real (primeiro incloud) e no meu testador (segundo incloud).

Tudo está correcto e é devidamente ignorado.

Os piratas não passam.