Erro número 6 - página 29
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
na saída da função de partida
Até 100000 sem melhoria visível
Substituído por
if(!IsTesting()) { Sleep(1000); GlobalVariableSet(stradeSemaphore, 0.0); }em
A mesma pimenta.
Erro 146.
ou seja, nós mesmos estamos esperando que nosso próprio contexto comercial seja liberado
e, em geral, esta é uma situação extremamente estranha. após conduzir uma operação comercial, o contexto é liberado instantaneamente. caso contrário, seria impossível fechar posições em um loop
Mais uma vez.
O código acima fará com que o Expert Advisor seja enforcado, se a bandeira do comércio tiver sido liberada.
Isto fará com que o comércio pare completamente, porque ninguém sinalizará o semáforo. Esta situação é pelo menos de alguma forma controlável, pois a bandeira só pode ser removida manualmente.
Pior ainda é o caso do semáforo. A GlobalVariableSet pode cair em outra EA, quando esta última fecha o semáforo. Como resultado, vários EAs tentarão negociar ao mesmo tempo.
Como vemos, os desenvolvedores não entendem que processos assíncronos acontecem no terminal. E este mal-entendido é exportado para o fórum.
Não é de se admirar que erros fatais, como o aqui discutido, ocorram e estes erros não possam ser corrigidos.
Por que dar conselhos prejudiciais?
A suposição é que se o assessor chegou a este ponto, então a bandeira comercial está de pé!
supõe-se que se a EA chegou a este ponto, então a bandeira comercial está hasteada!
Qual é a base para esta suposição? Quando as suposições não correspondem à realidade, ocorrem erros inesperados.
A bandeira não é nada.
Sincronização, mutexes, recursos compartilhados - o problema é real. É um absurdo sugerir que você resolva com variáveis globais a nível de usuário. Especialmente porque o exemplo é impraticável.
Ai de mim. "Desde as 12 horas da noite" não é uma estatística. Por razões desconhecidas, os problemas vêm em ondas, depois nenhum, depois vários ao mesmo tempo.
Eu pensei - quem se importa (tom de violinista de Kindzadz) :))
Em relação à realidade do fechamento/abertura - tenho verificações em todas as f-funções e aparecem erros, mas são erros FALSOS. Verifiquei os registros e o histórico de pedidos, todas as posições foram fechadas. A ordem simplesmente não teve tempo de se mover na história. Eu fiz um atraso de 1 segundo antes de verificar - mas isso não é suficiente... Quando perguntei, eles não me deram nenhuma resposta.
Bem visto. Mas já tive casos em que mesmo uma hora depois o pedido não foi a lugar algum, ou seja, às vezes eles não são falsos.
Eu também tenho um atraso de 10 segundos.
Todos os meus erros, como acabou, estavam no código =), ou seja, eu fiz a verificação errada após o fechamento do pedido.
Depois de corrigi-lo - não há nenhum. É verdade que não se passou muito tempo, temos que esperar...
Depois de corrigi-lo - não há nenhum. É verdade que não se passou muito tempo, teremos que esperar...
Como é o código corrigido?
para orderclaus:
//---- verificar se a posição realmente fechou e, se não, emitir a informação e sair, retornando -5 para ( int x = 0; x < 5; x ++ ) { Sleep(1000); if ( OrderSelect( Close_OrderTicket, SELECT_BY_TICKET ) ) { if ( OrderCloseTime() <= 0 ) { Processing_Error ( 0, "OrderClose" ); _Return_ ( 3, "Error", 0, "Position was not closed", "OrderClose(...)", "A posição não foi fechada" ); return(-5); } else { break; } } Close_GetLastError = GetLastError(); _Print_ ( 3, "OrderSelect( " + Close_OrderTicket + ", SELECT_BY_TICKET )", "Error #" + Close_GetLastError + " ( " + ErrorDescription( Close_GetLastError ) + " )"; }para pedidos e - apenas uma tentativa 5x de selecionar um pedido com uma segunda pausa,
para modificar - comparando os valores antigos com os valores atuais