Função OrderSendAsync() - página 3

[Yedelkin]

Mensagem técnica. Reunindo declarações interessantes sobre um tópico.

sergeev:

Yedelkin:
Quais os bens da conta que serão responsáveis pelo limite de ordens simultâneas na fila de execução? Será possível descobrir esta figura programática?

o resultado da OrderSendAsync = função falsa será simplesmente

utilizá-lo como guia

[Mykola Demko]

Rosh:

Reli o fio com interesse, e até o testei na prática, e aqui descobri a discriminação gritante do comércio automático.

Aqui está o registo de fecho manual de posição: (cronologia compreensível de baixo para cima)

2012.04.26 22:32:05     Trades  '686934': deal #9256820 sell 0.02 EURUSD at 1.32391 done (based on order #10091825)
2012.04.26 22:32:05     Trades  '686934': order #10091825 sell 0.02 / 0.02 EURUSD at 1.32391 done
2012.04.26 22:32:05     Trades  '686934': accepted instant sell 0.02 EURUSD at 1.32391
2012.04.26 22:32:04     Trades  '686934': instant sell 0.02 EURUSD at 1.32391

O que vemos aqui: a ordem é enviada, a ordem é aceite, um bilhete é atribuído à ordem, e finalmente a ordem é executada (pode haver algumas mudanças na interpretação, mas é tudo). Tudo é clássico.

O único estranho é que o evento Trades sabe ao certo (dentro do terminal) por qual categoria foi desencadeado, bem como por qual ordem (para as duas últimas categorias); caso contrário, seria impossível emitir tal comentário, e o programador teria de reinventar a roda para obter esta informação. E a situação com a função OrderSendAsync não acrescentou qualquer simplicidade.

No entanto, devemos notar que a velocidade de execução da ordem aumentou. Agora não temos tempo para reparar que a ordem foi colocada na fila, e já foi executada.

---

Assim, temos um pacote de encomendas, cada uma das quais teoricamente vem 4 Trades, em cada um dos Trades precisaríamos de controlar cada encomenda.

Assim, temos 4*Número_de_ordem*Número_de_ordem pontos de controlo, ou seja, temos 400 para 10 encomendas e 40000 para 100. E Deus nos livre, qualquer ordem teria menos quantidade de Trades do que 4, então toda a lógica de controlo entra em colapso, uma vez que esperar antes de enviar uma segunda ordem (se o primeiro pedido não for executado) tem lugar exactamente no número 4.

[Andrey Dik]

Enviou uma pilha de ordens de negociação para o servidor.

Para cada encomenda, precisa de manter um controlo de execução separado? E quanto tempo esperamos por uma resposta?

[---]

joo:

Cada encomenda tem de ser controlada separadamente?

Sim

E quanto tempo tenho de esperar por uma resposta?

Varia de corretor para corretor. Se STP, é mais uma questão para o seu fornecedor de liquidez.

[Mykola Demko]

sergeev:

yeah

Não têm a mesma função para corretores diferentes. Se STP, então é mais uma questão para o seu fornecedor de liquidez.

Não, é tudo adivinhado pela borra de café. Quando se abre a janela manualmente, pressiona-se comprar, espera-se por uma requalificação ou execução, pressiona-se ok e está feito.

Quando se abre em modo automático, deve haver também um ponto de referência, a partir do qual se tem de enviar um segundo pedido ou tudo está bem.

SZS adicionado ao posto acima, reler.

[---]

Urain:

Não, é tudo adivinhação, quando se abre manualmente uma janela, se pressiona comprar, se espera por uma requalificação ou execução, se pressiona ok e já está.

Não. Este é o caso quando o código de retorno é DONE(10009).

Mas há corretores que passam a sua profissão para o fornecedor. E, neste caso, devolver-lhe-ão imediatamente PLACED(10008). E a propósito, se foi uma ordem do mercado, não haverá nenhum bilhete de negócio nesta resposta. Apenas o bilhete de encomenda.

E não haverá sequer um bilhete para a encomenda no caso da OrderSendAsync.

No modo automático, assim deve ser o ponto de referência, a partir do qual se pretende enviar um segundo pedido, ou tudo está bem.

Bem, qual é o ponto de referência para as solicitações mesmo no MT4? Não fará um loop infinito e esperará pela eliminação ou abertura de uma encomenda.

Tudo é tipo bilhete, com verificações de estados salvos, etc.

[Yedelkin]

Tentei executar a função OrderSendAsync()

//+------------------------------------------------------------------+
//|                                               OrderSendAsync.mq5 |
//+------------------------------------------------------------------+
MqlTradeResult  res={0};
MqlTradeRequest req={0};
//+------------------------------------------------------------------+
//| Script program start function                                    |
//+------------------------------------------------------------------+
void OnStart()
  {
   req.action=TRADE_ACTION_PENDING;
   req.symbol=_Symbol;
   req.volume=1.0;
   req.price=3.0;
   req.type=ORDER_TYPE_BUY_STOP;
   req.type_filling=ORDER_FILLING_RETURN;
   switch(OrderSendAsync(req,res))
     {
      case  true:
         Print("retcode=",res.retcode,", order=",res.order,", deal=",res.deal);
         break;
      default: Print("Неудача при отправке запроса функцией OrderSendAsync()");
     }
  }

Respondeu com

2012.05.02 21:12:33 OrderSendAsync (USDCHF,M1) retcode=10008, order=0, deal=0

Uma pergunta rápida surge: como planeamos seguir o destino de um pedido comercial quando este é enviado usando a função OrderSendAsync(), se nem sequer conhecemos o bilhete de encomenda? O comentário deve ser preenchido pelo corretor.

[Renat Fatkhullin]

O modo assíncrono é concebido para a entrada de encomendas de lotes a granel, mas não para uma única transacção. Para uma única transacção é melhor usar o modo síncrono - tudo será executado à mesma velocidade, e com serviço completo.

Acompanhar a execução de transacções assíncronas no OnTrade. Sim, este é um caminho mais complicado, mas é o preço da assíncronia.

[Yedelkin]

Renat:
O modo assíncrono é concebido para a entrada de encomendas de lotes a granel, mas não para uma única transacção. Para uma única transacção é melhor utilizar o modo síncrono - tudo será executado à mesma velocidade e com serviço completo.

Acompanhar a execução de transacções assíncronas no OnTrade. Sim, é uma forma mais complicada, mas esse é o preço da assincronia.

Ok, deixem-me esclarecer uma questão: como é que alguém vai seguir o destino de quinhentos pedidos comerciais num lote maciço de envio de encomendas? Uma vez que qualquer envio em massa de encomendas consiste num lote de transacções únicas, será que todos utilizarão o princípio de comparar o estado anterior e o actual da história? Não existem outras abordagens?

[Renat Fatkhullin]

A raiz do entendimento é que os processos assíncronos
1) não garante a prontidão ou mesmo a disponibilidade de resposta
2) requer claramente filas separadas de operações por parte do promotor

Por outras palavras, temos de gerar uma lista de encomendas e depois verificá-las e preenchê-las dentro da OnTrade. Isto, é claro, é excruciante.

Pela nossa parte, poderíamos, de forma transparente, manter filas assíncronas, preenchê-las com respostas e fornecer aos comerciantes funções convenientes para verificar e recuperar entradas processadas da fila. Pode verificar as filas de espera de forma assíncrona no OnTrade ou de forma síncrona através de sondagens no circuito logo após o envio de um lote de encomendas.

Pensaremos num tal mecanismo - facilitaria a vida aos criadores de EA, aliviando-os da sua rotina.