Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
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:
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 :-)
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.
...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.
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).
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
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.
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?
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.
Oops! Acontece que um pedido assíncrono enviado com sucesso pode facilmente perder-se e não entrar na história.
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".