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
Você não entende nada. Quando voltamos, estamos entrando no On-funcionamento da fila gerada. Isto pode causar uma pausa que impede que o primeiro OrderSend envie o segundo correto.
Em que consiste a pausa/atraso? Na cópia de 3 estruturas?
Você propõe acumular a fila salvando todas as On-funções após o retorno, aguardando a On-função, que dirá que o primeiro OrderSend está terminado. E depois envie apenas o segundo OrderSend.
Não é necessário acumular todos os eventos. Não espere pelo próximo evento para copiar - você pode processar os eventos antes de retornar e enviar o segundo OrderSend assim que os pré-requisitos chegarem para isso
Você também não percebe que a tomada de posição pode ser executada durante a primeira OrderSend, mas sua OnTradeTransaction estará na fila mais tarde (no mesmo microssegundo, mas mais tarde) que a OnTradeTransaction final da primeira OrderSend.
E como isso o ajuda em tal situação?
bool HandleNextEvent(ENUM_EVENT_TYPE);
Será a última, tanto aqui como ali
Você não entende nada. Quando voltamos, estamos entrando no On-funcionamento da fila gerada. Isto pode causar uma pausa que impede o primeiro OrderSend de enviar o segundo correto imediatamente após o primeiro.
Você se propõe a acumular a fila salvando todas as funções On-funções após o retorno, aguardando o On-funcionamento, no qual haverá uma mensagem sobre o fim do primeiro OrderSend. E depois envie apenas o segundo OrderSend.
Ao mesmo tempo, você não entende que a tomada de posição pode ser executada durante a primeira OrderSend, mas sua OnTradeTransaction estará na fila mais tarde (no mesmo microssegundo, mas mais tarde) do que a OnTradeTransaction final da primeira OrderSend.
Não há fila de espera. O novo evento será processado após o atual, e todos os eventos que ocorreram durante este período serão ignorados.
Na minha opinião, a solução para o problema seria poder "assinar" um pedido. Ou seja, para que o terminal gere um evento quando ocorre uma transação em um pedido.
Mas isto deve ser implementado pelos desenvolvedores, não por nós. Todas as nossas soluções, de uma forma ou de outra, voltarão à história dos negócios. Eu não tenho uma criticidade tão microssegunda, mas é realmente
Mas é realmente irritante escrever bicicletas complexas para descobrir se um acordo é aprovado ou não, se os níveis são acionados ou se alguém corrigiu uma posição no terminal.
Embora parecesse uma coisa simples - um evento sobre um comércio sobre uma posição - e tudo seria muito mais fácil.
Mas cabe aos desenvolvedores implementar isto, não a nós.
Os desenvolvedores devem fornecer apenas as ferramentas. MQL é essencialmente uma linguagem de programação de baixo nível (assim como C++). Você o utiliza não em termos de tarefas, mas em termos de cálculos. E você toma todas as decisões de alto nível por conta própria. Você pode não ter ferramentas, mas não soluções prontas
Qual é o tempo de pausa? Na cópia de 3 estruturas?
No processamento de uma fila de eventos diversos.
Como isso o ajudaria em tal situação?
Será o último aqui ou ali.
Estarei ciente do fim do processo.
Não há fila de espera. O novo evento será processado após o evento atual e todos os eventos que ocorreram durante este período serão ignorados.
Incompetente.
Há vários eventos na fila a serem processados.
Estarei ciente do fechamento do tee.
Vamos parar no fato de que eu realmente (sem código comHandleNextEvent ) não entendo as coisas elementares.
Como nota final, a diferença entre oHandleNextEvent proposto e o que escrevi é que ele é via recursividade e eu o tenho através de um loop. Além disso, a fila é formada inicialmente e você pode administrá-la... você lida com alguns eventos ao mesmo tempo e os adia por algum outro tempo, você tem total liberdade.
Ao mesmo tempo, o mesmo cheque, cosido no conselheiro comercial de combate no mesmo Terminal, Alerta. Qual poderia ser a razão?
Fórum sobre comércio, sistemas automatizados de comércio e testes de estratégia comercial
MT5 e Velocidade em Ação
Anton, 2020.05.29 16:21
Roteiro para testes de tempo máximo e médio:
2474.
Tornou-se muito bom. Se você mudou - Obrigado. Vou ficar de olho no desempenho em modo de combate.
PS Em modo de combate, quando são feitos negócios, quase sempre ele se atrasa (só produz casos maiores que 5 milissegundos).
Caso contrário, parece ser muito melhor do que 2470.