Erros, bugs, perguntas - página 492
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
Absolutamente, exactamente em todos eles.
Tanto quanto estava disponível, tanto foi recebido. Essa é a forma de o compreender. Verifique a profundidade da história disponível. Certifique-se de que os dados estão disponíveis antes de os solicitar. Que construção tem? recentemente corrigiu um erro com a cópia de prazos mensais, pode ser este.
Portanto, é uma má verificação ou o Expert Advisor NÃO é multi-moeda, apenas pode funcionar com símbolos diferentes. O raciocínio é simples - sabendo que os carrapatos chegam a símbolos diferentes em momentos diferentes. Assim, se um EA for onTick EURUSD (por exemplo), e verificar GBPUSD ou mesmo apenas assinalar alterações de GBPUSD em vez de EURUSD, o resultado será diferente. Em particular, uma barra formada em EURUSD pode ocorrer antes da formação de uma barra com o mesmo tempo em GBPUSD. Se negociar GBPUSD duas vezes no mesmo bar: o anterior bar GBPUSD ainda será considerado como um novo bar (zero). Quanto aos indicadores multimoedas, tudo é claro. Aprender as noções básicas.
Que merda é a matemática, um carrapato entrou em 1 par, mas se o segundo carrapato está atrasado e f...
ou seja, precisamos do preço no momento do aparecimento de um novo bar e das carraças
Não desempenha qualquer papel na ocorrência de um novo bar, mas é de
A estratégia depende, se não se for um escalpador
Gostaria de perguntar uma vez mais à equipa MQ se existem planos para levar a função iCustom() a um estado de trabalho.
Presentemente, os programadores do Expert Advisor não podem oferecer uma solução universal utilizando iCustom(),
onde o cliente poderia especificar o nome de um indicador externo utilizado pelo Expert Advisor.
Para este efeito, o cliente precisa de ter o código fonte do Expert Advisor, bem como de introduzir manualmente cada nome de indicador no código do Expert Advisor, o que é bastante inconveniente, para o dizer de forma suave.
Há também o problema da indicação explícita obrigatória dos valores das células tampão indicadoras.
Se nenhum valor (vazio ou não vazio) for explicitamente atribuído às células tampão do indicador no texto do indicador, a função iCustom() pode preencher as células indicadas no Expert Advisor com
com qualquer porcaria. Penso que tal operação da função não pode ser considerada correcta.
Gostaria de perguntar uma vez mais à equipa MQ se existem planos para levar a função iCustom() a um estado de trabalho.
Presentemente, os programadores do Expert Advisor não podem oferecer uma solução universal utilizando iCustom(),
onde o cliente poderia especificar o nome de um indicador externo utilizado pelo Expert Advisor.
Para tal, o cliente precisa de ter o código fonte do Expert Advisor, bem como de introduzir manualmente cada nome de indicador no código do Expert Advisor, o que é bastante inconveniente, para o dizer de forma suave.
Pode passar um nome dinâmico do indicador chamado no iCustom, mas o conjunto de parâmetros de cada indicador personalizado é diferente.
Infelizmente, não conhecemos uma solução universal para a questão "como podemos implementar com segurança a chamada sem tocar no código sem saber o quê e com que parâmetros será chamada?
Se bem entendi, pretende fazer um sistema de plugin, quando um terceiro utilizador define qualquer nome do indicador com parâmetros (por exemplo, "MyIndicator(10,20,50,100)") nas definições da EA. Para um tal caso com um formato rígido do nome, pode analisar a cadeia por si próprio, formar um bloco de parâmetros e implementar uma chamada dinâmica de iCustom com um conjunto diferente de parâmetros como uma classe de invólucro. Por outras palavras, várias variantes da chamada iCustom com diferentes conjuntos/número de parâmetros estarão escondidas no seu interior.
Há também um problema de indicação explícita obrigatória do valor das células tampão indicadoras.
Se nenhum valor (vazio ou não vazio) for explicitamente atribuído à célula tampão do indicador no texto do indicador, a função iCustom() pode preencher as células indicadas no Expert Advisor com
com qualquer porcaria. Penso que tal operação da função não pode ser considerada correcta.
É impudência e preguiça do revelador não preencher o tampão que lhe foi dado à sua completa disposição.
O sistema de tempo de execução não sabe como se utiliza o buffer indicador e não tem o direito de o preencher com alguns valores, especialmente durante os momentos de massa sobre atribuições (paging ou actualizações de gráficos). O indicador é necessariamente notificado sobre todos os casos em que é necessário recalcular via OnCalculate(...,const int prev_calculated,...) função e parâmetro prev_calculated.
No iCustom, pode passar um nome dinâmico do indicador a ser chamado, mas cada indicador personalizado tem o seu próprio conjunto de parâmetros.
Infelizmente, não conhecemos uma solução universal para a questão "Como podemos implementar com segurança a chamada sem perturbar o código, sem saber o quê e com que parâmetros será chamada?
Se bem entendi, pretende fazer um sistema de plugin, quando um terceiro utilizador define qualquer nome do indicador com parâmetros (por exemplo, "MyIndicator(10,20,50,100)") nas definições da EA. Para um tal caso com um formato rígido do nome, pode analisar a cadeia por si próprio, formar um bloco de parâmetros e implementar uma chamada dinâmica de iCustom com um conjunto diferente de parâmetros como uma classe de invólucro. Por outras palavras, várias variantes da chamada iCustom com diferentes conjuntos/número de parâmetros estarão escondidas no seu interior.
Pela necessidade problemática de alterar o código, referia-me ao requisito de especificar explicitamente o nome do indicador durante os testes
no formato #property tester_indicator "Nome.ex5", mas não um número diferente de parâmetros do indicador.
Os indicadores podem ser utilizados com os parâmetros predefinidos, seleccionando apenas o número de buffer de indicadores com o sinal correspondente.
Isto é impudência e pura preguiça do revelador em não preencher o tampão que lhe foi dado à sua completa disposição.
O sistema de tempo de execução não sabe como se utiliza o buffer indicador e não tem o direito de o preencher com alguns valores, especialmente durante os momentos de massa sobre atribuições (paging ou actualizações de gráficos). O indicador é necessariamente notificado sobre todos os casos de necessidade de recalcular através da função OnCalculate(...,const int prev_calculated,...) e parâmetro prev_calculated.
É realmente difícil atribuir Vazio_Valor às células não utilizadas no iCustom() em vez de as entupir com lixo da pilha?
https://www.mql5.com/ru/forum/1111/72233#comment_72233
Note-se que o valor real das células tampão continua a ser um Vazio. É o iCustom() que faz a adulteração.
Por necessidade problemática de alterações no código, referia-me ao requisito de especificar explicitamente o nome do indicador durante os testes
no formato #property tester_indicator "Nome.ex5", mas não um número diferente de parâmetros do indicador.
Resolveremos a questão mais a fundo - há nuances.
É realmente difícil atribuir Vazio_Valor às células não utilizadas no iCustom() em vez de as encher com lixo da pilha?
https://www.mql5.com/ru/forum/1111/72233#comment_72233
Isto não deve ser feito. Leia novamente a minha resposta, por favor.
A razão pela qual iCustom() atribui valores arbitrários às células tampão que não estão realmente cheias de nada não me é clara, bem como a razão pela qual não pode ser evitada de forma alguma.
Suponho que tem algo a ver com a alocação de memória para a matriz de dados correspondente do buffer indicador.
Tal operação de iCustom(), quando é impossível determinar a origem e a verdade dos dados, parece-me inadmissível e cria riscos adicionais para o utilizador.
Se iCustom() atribuir valores arbitrários, inconsistentes com os valores reais às células tampão de qualquer forma,
porque não atribui valores iguais a Empty_Value a estas células tal como é implementado no MT4?
Então, pelo menos o seu estatuto seria claro.
mas desta forma
há um arredondamento, será que ainda diz isso?
Eu não discuto.
mas desta forma
há um arredondamento, ainda escreve isso, deveria?