Erros, bugs, perguntas - página 2219
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
Resultado emForexTimeFXTM-Demo01
O guião abre e fecha posições até detectar uma "ordem fantasma" - nem entre as actuais nem na história. Devo considerá-lo um bug ou uma característica de plataforma?
O guião é escrito de tal forma que várias posições podem abrir devido a esta nuance. Mas isso não impede de obter uma "ordem fantasma".
Eu não quero ser totó, mas expressões como estas:
Pode lembrar-se de cor todos os valores numéricos de um dado enumeral e por que ordem vão, mas outras pessoas podem não conhecer estas entranhas. A brevidade é certamente a irmã do talento, mas apenas se não prejudicar a qualidade.
E por falar no assunto em discussão, a ordem.deal, e não o resultado.order, deve ser verificada para que a posição seja aberta. Consequentemente, deve ser encontrada entre posições, e não entre ordens. Não é assim?
A escassez é, evidentemente, a irmã do talento, mas não em detrimento da qualidade.
Parece ser uma operação MQL comum.
E por falar no assunto em discussão, a ordem.deal, e não o resultado.order, deve ser verificada para que a posição seja aberta. Assim sendo, deve ser procurada entre as posições, e não entre as ordens. Não é assim?
A encomenda inicial que é enviada imediatamente após a OrderSend pode não ser encontrada em lado nenhum. A posição é muito mais tardia do que a encomenda.
ZZY No código, deixei propositadamente o comentário com a linguagem mais compreensível do algoritmo de negociação - MQL4.
A encomenda original que é enviada imediatamente após a OrderSend não pode estar em lado nenhum. A posição é muito mais tardia do que a encomenda.
De facto, não é a questão, de acordo com a documentação, a OrderSend não é obrigada a receber quaisquer bilhetes:
Quando se envia uma ordem de mercado (MqlTradeRequest.action=TRADE_ACTION_DEAL) o resultado bem sucedido da função OrderSend() não significa que a ordem tenha sido executada (as operações correspondentes foram executadas). Neste caso, verdadeiro significa apenas que a ordem foi colocada com sucesso no sistema de negociação para posterior execução. O servidor de negociação pode preencher os valoresdos campos de resultadosnaestrutura de resultados devolvidos, se estes dados lhe forem conhecidos no momento da geração da chamada OrderSend(). Em geral, o evento ou eventos de negócios correspondentes a uma encomenda podem ocorrer após o envio da resposta à chamada OrderSend(). Portanto, para qualquer tipo de pedido de troca, ao receber o resultado OrderSend(), deve primeiro verificar o código de retorno do servidor de trocaretcode e o código de resposta do sistema de troca externoretcode_external(se necessário) disponível naestrutura doresultado retornado.
Portanto, não podemos em caso algum passar sem a OnTradeTransaction.
Assim, acontece que não há garantia de operações de comércio síncrono na MQL5.
Não importa, porque de acordo com a documentação, a OrderSend não é obrigada a receber quaisquer bilhetes:
Não é necessário verificá-lo em qualquer caso. É apenas opcional.
Um resultado não zero após o OrderSend sincronizado diz-nos sempre que é recebida uma resposta do servidor comercial com uma ordem registada no mesmo. Este bilhete provém exactamente do servidor. E se a OrderSend for bem sucedida, este bilhete é sempre recebido.
O aborrecimento, porém, parece acontecer não por causa da OrderSend, mas no momento de aceitar a ordem numa troca. Embora existaORDER_STATE_REQUEST_ADD para tais casos. Seja como for, à espera de uma resposta da MQ. Na minha opinião, isto é um bug quando há uma ordem no servidor de comércio, mas após o OrderSend sincronizado no terminal não há nenhuma palavra sobre isso.
Seja como for, à espera de uma resposta da MQ. Na minha opinião, isto é um bug, quando há uma ordem no servidor de negociação, mas após o OrderSend sincronizado no terminal não há sinal dela.
Digo mais, devemos pedir aos programadores que assegurem o sincronismo total da OrderSend, tanto no terminal como no servidor. Caso contrário, se o sincronismo de execução não é garantido, então porque precisamos desta função? Para este fim já existe OrderSendAsync.
Olá. Hoje actualizei para a versão 1860 e ao mesmo tempo que optimizava o Expert Advisor, deparei-me com este problema:
O tempo de espera entre os passes é de 1 minuto! Pode por favor aconselhar qual poderá ser o problema?
p.s. Antes da actualização, tudo funcionava como um relógio.
Por acaso, está a usar a função de Barras?
Se assim for, ver isto.
Apenas uma pergunta:
Talvez faça sentido fazer ficheiros comuns? A única coisa que me incomoda é a constante renomeação de mq4 e mq5. Em relação aos projectos, estava a pensar, talvez eu devesse fazer uma extensão comum como mq ?
E pode simplesmente copiar código de terminal para terminal sem qualquer edição em extensões...
Apenas uma pergunta:
Talvez faça sentido fazer ficheiros comuns? A única coisa que me incomoda é a constante renomeação de mq4 e mq5. Em relação aos projectos, estava a pensar, talvez eu devesse fazer uma extensão comum como mq ?
E pode simplesmente copiar código de terminal para terminal sem qualquer edição em extensões...
E quem proíbe de escrever estes códigos em ficheiros mqh e ligá-los usando (#incluir). É o que tenho vindo a fazer há já algum tempo.
E quem proíbe de escrever estes códigos em ficheiros mqh e ligá-los a (#incluir). O que tenho vindo a fazer há já algum tempo.
você liga, eu mudo as extensões ... vizinhos.
Digo mais, devemos pedir aos programadores que garantam que a OrderSendAsync é totalmente sincronizada, tanto no terminal como no servidor. Caso contrário, se a execução sincronizada não for garantida, porque precisamos desta função? Já existe OrderSendAsync para este fim.
Deixem-me ver se entendi bem isto. Sincronização do envio de ORDENS para o sistema de negociação da plataforma e do próprio terminal.