Processamento OnTradeTransaction - página 2

Novo comentário
 
fxsaber:

Podemos ter >=2 receber e interromper pedidos ao mesmo tempo?

Sim, isso mesmo, fizemos uma entrada inicial e estabelecemos um TP e uma ordem de parada. Então, algum tempo depois poderemos ter acrescentado mais entradas e definido mais TPs e paradas.

 

No caso de um evento perdido, lembro-me das ordens colocadas, do bilhete da última negociação contabilizada, da hora do último registro (mudança) do estado, e periodicamente, assim como durante a inicial, sincronizo a lista de ordens e verifico se há negociações não contabilizadas.

A ocorrência de eventos ao acaso é a norma, a ausência de ordens (temporárias) tanto nas ordens quanto no histórico não é incomum e pode ocorrer tanto antes quanto depois de um negócio ter ocorrido.

Uma posição na netting recebe um ticket da primeira ordem e, em outras negociações (mudanças), poupa-o até que seja fechado (ou seja, torna-se 0,0).

Bem, dependendo do volume do pedido, ele pode gerar vários negócios.
 
Илья Ребенок:


Compartilhe suas experiências e idéias, por favor.

Você não está fazendo isso desde o início.

Por que os mágicos e todos os tipos de cheques?

O ticket de um pedido é um identificador único.

Se você enviar uma ordem síncrona, você receberá um bilhete como resultado da função.

Se você envia uma ordem assíncrona, recebemos o bilhete na OnTradeTransaction.

Adicionado

E aquihttps://www.mql5.com/ru/forum/67298/page2#comment_2089220

é uma boa função para verificar o pedido

ФОРТС: В помощь начинающим
ФОРТС: В помощь начинающим
  • 2015.11.25
  • www.mql5.com
Установка отложенного ордера командой OrderSend().
 
Илья Ребенок:

Sim, isso mesmo, fizemos uma entrada inicial e estabelecemos um TP e uma ordem de parada. Então, após algum tempo, poderíamos fazer uma recarga e colocar outro TP e parar os pedidos.

Ordens limitadas que requerem TP/SL poderiam ser executadas parcialmente. Ao mesmo tempo, o TP na forma de ordens limitadas será executado da mesma forma. Por exemplo, o TP é executado em um terço do volume - o SL deve ser diminuído na mesma quantidade.

Em resumo, uma lógica bastante desagradável para capturar todos os truques.


A tarefa deve ser implementada na OnTrade. Não deve ser difícil de implementar.

 
prostotrader:

Você está fazendo tudo errado desde o início.

Por que os mágicos e todos os tipos de cheques?

O ticket de um pedido é um identificador único.

Se você estiver enviando uma ordem síncrona, então o bilhete é recebido como resultado da função.

Se você envia uma ordem assíncrona, recebemos o bilhete na OnTradeTransaction.

Adicionado

E aquihttps://www.mql5.com/ru/forum/67298/page2#comment_2089220

é uma boa função para verificar o pedido

Obrigado, vou lê-lo.
JRandomTrader:

Em caso de perda de um evento, lembro-me de ter feito os pedidos, o bilhete da última transação contabilizada, a hora da última entrada (mudança) de estado, e periodicamente, assim como quando isso acontece, sincronizo a lista de pedidos e verifico se há negócios não gravados.

A ocorrência de eventos ao acaso é a norma, a ausência de ordem (temporária) tanto nas ordens quanto no histórico não é incomum e pode ocorrer tanto antes quanto depois de um acordo ter ocorrido.

A posição na netting recebe um ticket da primeira ordem e em outras operações (mudanças) ela a salva até fechar (ou seja, torna-se 0,0).

Bem, dependendo do volume do pedido, ele pode gerar múltiplos negócios.

Um dos objetivos do robô era se livrar da dependência local. Em outras palavras, ele só recebe dados do mercado sem estar vinculado às variáveis do terminal ou de um PC. Isto significa que em caso de necessidade urgente eu tenho que mudar para outro PC e o robô vai pegar tudo.

Agora eu vi outro bug interessante. Recebi 2 transações TRADE_TRANSACTION_DEAL_ADD idênticas. Desculpe, mas que diabos é isto?) O robô acabou colocando 2 paradas em 1 transação.

2019.02.08 10:55:29 [INFO]: ( PChBreak_RTS-3.19_22 ) TRADE_TRANSACTION_DEAL_ADD
TRADE_TRANSACTION_DEALDEAL_ADD
Símbolo: RTS-3.19
Bilhete de acordo: 12674810
Tipo de negócio: DEAL_TYPE_BUY
Pedido de bilhete: 82646001
Tipo de pedido: ORDER_TYPE_BUY
Estado do pedido: ORDER_STATE_STARTED
Tipo de tempo de pedido: ORDER_TIME_GTC
Validade do pedido: 1970.01.01.01 00:00
Preço: 119700
Preço de ativação: 0
Stop Loss: 0
Tirar Lucro: 0
Volume: 1
Posição: 82646001
Posição por: 0

2019.02.08 10:55:32 [INFO]: ( PChBreak_RTS-3.19_22 ) TRADE_TRANSACTION_DEAL_ADD
TRADE_TRANSACTION_DEALDEAL_ADD
Símbolo: RTS-3.19
Bilhete de acordo: 12674810
Tipo de negócio: DEAL_TYPE_BUY
Pedido de bilhete: 82646001
Tipo de pedido: ORDER_TYPE_BUY
Estado do pedido: ORDER_STATE_STARTED
Tipo de tempo de pedido: ORDER_TIME_GTC
Validade do pedido: 1970.01.01.01 00:00
Preço: 119700
Preço de ativação: 0
Stop Loss: 0
Tirar Lucro: 0
Volume: 1
Posição: 82646001
Posição por: 0

 

Os eventos de transação(TRADE_TRANSACTION_DEAL_ADDD) vêm várias vezes regularmente.

Felizmente, apenas a mais recente se repete (pelo menos eu não peguei as mais antigas).

Para filtrar é suficiente verificar se o ticket da transação é o mesmo que o anterior.

 
Ilya Baranov:

Os eventos de transação(TRADE_TRANSACTION_DEAL_ADDD) vêm várias vezes regularmente.

Felizmente, apenas a mais recente se repete (pelo menos eu não peguei as mais antigas).

Para filtrá-lo, basta verificar se o bilhete de transação é o mesmo que o anterior.

Não várias vezes, mas pelo número de EAs trabalhando atualmente no terminal.

Portanto, cada EA deve processar seu próprio pedido

case TRADE_TRANSACTION_DEAL_ADD:
      if((BuyOrder.ticket > 0) && (trans.order == BuyOrder.ticket))  // Buy order
      {
        //Сделка этого советника
      }
break;
 
prostotrader:

Não várias vezes, mas pelo número de EAs trabalhando atualmente no terminal.

Portanto, cada EA tem que processar seu próprio pedido

Seu código protege contra o fato de que se tratava de um comércio desta EA.

Eu e TS falamos de casos em que a OnTradeTransaction com o tipoTRADE_TRANSACTION_DEAL_ADD é chamada várias vezes para uma operação, ou seja, outros campos da MqlTradeTransaction contêm exatamente os mesmos dados.

Isso significa que em seu caso o código de processamento pode ser executado várias vezes.

Talvez este não seja o caso de todos os corretores. Mas isso acontece regularmente com todos os corretores com os quais trabalhei.

 
Ilya Baranov:

Seu código protege contra o fato de que se tratava de uma profissão da EA.

Eu e TS estamos falando de casos em que a OnTradeTransaction comTRADE_TRANSACTION_DEAL_ADD tipoé chamada várias vezes para uma operação, ou seja, outros campos da MqlTradeTransaction têm exatamente os mesmos dados.

Isso significa que em seu caso o código de processamento pode ser executado várias vezes.

Talvez este não seja o caso de todos os corretores. Mas isso acontece regularmente com todos os corretores com quem trabalhei.

Eu negocio na Otkryvashka em real e testei em demonstração, mas não tenho múltiplos gatilhos.

Coloque sua peça de código paraTRADE_TRANSACTION_DEAL_ADD

 
Ilya Baranov:

Os eventos de transação(TRADE_TRANSACTION_DEAL_ADDD) vêm várias vezes regularmente.

Felizmente, apenas a mais recente se repete (pelo menos eu não peguei as mais antigas).

Para filtrar, basta verificar se o ticket da transação é o mesmo que o anterior.

Sim, obrigado! Só fiz isso depois do que vi.

Quanto ao problema original, eu coloquei um deslize para ter tempo de bombear a transação de apagar um pedido e adicioná-lo ao histórico. Observado.

A imperfeição da plataforma a este respeito é muito triste. Coisas que devem ser agrupadas fazem coisas separadas.

prostotrader:

Não várias vezes, mas pelo número de EAs trabalhando no terminal no momento.

É por isso que cada EA tem que processar seu próprio pedido

Neste caso, ainda preciso armazenar o bilhete do pedido do requerente em algum lugar para compará-lo com o bilhete do ofício. E eu só quero me livrar de todo armazenamento em variáveis locais e obter informações apenas do mercado/terminal para nivelar os riscos da infra-estrutura local.
12345678910
Novo comentário
Razão: