Aceitação de ordens SL/TP - página 7
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
ZZY Já descrevi acima a perda de pedidos em postos anteriores, e agora gostaria de acrescentar o seguinte. O preço atingiu o ponto de partida de uma posição aberta. O servidor gerou o pedido TP-mercado correspondente e o entregou no terminal (Expert Advisors o viram). Então esta ordem de mercado TP desapareceu não só do Terminal, mas também do Servidor.
Arquitetonicamente, é assim.
A verificação pode falhar se, por exemplo, houvesse um gatilho TP de uma posição aberta, que já se encontra no estado de fechamento.
Assim, podemos ver as ordens completas atuais no terminal (elas passarão a verificação e estarão no histórico comercial (mesmo no caso de reajustes)) e as ordens fantasmas (não passarão a verificação e estarão ausentes no histórico comercial). Ambos terão seus próprios ingressos. Teoricamente, as ordens fantasmas poderiam ter os mesmos bilhetes.
Este esquema é projetado devido à arquitetura assíncrona do servidor MT5. Ela se assemelha um pouco à lógica OrderSendAsync do Terminal. É difícil dizer se o servidor envia corretamente informações sobre ordens fantasmas para o terminal antes de verificar se estão corretas.
Característica TP.
Característica TP.
Tecnicamente, não há aqui nenhuma contradição: O TP no exemplo é definido antes da ordem limite - é por isso que é executado mais cedo. O TP é executado de uma forma estranha em Ж - essa é outra questão
Se primeiro abríssemos uma posição e depois fizéssemos um pedido de TP e só depois TP - o resultado seria o mesmo - então temos muito em que pensar.
Tecnicamente, não há aqui nenhuma contradição: O TP no exemplo é definido antes da ordem limite - é por isso que é executado mais cedo. Mas o TP é executado de uma forma estranha - essa é outra questão.
Se abríssemos uma posição primeiro, depois fizéssemos uma ordem Limitada e só depois TP, o resultado seria o mesmo - então teríamos muito em que pensar.
Este exemplo é para ilustração. As conclusões não são do exemplo.
O exemplo é para fins ilustrativos. As conclusões não são do exemplo.
Portanto, faça um exemplo onde o erro é óbvio - é óbvio que, sendo todas as outras coisas iguais, não é normal se TP for executado antes da ordem limite que o precede
Então dê um exemplo onde o erro é óbvio - é óbvio que, sendo todas as outras coisas iguais, não é normal se o TP for executado antes da ordem limite que o precede
Eu não preciso de provas. A MQ sabe como funciona.
Eu não preciso de provas. A MQ está ciente de como funciona para eles.
Duvido que eles estejam cientes dos detalhes. Lembro-me de ter sido argumentado por várias páginas que não havia erro (ainda era uma prática naquela época), então (depois de várias outras páginas) eles admitiram que algo estava errado - eles decidiram investigar
E se não há um exemplo específico e inequívoco, então (na realidade de hoje) não há, portanto, motivo para investigar
E se não há um exemplo concreto e inequívoco, então (nas realidades de hoje) não há, conseqüentemente, nenhuma razão para olhar para ele.
Um exemplo nem sempre dá um motivo para lidar com isso. Os MQs simplesmente não vêem o problema, ou ele é visto como irrelevante.
Um exemplo nem sempre dá origem a um problema. Os MQs simplesmente não vêem o problema, ou ele é visto como irrelevante.
Um problema significativo é apenas se: TP falha em executar (o preço desapareceu - não há tempo) e como consequência o limite também falhará em executar
A propósito, sim, é interessante. Se um limitador pequeno estiver no mesmo nível que o TP de uma posição enorme, e esse TP for redirecionado porque é grande, o limitador não terá sequer uma chance de preencher?
Isto pode ser manipulado, acho eu.