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

[Denis Kirichenko]

Urain:

Se a sua proposta apenas complementaria uma função existente, então nada, senão não é claro como uma simples estrutura MqlPacketTradeRequest ...

... Se a estrutura MqlPacketTradeRequest for a estrutura do conjunto dinâmico de estruturas MqlTradeRequest, pode quebrar toda a lógica do servidor inundado com estruturas de consulta simples.

Caso contrário, a nível terminal, teríamos de dividir este pacote em pedidos separados, o que negaria todo o objectivo de introduzir esta sobrecarga.

Parece que "concordámos" com uma tal variante devido à estrutura assíncrona:

bool  OrderSendAsync(
   MqlPacketTradeRequest&  packet_request,      // пакетная структура запроса
   );

Onde,

pacote_request incluirá entre outras coisas um conjunto de estruturas MqlTradeRequest...

Então todos estes pensamentos são matéria prima para discussão :-)

[Yedelkin]

Urain:

IMHO um lote de aplicações idênticas é necessário apenas para fins de demonstração, para aplicações de trabalho de símbolos diferentes, com volumes diferentes e, claro, serão utilizadas direcções diferentes. E, portanto, cada pedido terá de ser verificado separadamente, pelo que não vale a pena enviá-los num lote.

Bem, tem de escolher aqui: início único da função OrderSendPacketAsync(MqTradeRequest& request[], MqlPacketTradeResult& packet_result) que envia um pedido de matriz pré-preenchido[] de 500 elementos de cada vez com verificação única de código de retorno 10008, ou 500 vezes iniciando a função OrderSendAsync() com 500 vezes verificando o código de retorno 10008.

[Yedelkin]

Urain:

...se a estrutura MqlPacketTradeRequest é a estrutura do conjunto dinâmico de estruturas MqlTradeRequest, pode quebrar toda a lógica de servidor que foi concebida para estruturas de consulta simples.

Como pode um pedido comercial usando uma matriz dinâmica "quebrar a lógica do servidor"? Se tenho um bloco, que processa uma variável de um determinado tipo de estrutura, então o que me impede de aplicar este bloco a cada elemento de um conjunto do mesmo tipo? Do mesmo modo, se hoje em dia um servidor está "orientado para estruturas de consulta simples", o que me impede de adicionar um loop, que quando um servidor aceita um array dinâmico enviado pela função OrderSendPacketAsync(), permitirá aplicar por sua vez um bloco "orientado para estruturas de consulta simples" a cada elemento de tal array?

[Yedelkin]

papaklass:

Na minha opinião, a função OrderSendAsync() deveria ser paramétrica em vez de criar um laço para o envio de encomendas. Por exemplo OrderSendAsync(Símbolo(), número, direcção). Como parâmetros: - símbolo, - númerode encomendas, - direcção das encomendas (compra, venda).

Isto é semelhante a um caso especial de envio de um pedido de comércio em massa utilizando uma matriz dinâmica e a função OrderSendPacketAsync(), quando os campos'símbolo' e 'tipo' são os mesmos paracada elemento da matriz dinâmica .

[Yedelkin]

Quando realizamos comércios assíncronos, não sabemos exactamente como foi desencadeado qualquer pedido em particular. Em particular, não sabemos qual era o volume pendente quando um dos pedidos assíncronos foi parcialmente executado.

Pode dizer-me se entendi correctamente que tanto no comércio cambial como no comércio de acções, a ordem da propriedade histórica

ORDER_VOLUME_CURRENT

Volume não preenchido

permite-nos determinar de forma inequívoca até que ponto um pedido assíncrono foi executado na íntegra? Isto é, é correcto que quando uma ordem de mercado é enviada de forma assíncrona no mercado cambial, quando aparece na história, podemos ter a certeza que se ORDER_VOLUME_CURRENT==0.0, a ordem foi completamente executada, mas se ORDER_VOLUME_CURRENT contém um valor não zero, então este valor deve ser considerado como o volume não preenchido para essa ordem de mercado cambial?

A questão é suscitada pelo facto de aqui: https://www.mql5.com/ru/forum/3775/page28#comment_84851 enfatiza que a propriedade ORDER_VOLUME_CURRENT refere-se a ordens utilizadas na bolsa de valores.

[Yedelkin]

Pergunta relativa ao pedido assíncrono que aparece na história.

Quando OrderSendAsync() retorna verdadeiro e o campo result.retcode contém 10008, então de acordo com a Referência, "significa que o pedido foi enviado, mas não garante que tenha chegado ao servidor de negociação".

Pergunta: se um pedido assíncrono for enviado com sucesso pelo terminal, mas não chegar ao servidor, será que tal pedido acabará sempre no histórico? Por outras palavras, pode acontecer que um pedido assíncrono seja enviado com sucesso (por todas as indicações) para o servidor, mas a informação sobre ele não aparecerá na história? Se este cenário for possível, em que condições?

[Renat Fatkhullin]

Yedelkin:

Pergunta: se um pedido assíncrono foi enviado com sucesso pelo terminal, mas não chegou ao servidor, a informação sobre tal pedido aparecerá sempre no histórico? Por outras palavras, pode acontecer que um pedido assíncrono seja enviado ao servidor com sucesso (em todos os aspectos), mas a informação sobre ele não aparece na história? Se este cenário for possível, em que condições?

Se o pedido não chegar ao servidor, não tem qualquer hipótese de aparecer no terminal do cliente.

[Yedelkin]

Renat:
Se o pedido não chegar ao servidor, não tem qualquer hipótese de aparecer no terminal do cliente.

Oops! Acontece que um pedido assíncrono enviado com sucesso pode facilmente perder-se e não aparecer na história.

[---]

Yedelkin:
Oops! Acontece que um pedido assíncrono enviado com sucesso pode facilmente perder-se e não entrar na história.

não.

[Renat Fatkhullin]

Yedelkin:
Acontece que um pedido assíncrono enviado com sucesso pode facilmente perder-se e não entrar na história.

A questão é que um pedido assíncrono não tem praticamente nenhum estatuto de "enviado com sucesso".

A conclusão bem sucedida da função significa apenas que a "encomenda parece correcta do ponto de vista do cliente e foi atirada para a tubagem da rede, aguardar uma resposta na OnTrade".