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
Em robôs "normais", o caso que descrevi, não notei nada; mas em um caso me pediram para fazer um sistema de segurança: a condição era que as posições fossem sempre bloqueadas (seja com posições reais ou com uma ordem pendente), ou seja, o número de lotes de compra é igual ao número de lotes de venda. Este é o caso que me introduziu às nuances de ordem/posição/contagem de comércio em uma nota de cinco.
A diferença, como expliquei a mim mesmo :) é que os quatro, ao receber uma resposta do corretor, primeiro sincronizam suas "tabelas" com os pedidos abertos e o histórico, e depois informam o usuário sobre a resposta do corretor. Os cinco imediatamente nos transmitem esta resposta, e ao mesmo tempo corrigem suas "tabelas" (e todos os programas mql lêem dados destas "tabelas"). Este é o momento em que pegamos no timer de milissegundos. Mas então, por que não o apanhamos no testador?
Em geral, fiz a minha paz de espírito...
Não, as coisas estão piores.
A ordem no momento da transformação de uma ordem pendente (ou de mercado) em uma ordem histórica (executada ou cancelada), ela desaparece completamente do terminal por algum tempo. Ela não aparece nem entre os mercados pendentes (ou "iniciados"), nem entre os históricos.
Portanto, não se trata de uma questão de execução, mas de sincronização destas duas tabelas. A resposta do servidor veio ("Order executed, generated transaction so-and-so"), ela é removida de uma tabela, mas não é inserida na outra.
Não, as coisas estão piores.
Quando uma ordem muda de uma ordem pendente (ou de mercado) para uma ordem histórica (executada ou cancelada), ela desaparece completamente do terminal por algum tempo. Ela não aparece nem entre os mercados pendentes (ou "iniciados"), nem entre os históricos.
Portanto, não se trata de uma questão de execução, mas de sincronização destas duas tabelas. A resposta veio do servidor ("Ordem executada, acionou a transação mais ou menos") e é excluída de uma tabela mas não inserida na outra.
É interessante verificar.Igor Makanu me intrigou com a tarefahttps://www.mql5.com/ru/forum/6343/page1097#comment_12518742
Fiz a primeira aproximação no meu joelho. Depois farei algumasestatísticas sobre a operação OnOrder e OnOrderTransaction e o estado do ambiente comercial e, se eu não for muito preguiçoso, posso colocá-lo para teste de demonstração para ver o que está acontecendo em diferentes contas/corretores.
então, será possível analisar. Suposições feitas até agora: 1. nenhuma execução parcial é verificada e as peculiaridades da conta não são verificadas; enviei uma ordem de mercado, a posição aberta é lembrada, espero que a transação seja aberta no diário e a abro novamente na direção oposta. 2. Idealmente, uma determinada transação deveria ser capturada na OnOrderTransaction, mas até agora eu a fiz desta maneira - em ambos os casos, eu verifico tudo da mesma maneira.
Naturalmente, o código não é o ideal. Eu já posso ver onde as posições de pedidos serão perdidas se tudo for tão ruim quanto descrito no post acima.
Isto é interessante de conferir.Igor Makanu me intriga com a tarefa https://www.mql5.com/ru/forum/6343/page1097#comment_12518742
Fez uma primeira aproximação no joelho.
Esta demonstração é melhor para ver.ForexTimeFXTM-Demo01
Eu não notei o caso que descrevi em robôs comerciais "normais".
Qualquer biblioteca comercial pode e deve ser verificada para verificar a abundância, usando testes de estresse em várias contas de demonstração. Deve passar tudo sem nenhum impedimento.
Bem, para que isso aconteça, o autor tem que se familiarizar pessoalmente com as piadas do MT5. Em minha prática, descobri que mesmo isto não é suficiente.
Há algumas coisas muito específicas que não foram detectadas pelo terrível spamming das encomendas para os servidores comerciais. Graças ao feedback, foi possível encontrar um comportamento bastante estranho que nem mesmo os próprios desenvolvedores parecem perceber.
houve uma solução na discussãohttps://www.mql5.com/ru/forum/6343/page1098#comment_12519819, parte da discussão foi eliminada (((
Existe uma solução no ramo de MT4Orders. Mas você mesmo tem que sentir cada ancinho ;)
Isso mesmo, o ancinho é sempre interessante, e então veja como os profissionais o fizeram. A soluçãofxsaber é brilhante em sua concisão, mas vejo um senão nessa solução em uma coisa - os manuais dizem que o bilhete de posição é EXATAMENTE o bilhete da ordem aberta, mas NÃO TUDO.
Na minha solução, eu estava procedendo a partir disso.
Qualquer biblioteca de negociação pode e deve ser verificada quanto a perspicácia através de testes de estresse em várias contas de demonstração. Deve passar tudo sem nenhum impedimento.
Usei 200ms para os testes e quando o devolvi, o homem o fixou em 5ms. Aos cinco, funcionou quase sempre, de qualquer forma.
Não sei se é importante, mas eles usaram o winapi timeBeginPeriod(1), ou seja, abaixo do padrão de 20ms tudo aconteceu
o bilhete de posição GERALMENTE o bilhete de ordem de abertura, mas NÃO SEMPRE.
Não me lembro muito bem, mas parece ser sempre.
Não me lembro muito bem disso, mas acho que sempre esteve presente.
Sim, você está certo, pois neste caso é um identificador de posição, constante ao longo de sua vida. Confundi-o com o ticker de posição, que muda durante os rollovers e as redes.
Mas eu não entendo - quando uma posição é parcialmente fechada, o bilhete não muda para o bilhete da última ordem que afeta a posição?
Vou rever meus códigos, obrigado. Eu visitei o fórum não por nada)
Quanto à "ordem perdida" que não está na lista de ordens atuais ou históricas: Parece-me que não se trata de um bug, só preciso olhar cuidadosamente as características de
Acho que isto não é um bug, basta olhar com cuidado as peculiaridades do mercado de MT-servidor de terminais (no caso de execução instantânea o mercado não funciona). Acho que sim, veja - o terminal envia uma ordem de mercado, no caso de função síncrona - ele espera e recebe uma resposta do servidor,
Se não houver erro, a resposta pode ser apenas TRADE_RETCODE_DONE (no caso de execução instantânea, são requerimentos, mas até agora é o tipo de mercado), o que significa essencialmente que o servidor enviou a ordem para o mercado e ele
Na verdade, isso significa que o servidor enviou o pedido e espera por sua resposta. O estado do pedido neste momento éORDER_STATE_STARTED se eu não estiver enganado e seu bilhete for conhecido. Se o pedido for executado, o servidor envia a OnTradeTransaction ao terminal e o status do pedido muda para ORDER_STATE_FILLED e o comércio é conhecido
e a posição se torna conhecida. É somente neste ponto que o terminal registra a ordem na história. Não o faz de antemão, pois não temos certeza do que aconteceu com ele e já deu a resposta inicial do servidor.
Este é o tempo até que a ordem seja executada na rede ECN ou em outro lugar, eles não estão em nenhuma das duas listas. Isto é, no caso da ordem de mercado, ela só aparece na história (não tenho certeza sobre o caso das solicitações durante a execução imediata),
nunca aparecerá na lista de abertos. E quando uma ordem pendente é acionada, ela é removida da lista das abertas porque já se tornou uma ordem de mercado e esperamos que o servidor de mercado responda, e então ela é enviada para a história.
Eu estou certo?