O controlo assíncrono só pode ser realizado em OnTrade().
Há uma necessidade de identificar um pedido em particular na OnTrade().
Assim, chegamos a essa OrderSendAsync() deve devolver o número do bilhete recebido do servidor (excluindo a situação de time-out). O número do bilhete é necessário para identificar de forma única o pedido tanto do servidor como do cliente.
Ao unificar este mecanismo, a função OrderSend() também pode ser redesenhada - deve devolver o número do bilhete, ou "-1" em caso de não envio da encomenda para o servidor.
Em seguida, no programa, implementar uma classe com a lista de bilhetes gerados.
Em cada evento OnTrade(), nós compreendemos:
1. se esta é a nossa acção, ou, por exemplo, a acção de outra instância do Conselheiro Especialista (os magos deixarão de ser necessários).
2. A que tipo de pedido estamos a receber uma resposta.
Assim, a OrderSendAsync() deve devolver o número do bilhete recebido do servidor (excluindo a situação de timeout). O número do bilhete é necessário para identificar inequivocamente o pedido, tanto com o servidor como com o cliente.
Renat: Estamos agora a discutir a adição da função OnTradeResult(MqlTradeResult&info) que terá detalhes exactos das respostas do servidor.
Na minha opinião, deveria ter este aspecto do lado do utilizador:
o utilizador escreve uma classe para trabalhar com apontadores e anexa-lhe a classe de processamento de sinais comerciais.
Quando um ou mais sinais aparecem, novos objectos são criados e um ou mais pedidos são enviados para o servidor; consequentemente, o objecto existe até que o sinal seja executado.
OnTrade monitora o destino e toma uma decisão (ou/ou) ou envia um novo pedido ou destrói o objecto à medida que este foi passando.
Este esquema necessita da identificação do objecto a processar em relação com a activação deste evento comercial.
De modo algum. A propósito, não vale muito a pena preocupar-se com a OnTrade, porque não virá 100% do tempo (é mais ou menos o mesmo que o erro 1 em MT4)
De modo algum. A propósito, não vale muito a pena preocupar-se com a OnTrade, porque não virá 100% do tempo (que é mais ou menos o mesmo que o erro 1 em MT4)
Ainda tem de subscrever um seguro.
Não é melhor "torná-lo bom"?
Justificar porque é que o Comércio não vem em ~100% do tempo?
Para login e uso do site MQL5.com, você deve ativar o uso de cookies.
Ative esta opção no seu navegador, caso contrário você não poderá fazer login.
Você entrou na conta. A autenticação de dois fatores foi desativada. Configure-a novamente e escaneie um novo código QR ou continue com a autenticação de dois fatores desativada.
Assincronia sem controlo = caos.
O controlo assíncrono só pode ser realizado em OnTrade().
Há uma necessidade de identificar um pedido em particular na OnTrade().
Assim, chegamos a essa OrderSendAsync() deve devolver o número do bilhete recebido do servidor (excluindo a situação de time-out). O número do bilhete é necessário para identificar de forma única o pedido tanto do servidor como do cliente.
Ao unificar este mecanismo, a função OrderSend() também pode ser redesenhada - deve devolver o número do bilhete, ou "-1" em caso de não envio da encomenda para o servidor.
Em seguida, no programa, implementar uma classe com a lista de bilhetes gerados.
Em cada evento OnTrade(), nós compreendemos:
1. se esta é a nossa acção, ou, por exemplo, a acção de outra instância do Conselheiro Especialista (os magos deixarão de ser necessários).
2. A que tipo de pedido estamos a receber uma resposta.
Assim, a OrderSendAsync() deve devolver o número do bilhete recebido do servidor (excluindo a situação de timeout). O número do bilhete é necessário para identificar inequivocamente o pedido, tanto com o servidor como com o cliente.
Olá. Sabe sequer o que é a assíncronia?
Estamos agora a discutir a adição da função OnTradeResult(MqlTradeResult&info) que terá detalhes exactos das respostas do servidor.
Na minha opinião, deveria ter este aspecto do lado do utilizador:
o utilizador escreve uma classe para trabalhar com apontadores e anexa-lhe a classe de processamento de sinais comerciais.
Quando um ou mais sinais aparecem, novos objectos são criados e um ou mais pedidos são enviados para o servidor; consequentemente, o objecto existe até que o sinal seja executado.
OnTrade monitora o destino e toma uma decisão (ou/ou) ou envia um novo pedido ou destrói o objecto à medida que este foi passando.
Este esquema necessita da identificação do objecto a processar em relação com a activação deste evento comercial.
Neste esquema, é necessário identificar qual o objecto a processar em relação com a activação deste evento comercial.
Qual é o problema?
Está a brincar?
O comércio está agora sem rosto, não se pode dizer que objecto da lista deve ser processado à medida que chega.
Está a brincar comigo?
De modo algum. A propósito, não vale muito a pena preocupar-se com a OnTrade, porque não virá 100% do tempo (é mais ou menos o mesmo que o erro 1 em MT4)
Ainda tem de subscrever um seguro.
Não é melhor "torná-lo bom"?
De modo algum. A propósito, não vale muito a pena preocupar-se com a OnTrade, porque não virá 100% do tempo (que é mais ou menos o mesmo que o erro 1 em MT4)
Ainda tem de subscrever um seguro.
Não é melhor "torná-lo bom"?
Justificar porque é que o Comércio não vem em ~100% do tempo?