Eu também estava pensando, aparentemente nesta situação não se trata de bombear, mas de começar a construir a nova barra sem esperar que a história seja bombeada para cima. E isso é meio certo. Mas, por outro lado, imagine um Expert Advisor comercial. Ocorre uma falha na conexão e então a conexão é restaurada. O especialista pode abrir uma posição com base nos valores do indicador errado até que o histórico seja completamente trocado. Portanto, a questão está além do escopo deste tópico e diz respeito à segurança do autotrading em geral. O problema não é simples, é claro. Talvez, a solução seria uma variável pré-definida "duração do último período contínuo da história"? Os indicadores (especialistas) poderiam lê-lo e lidar com a situação de alguma forma.
O armazenamento de valores de barras (não apenas de tempo[0]) pode ajudar neste caso .....
Aqui está um fragmento desse arquivo de registro que mostra que quando uma nova barra começa, as barras aumentam em 1 e não pelo número de barras a serem atualizadas. Portanto, isso não ajuda
Aqueles que fazem EAs comerciais sérios provavelmente estão cientes deste problema. E algum tipo de tratamento para esta situação está incluído na EA.
Bem, podemos tentar lidar com a situação de alguma forma, mas parece que não podemos passar sem alguns truques complicados. Especialmente levando em conta a posição rígida da MQ nos gráficos sem furos. Por outro lado, o terminal sabe se precisa ou não bombear a história. Se a MQL tivesse acesso a esse conhecimento, o problema seria resolvido muito mais naturalmente.
Em seguida, comparamos o Tempo[0] e o Tempo[1]. Eu mesmo só lutei uma vez com tal situação, portanto não posso lhe dar um código prático desde o início.
Em seguida, comparamos o Tempo[0] e o Tempo[1]. Eu mesmo só lutei uma vez com tal situação, portanto, não posso lhe dar nenhum código prático. <br / translate="no">.
Isto não fará nada a menos que você habilite primeiro o código do tipo "gráfico sem furos", pois a existência de furos é uma situação normal na MT. Embora em grandes períodos de tempo, ela vai pegar quase todos os fracassos.
Na verdade, isto é uma espécie de "demonização" :) O código deve ser escrito com máxima proteção, pois a troca de dados pode ser causada não apenas pelo terminal, mas também pelo ISP, centro de dados, corretor, desligamento do computador e assim por diante.
Receio que esse código com a máxima proteção seja inadequado para o uso prático :). Uma vez que o comércio é arriscado em geral, poderíamos ter nos limitado a uma proteção razoável. Mas estamos falando aqui de uma situação bastante freqüente. A propósito, minha conclusão sobre uma melhor segurança de grandes prazos em postos anteriores estava errada. A barra anterior pode ter valores altos, baixos e Сlose incorretos antes da troca do histórico, enquanto a barra atual tem valores altos, baixos e abertos incorretos.
Sim, acontece que os grandes prazos são ainda mais perigosos do que os pequenos, porque não vejo nenhuma maneira simples de determinar a exatidão dos dados para as duas últimas barras. Você pode imaginar um indicador pendurado nos minutos e preenchendo a variável global GoodHistoryDepht. Outros indicadores verificam este valor em relação à profundidade de cálculo requerida e tomam decisões. Mas devido à posição do MQ nos buracos, grande parte do tempo (e quanto mais longo o prazo, maior, até a completa rejeição das barras diárias) será simplesmente inadequado para o comércio. Especialmente tendo em vista que as falhas de comunicação preferem viver em contas reais.
start() {..... if (PrevBars!=Bars-1) { init(); PrevBars=Bars-1; }Aqui está um fragmento desse arquivo de registro que mostra que quando uma nova barra começa, as barras aumentam em 1 e não pelo número de barras a serem atualizadas. Portanto, isso não ajuda
Bem, podemos tentar lidar com a situação de alguma forma, mas parece que não podemos passar sem alguns truques complicados. Especialmente levando em conta a posição rígida da MQ nos gráficos sem furos.
Por outro lado, o terminal sabe se precisa ou não bombear a história. Se a MQL tivesse acesso a esse conhecimento, o problema seria resolvido muito mais naturalmente.
Isto não fará nada a menos que você habilite primeiro o código do tipo "gráfico sem furos", pois a existência de furos é uma situação normal na MT. Embora em grandes períodos de tempo, ela vai pegar quase todos os fracassos.
O código deve ser escrito com máxima proteção, pois a troca de dados pode ser causada não apenas pelo terminal, mas também pelo ISP, centro de dados, corretor, desligamento do computador e assim por diante.