Erros, bugs, perguntas - página 149
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
Ponha um atraso - sim, aceito, quantas linhas de código seriam necessárias para fazer isso? E se for uma multi-moeda, tem de dar conta do atraso em cada uma, não é verdade?
Eu escrevi o código que resolve isto. Só que eu não gosto, tal como, desculpa, não gosto do teu. E não se trata de parcialidade, a questão é que não existem outras opções, simples e elegantes.
Tenho duas linhas sobre a moeda múltipla no bloco para o pedido comercial. É isso mesmo... Se precisar de abrir uma encomenda, verifique se a hora actual não é superior à hora limite. Não há nada mais elegante e ambos são absolutamente fiáveis...
Ponha um atraso - sim, aceito, quantas linhas de código seriam necessárias para fazer isso? E se for uma multi-moeda, tem de dar conta do atraso em cada uma, não é verdade?
Eu escrevi o código que resolve isto. Só que eu não gosto, tal como, desculpa, não gosto do teu. Não é uma questão de parcialidade, a questão é que não existem outras soluções simples e elegantes.
Atraso não é o nosso método))
1. Devemos memorizar o número de posições(ou ordens) numa variável (estática ou global) antes de realizarmos uma operação comercial.
2. Em caso de não-execução, a variável=-1;
Em caso de execução bem sucedida, esperamos, não fazemos nada, e verificamos cada tick até que o número de posições (ou ordens) seja igual à variável.
3. quando não é igual - variável=-1;
Atraso não é o nosso método))
1. Antes de uma operação comercial, armazenar numa variável (estática ou global) o número de posições(ou ordens)
Atraso não é o nosso método))
1. Antes de uma operação comercial, guardamos o número de posições(ou ordens) numa variável (estática ou global)
2. Em caso de não-execução - variável=-1;
Em caso de execução bem sucedida, esperamos, não fazemos nada, e verificamos cada tick até que o número de posições (ou ordens) seja igual à variável.
3. logo que já não seja igual, variável=-1;
Não é um método - apenas para as gratificações, mas para o comércio a médio prazo está bem. Caso contrário, corremos o risco de nos depararmos com
10024
TRADE_RETCODE_TOO_MANY_REQUESTS
Pedidos demasiado frequentes
com possível proibição de negociar o Conselheiro Especialista.
Está aberta? A posição é a mesma para cada instrumento.... Não se pode enchê-lo ou fechá-lo parcialmente... o montante será o mesmo. E não é aceitável recalcular o número de encomendas na história... não sabe de onde podem vir...
Sim, estou ciente disso) devemos escrever numa variável o que deve ser alterado como resultado de OrderSend().
Se fechar completamente/(ou abrir uma nova) mudará o número total de poses (embora, sim, é suficiente, e parece mais fiável, e não é/é uma poses por símbolo a lembrar). Pode também lembrar-se do volume, e funcionará ao adicionar/remover posições.
Ao definir/remover uma ordem pendente - o número de ordens (pode ser calculado utilizando o símbolo).
Em geral: um pouco de imaginação e adicionar apenas uma variável, por tipo de operação comercial, tornará o seu código mais fiável, simples e elegante :)
Não é um método - apenas para as gratificações, mas para o comércio a médio prazo - um método normal. Caso contrário, corremos o risco de nos depararmos com
10024
TRADE_RETCODE_TOO_MANY_REQUESTS
Pedidos demasiado frequentes
Caso contrário, arriscamo-nos a ser proibidos de negociar o Expert Advisor.
isso é um pouco diferente, foi assim em 4:
ERR_TOO_MANY_REQUESTS 141 Demasiados pedidos. É necessário reduzir a frequência dos pedidos e alterar a lógica do programa.
Tem de se esforçar muito para obter este erro, ou pode ter uma conta numa empresa de corretagem inteligente :)
O escorregamento é um método normal para alguns erros, noutros casos parece um pouco tortuoso.
é um pouco diferente, foi assim em 4:
tem de se esforçar muito para cometer esse erro, ou ter uma conta DC duvidosa :)
O escorregamento é um método normal para alguns erros, noutros casos parece um pouco tortuoso.
Não sei.
Aqui, até diz no manual do terminal:
Não sei...
Aqui, até diz no manual do terminal:
Não é isso que eu quero dizer :)
Vladix:
Em termos gerais, o problema é este:
um tick vem, o indicador mostra que precisa de fechar, eu fecho
o próximo tick vem, o indicador mostra que deve fechar e eu não sei o que fazer - a posição já está sobrescrita e o que lhe acontece neste momento, claro, pode ser descoberto, mas através do quinto ponto.Neste caso, basta saber que a informação da posição foi actualizada, sem utilizar o quinto ponto, de preferência)
Desenvolvedores.
Na ajuda MQL, não há ENUM_CHART_VOLUME_MODE no separador Índice. Adicione-o...
Em geral: um pouco de imaginação e a adição de apenas uma variável, por tipo de operação comercial, tornará o seu código mais robusto, simples e elegante :)
Assim, fantasie exactamente qual o código de que o homem precisa que seria 10 linhas longas e fiáveis, como a minha, e que ele gostaria :)
E por falar em elegância, sugere que se faça uma pilha com uma lógica pouco clara a partir de duas linhas que estão a cumprir absoluta e logicamente a tarefa que está a pedir...
Atraso não é o nosso método))
Em caso de execução, esperamos... ...3. iaque não é igual...
E esperar por quanto tempo? Isso não conta como um atraso? E se nunca se tornar "não igual"? E estamos à espera pelo tempo... Um pedido comercial pode facilmente devolver um troue e não ser efectivamente satisfeito...