OnTradeTransaction - página 7

 
fxsaber:

De acordo. Mas infelizmente na MT5, ao contrário da MT4, o ambiente comercial pode não corresponder à realidade. Por exemplo, quando uma ordem pendente é executada por alguns milissegundos, ela pode não estar em nenhum lugar. E aqui mesmo a OnTradeTransaction não ajudará.

Talvez, OnTrade, como eu entendo, ela seja gerada no próprio terminal já com base em transações.

Ou, você quer dizer que quando uma ordem pendente aciona no manipulador da OnTrade, nenhuma nova posição em aberto pode ser detectada?

 
Aleksey Mavrin:

Talvez a OnTrade, como eu entendo, seja gerada no próprio terminal com base em transações.

Ou você está dizendo que uma nova posição em aberto pode não ser detectada no manipulador OnTrade quando uma ordem pendente é acionada?

Em qualquer função. Neste sentido, há um buraco no MT5. É improvável que eles o remendem.

 
fxsaber:

Em qualquer função. Nesse sentido, existe um buraco no MT5. É improvável que eles o remendem.

Se assim for, é uma infelicidade. Praticamente perde o sentido da OnTrade. Teremos de verificá-lo. Idealmente, a OnTrade deveria ser chamada aproximadamente quantas vezes quando o pedido é acionado:

para paradas:

- uma ordem de mercado é criada e enviada

- a ordem pendente foi movida para a história

- a ordem foi executada, um acordo foi registrado

- a ordem de mercado foi movida para a história

- posição criada

para a ordem Limite:

- ordem limite ativada transação escrita

- A ordem pendente foi movida para a história

- posição foi criada

Assumindo a última, já deveria haver uma posição, e não as anteriores, é lógico que elas não deveriam, eh?

Chamei funções para verificar todos os estados comerciais - negociações, posições e ordens - na OnTrade. Até agora tudo parece estar funcionando bem, mas eu não tenho tido negócios muito complexos.

 
fxsaber:

Por que vim ao fórum, há tantos problemas não resolvidos))

Obrigado, vou dar uma olhada nisso. Embora eu tenha lido o destacado, não é um problema, mas uma característica. Em bancos de dados, e em geral, o conceito de transação e significa que TODOS

necessário para realizar uma consulta e manter a exatidão do banco de dados, e após a transação poder funcionar com o banco de dados, não haverá erros.

Se alguma ação (e até para escrever uma linha em qualquer tabela é às vezes necessário fazer mais de uma e garantir que as anteriores foram feitas com sucesso)

As mudanças são revertidas para trás e a transação é rejeitada. Onde eu vou com isto, provavelmente, você não deve esperar da MT o nível do SGBD :)

Aqui todas as operações intermediárias têm que ser vigiadas e verificadas, novamente em algum lugar dá mais flexibilidade.

Mas tudo me parece legal - primeiro, o servidor diz que o pedido está feito e o terminal o apaga no arquivo, depois (mais tarde) o servidor diz que abriu uma posição e pode não abrir devido a algum erro, depois deve ser zero zero zero.

Vou verificar e relatar os resultados em detalhes.

 
Aleksey Mavrin:

Mas tudo faz sentido para mim - o servidor primeiro informa que a ordem é executada, o terminal a elimina no arquivo, depois (mais tarde) o servidor informa que abriu uma posição

A ordem não está na história e não está entre as atuais. E não há nenhuma posição. Isto é, não há nada.

 
Aleksey Mavrin:

Mas tudo faz sentido para mim - o servidor primeiro informa que a ordem é executada, o terminal a apaga no arquivo, depois (mais tarde) o servidor informa que abriu uma posição, mas pode não abrir devido a algum erro, então deve ser zero zero zero.

Não posso dizer neste fórum ou em qualquer outro lugar que li os posts do administrador Renat (provavelmente fórum rápido), mas parece que ele escreveu que a única verificação que a ordem passa no servidor é para fornecer requisitos de margem, então a ordem "voa" através do conector para a troca, então a incerteza da execução da ordem, em princípio, é possível, o servidor não sabe a que preço a ordem é executada

 
Além do exemplo dado pela fxsaber, na prática há também um caso em que há um ticket tanto entre os pedidos quanto entre as posições em aberto. a situação também dura vários milissegundos (não verificado nas últimas construções, no entanto). o mecanismo de verificação deve ser diferente, portanto esteja preparado com antecedência :)
 
Igor Zakharov:
Além do exemplo dado pelo fxsaber, na prática há um caso em que há um bilhete tanto entre os pedidos quanto entre as posições em aberto. esta situação também dura vários milissegundos (não verificado nas últimas construções, porém). o mecanismo de verificação deve ser diferente, portanto prepare-se com antecedência :)

Esta situação é tratada de tal forma que para a MT4 EAs tudo permanece igual na MT5 como na MT4. Mas com ordens fantasmas - precisamos anotar isso.

 

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, eu aguentei...

Razão: