![MQL5 - Linguagem para estratégias de negociação inseridas no terminal do cliente MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Colegas, o que pensam desta ideia? Em tal estrutura(MqlPacketTradeResult) pode escrever um campo indicando o número de encomendas concluídas, etc.
Colegas, o que pensam desta ideia? Em tal estrutura(MqlPacketTradeResult) pode escrever um campo indicando o número de encomendas concluídas , etc.
Но для этого придётся дожидаться ответа от сервера в рамках функции OrderSendAsync(). И асинхронность функции OrderSendAsync() сойдёт на нет. Ренат же уже пообещал, что будут иные функции, с помощью которых можно попытаться похимичить после срабатывания OrderSendAsync().
Sim, não tinha pensado em assincronia...
É tudo, então:
Sim, não tinha pensado em assincronia...
Bem, aqui vai:
Assíncrono significa trabalhar sem esperar por uma resposta. Disparar (OrderSenAsync) e correr sem tentar ver se o alvo é atingido. Pois não há tempo.
Uma resposta indirecta seria um som vindo mais tarde (OnTrade) - talvez o tiro tenha atingido o alvo, ou talvez algo tenha simplesmente caído. É aqui que pode olhar para fora e ver (verificar todas as ordens, negócios, posições, etc.) se desejar.
Sim, não tinha pensado em assincronia...
Então é tudo:
Uma resposta indirecta é um som que vem mais tarde (OnTrade) - talvez o tiro tenha atingido o alvo, ou talvez algo tenha acabado de cair. É aqui que pode olhar, se desejar (verificar todas as ordens, negócios, posições, etc.).
Assíncrono significa trabalhar sem esperar por uma resposta. Disparar (OrderSenAsync) e correr sem tentar ver se o alvo é atingido. Pois não há tempo.
Uma resposta indirecta é um som posterior (OnTrade) - pode ser que o tiro tenha atingido o alvo ou que algo tenha simplesmente caído. É aqui que pode olhar se quiser (verificar todas as ordens, negócios, posições, etc.).
Está enganado ou devido à sua pouca experiência em comércio em modo assíncrono ou devido à fraca funcionalidade do MT5 para tal tipo de operação.
Não precisa de assíncronia por causa da assíncronia. E é utilizado apenas quando é rentável. Por exemplo, ao negociar uma carteira, quando a carteira precisa de ser comprada ou reequilibrada aqui e agora. Por outras palavras, uma dúzia de ordens de comércio de símbolos diferentes aos preços actuais.
E ninguém o fará, se tratar a assincronia da forma que descreveu - disparar e esquecer. E as reacções aos disparos devem ser avaliadas com base nas posições líquidas actuais. As reacções devem ser específicas a cada ordem comercial.
Se houvesse um redireccionamento, deveríamos ser informados sobre isso ou receber outra resposta. Não devemos adivinhar se houve ou não uma reincidência, uma vez que a posição líquida não mudou por um segundo ou dois.
Na primeira página desta discussão existem diagramas e eventos de mensagens recebidas. Não apareceram apenas do nada, mas com anos de experiência assíncrona. Por isso, vale a pena prestar atenção a tal arquitectura, sem reticências.
Colegas, o que pensam desta ideia? Em tal estrutura(MqlPacketTradeResult) pode escrever um campo indicando o número de encomendas concluídas, etc.
Presume que o lote de encomendas tem sempre os mesmos campos?
IMHO um lote de pedidos idênticos é necessário apenas para fins de demonstração, para o trabalho serão utilizados pedidos de símbolos diferentes com volumes diferentes e, claro, direcções diferentes. E consequentemente, cada pedido terá de ser verificado separadamente, pelo que não faz sentido enviar-lhes um lote.
E o que se supõe é apenas uma ligação do for loop.
Está a sugerir que uma pilha de candidaturas tem sempre os mesmos campos preenchidos?
IMHO um lote de aplicações idênticas só é necessário para fins de demonstração, aplicações com caracteres diferentes, volumes diferentes e, claro, direcções diferentes serão utilizadas para o trabalho. E consequentemente, cada pedido terá de ser verificado separadamente, pelo que não faz sentido enviar-lhes um lote.
E o que se supõe é apenas uma ligação do for loop.
O que os impede de preencher ciclicamente cada pedido ? E depois, tal como ciclicamente processa cada resultado?
Se a sua proposta apenas irá complementar a função existente, nada, senão não é claro como a estrutura simples MqlPacketTradeRequest ...
... Se a estrutura MqlPacketTradeRequest é a estrutura da matriz dinâmica das estruturas MqlTradeRequest, ela pode quebrar toda a lógica do servidor que é concebida para estruturas de consulta simples.
Caso contrário, a nível do terminal teríamos de dividir este lote em pedidos separados, o que anula todo o objectivo de introduzir esta sobrecarga.