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
Mais uma vez. Não diz isso em nenhum lugar. Isso é o primeiro de tudo. Em segundo lugar, por que depois é enganador ao mostrar primeiro um código de erro 4066 e depois não?
Os dados são bombeados em lotes e depois processados pelo terminal, e já que você está trabalhando em um timer, você é pausado. Não vejo isso explicitamente em nenhum lugar, mas muitos programadores que escrevem aplicações MTF geralmente sabem disso e eu já lhes falei sobre isso de uma só vez.
https://docs.mql4.com/ru/series/timeseries_access leia-o com atenção.
Bem, acima de tudo você já nos deu uma variante de verificação de acessibilidade do histórico. Não é perfeito, mas é simples e óbvio.
Se esta variante não funcionar, verifique como a seguir.
Os dados são bombeados em porções e depois processados pelo terminal, e como você está em um timer, você é pausado. Sim, não é mencionado explicitamente em nenhum lugar, mas muitos programadores que escrevem aplicações MTF geralmente sabem sobre isso e eu lhes falei sobre isso imediatamente.
https://docs.mql4.com/ru/series/timeseries_access leia-o com atenção.
Bem, acima de tudo você já nos deu uma variante de verificação de acessibilidade do histórico. Não é perfeito, mas é simples e óbvio.
Sobre entrar "em uma pausa", onde estão as provas?
Eu o li cuidadosamente (e já o li antes). Estou ciente de que os dados (especialmente os TFs mais antigos) nem sempre estão imediatamente disponíveis. Não há problema. Mas por que então a função SeriesInfoInteger() não retorna nenhum erro!? Aqui está a questão!
Assumindo que o pedido cai em alguma pausa/swap/update/break etc., então deixe-o retornar o código de erro != 0. E não haverá nenhum problema!
E, acima, você já deu a opção de verificar a acessibilidade da história. Não é perfeito, mas é simples e direto.
Respondeu acima @Ihor Herasko sobre este ponto.
Já respondeu @Ihor Herasko acima sobre este ponto.
Eu dei minha versão do teste acima. Por que perguntar tanto aos desenvolvedores, mas este ponto já é conhecido há muito tempo!
Tentarei certamente sua versão do teste e relatarei os resultados.
Tentarei certamente a sua versão do teste e apresentarei um relatório com os resultados.
Primeiro uma resposta de @Ihor Herasko. Código para reprodução:
Resultado:
De acordo com as entradas dos registros. O terminal foi desligado às 14:25. A seguir, ligado às 14h30min. Verificamos o horário do bar M15. Começamos com a TF M1. O indicador (código acima) mostrava o tempo real de abertura 12:15 (hora do terminal, atrasado em 2 horas em relação à minha hora local). O resultado deveria ter sido 12:30! Conclusão - o erro está presente. E este método sugerido por @Ihor Herasko não funciona.
Não deixe de fazer um relatório! Funciona para mim! Mas pode haver todo tipo de armadilhas se não funcionar, vamos pensar no que mais podemos fazer.
Vou assinar. Código:
Resultado:
Desligou o terminal às 14:48h, religou-o às 15:01h. Deveria ter chegado a hora às 13:00 horas. Eu tenho 12:45. Alguma outra pergunta?
Mudei a TF de M1 para M5 e obtive o resultado correto:
Acho que consegui! O indicador é iniciado imediatamente com o terminal? Se sim, antes de verificar a conexão com o servidor IsConnected() você tem um timer muito rápido que não tem tempo para sincronizar!
Ou faça isso
Mas é preciso levar em conta a diferença entre a hora do servidor e a hora local. Escreva de volta com os resultados!