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

[Yedelkin]

hrenfx:

Deve ser esclarecido:

TRADE_RETCODE_PLACED for OrderSend é a resposta do servidor.

TRADE_RETCODE_PLACED for OrderSendAsync é a resposta terminal.

Embora os códigos sejam idênticos, eles têm um significado bastante diferente. É muito provável que os criadores resolvam esta ambiguidade.

É por isso que o deve compreender:

deve ser compreendido no contexto apropriado.

Então, explique em que condições o servidor deve devolver o código TRADE_RETCODE_PLACED ao enviar um pedido comercial usando a função OrderSend? Porque de acordo com o comentário da função OrderSendAsync e a resposta da Roche, este mesmo código TRADE_RETCODE_PLACED indica apenas o envio bem sucedido de um pedido do terminal para o servidor. Assim, acontece que assim que o pedido chega ao servidor e o seu processamento/cheque inicia, o servidor terá de gerar outros códigos "reais" de servidor "com base nos resultados do processamento". Então, não percebo bem porque é que o servidor (nomeadamente o servidor) deve devolver o código TRADE_RETCODE_PLACED, se este código se refere à fase de tempo de vida do pedido, antes do pedido aparecer no servidor? Ou será que o código TRADE_RETCODE_PLACED tem algum outro significado em relação à funcionalidade OrderSend?

[hrenfx]

OrderSend pode receber uma resposta tanto do servidor como do terminal (em caso de falha dos filtros do terminal).

OrderSendAsync recebe sempre resposta apenas do terminal. Para receber resposta do servidor, é necessário apanhar os eventos apropriados no onTrade.

[Yedelkin]

hrenfx:

OrderSend pode receber uma resposta tanto do servidor como do terminal (em caso de falha dos filtros do terminal).

Se compreendo correctamente a seguinte ideia:

O terminal verificou o pedido da OrderSend e enviou-o com sucesso para o servidor, com o código retcode a receber um valor intermédio de TRADE_RETCODE_PLACED. Neste ponto a ligação é interrompida e tudo o que a OrderSend pode devolver é o código TRADE_RETCODE_PLACED preso no campo retcode? Seria este o exemplo onde OrderSend devolve TRADE_RETCODE_PLACED?

[hrenfx]

Yedelkin:

Tive a seguinte ideia correcta:

O terminal verificou o pedido da OrderSend e enviou-o com sucesso para o servidor, com o retcode a receber o valor intermédio TRADE_RETCODE_PLACED. Neste ponto a ligação é interrompida e tudo o que a OrderSend pode devolver é o código TRADE_RETCODE_PLACED preso no campo retcode? Será este o exemplo quando a OrderSend devolver TRADE_RETCODE_PLACED?

Talvez, mas duvido que assim seja. Muito provavelmente seria TRADE_RETCODE_TIMEOUT via TimeOut-time para uma tal interrupção na comunicação.

Honestamente, não compreendo para que serve esta treta no caso de OrderSend. Talvez os programadores expliquem mais na ajuda.

P.S. Eu não escrevi uma única linha em MQL5. Por conseguinte, todos os meus pensamentos sobre o assunto podem ser ignorados.

[Yedelkin]

...Ainda assim, isso é um disparate. O Guia do Utilizador do Terminal do Cliente (Janeiro de 2012) diz que uma das fases da encomenda é a fase "set(placed) - dealer accepted order".

Isto é, de acordo com o manual, a ordem está a sinalizar a fase de vida de um pedido comercial, quando já chegou com sucesso ao servidor. E a descrição da função OrderSendAsync() diz exactamente o contrário: o código TRADE_RETCODE_PLACED não depende da chegada ao servidor.

[Yedelkin]

hrenfx:

Honestamente, não vejo porque é que esta nerdidade é necessária no caso de OrderSend.

Pessoalmente, gostei da ideia de precisar de "processamento de código de retorno" no meu tempo. Mas para escrever correctamente esse processamento, é preciso saber do que se trata. Há muito tempo que tento compreender exactamente a que é que o código TRADE_RETCODE_PLACED está relacionado.

[hrenfx]

Em geral, qualquer pessoa pode escrever uma série MyOrderSend via OrderSendAsync:

1. Chamado OrderSendAsync.
2. Aguardar a resposta apropriada do servidor no onTrade.
3. Exited MyOrderSend com esta resposta.

Com esta implementação, MyOrderSend será totalmente idêntico ao OrderSend normal (que pode ser simplesmente eliminado do API através da implementação via OrderSendAsync na biblioteca normal).

[Yedelkin]

hrenfx:

Com esta implementação, MyOrderSend será completamente idêntico ao OrderSend normal (que pode ser simplesmente eliminado do API implementando OrderSendAsync na biblioteca normal).

Uma ideia interessante para o auto-desenvolvimento. Mas enquanto a onTrade não estiver parametrizada, quaisquer verificações usando a onTrade na biblioteca do pessoal serão provavelmente muito mais lentas do que a própria função OrderSend. Posso estar enganado.

[hrenfx]

Geralmente, a entrada da OrderSendAsync é um acontecimento histórico para a Metatrader. Em todo o tempo o API comercial existiu (a começar pelo Metatrader3 (não vi nenhum anterior)) Metatrader, embora implementado através da sua própria língua, permaneceu praticamente inalterado na sua essência. OrderSendAsync é a primeira alteração substantiva ao API de negociação a partir de Metaquotes.

Felicito sinceramente os criadores por este evento e desejo trazer o modelo assíncrono para uma funcionalidade adequada!

[Yedelkin]

Mensagem técnica. Reunindo declarações interessantes num só fio.

Renat:

Note-se que há e haverá limites para o número de ordens simultâneas na fila de execução de uma conta. Neste momento são 16 candidaturas, se não estou enganado.

As operações assíncronas funcionarão cuidadosamente com a "janela do número de ordens admissíveis", aguardando que parte do lote anterior seja executada antes de enviar o lote seguinte. Além disso, haverá protecções contra inundações estúpidas/de teste. Até agora, é recebido um erro quando o número de pedidos permitidos transborda.

O novo método de operações assíncronas através do OrderSendAsync resolve o problema principal - permite fazer uma dúzia de operações instantaneamente. Esta é uma ferramenta muito poderosa e deve ser utilizada com cuidado e sempre com vista à possibilidade de uma proibição pelo servidor e corretor.