Um filtro útil responde a uma pergunta prática: este EA pode avaliar uma nova posição com as informações disponíveis? O nome de uma sessão ou um calendário vazio não responde sozinho. A regra precisa de um relógio verificado, cobertura clara dos eventos e cotações atuais do símbolo negociado.
Comece com uma separação simples: gerencie a exposição existente com suas próprias regras; permita avaliar novas entradas somente após as verificações obrigatórias. Este guia detalha essa separação, apresenta um breve registro de decisões e explica como testá-la. Não fornece um EA pronto nem comprovação de rentabilidade.
1. Defina o que o filtro controla
Separe a regra de sessão, a restrição por notícias programadas e o setup de entrada da estratégia. A sessão define os horários permitidos; a regra de notícias exclui intervalos selecionados; o setup define a oportunidade. Passar nas duas primeiras verificações não cria um setup nem remove limites de execução e risco da conta.
Use três resultados explícitos: PASS, BLOCK e UNKNOWN. São rótulos de dados definidos pelo autor, não códigos de erro do MT4. Uma janela fechada conhecida pode bloquear; informação ausente não justifica aprovação. Na política ilustrada, tanto um bloqueio quanto um dado obrigatório desconhecido suspendem a avaliação de novas entradas. O gerenciamento segue suas próprias verificações de dados e permissões.
2. Escreva as regras de horário e cobertura antes dos testes
Use o mapeamento de horários por data do guia de sessões e as definições de eventos do guia do calendário econômico. Registre as regras em uma especificação com versão que outra pessoa consiga aplicar aos mesmos dados.
- Instrumento e escopo: corretora, conta, símbolo, moedas relevantes e famílias de eventos selecionadas, incluindo etapas posteriores.
- Sessão: datas completas, fuso horário, regras de dias da semana e limites de inclusão ou exclusão precisos.
- Mapeamento de horários: relação verificada entre UTC, eventual regra local e horário do servidor da corretora em cada data.
- Exclusão por notícias: fonte do horário, intervalos antes e depois, sobreposições e tratamento de eventos provisórios, atrasados ou alterados.
- Requisitos dos dados: cobertura de datas e moedas, esquema, versão da fonte, estado de atualização e limites de idade.
- Resposta a falhas: o que suspende entradas, como monitoramento e gerenciamento continuam e o que deve ser reconciliado antes da retomada.
Para sessões locais que atravessam a meia-noite, defina o dia de negociação de referência e trate explicitamente a mudança de data. Inclua eventos de dias adjacentes cuja exclusão alcance o momento da decisão. Nas transições de horário de verão, verifique a conversão escolhida para horários locais repetidos ou inexistentes. Não substitua silenciosamente um mapeamento ausente pelo fuso exibido no computador.
3. Valide o snapshot do calendário, não apenas o download
Um snapshot é uma versão salva do calendário usada para decidir. Um download bem-sucedido ou uma lista de eventos vazia não comprova completude. Confira se o provedor cobre moedas, datas e tipos de eventos solicitados, se todos os registros necessários foram obtidos e se horários, unidades e versões foram interpretados corretamente.
Guarde separadamente as informações de atualização do provedor e seu horário de recebimento. Uma resposta recém-recebida pode conter dados antigos. Substitua o snapshot ativo somente após validar toda a nova versão; um arquivo parcial ou uma lista atualizada pela metade não deve se tornar válida. Uma atualização malsucedida ou outra leitura do cache não deve zerar a idade da última versão verificada.
Um snapshot verificado e suficientemente recente pode confirmar que nenhum intervalo selecionado está ativo dentro da cobertura declarada. Cobertura ausente, alteração de agenda não resolvida, horário desconhecido de evento relevante ou snapshot vencido permanecem desconhecidos. Suspenda as entradas dependentes conforme definido e continue o tratamento de falhas e o gerenciamento previstos. Notícias inesperadas ficam fora da proteção de um calendário programado.
4. Verifique separadamente a cotação do símbolo negociado
Acompanhe recebimento e validade do Bid/Ask desse símbolo usando uma medição de tempo decorrido que trate reinicializações e alterações do relógio. Recebimento recente não comprova dados atuais na origem nem execução disponível. Valide fluxo de dados, contexto do relógio, spread e permissões de negociação separadamente; consulte o monitoramento de EAs.
No MT4, TimeCurrent() em OnTick() corresponde ao tick processado; em outros manipuladores pode refletir a última cotação de qualquer símbolo na Observação do Mercado. Isso não comprova uma cotação recente do próprio símbolo. Em tempo real, TimeGMT() depende das configurações de horário do computador; no testador MT4 equivale a TimeCurrent() simulado. A diferença no testador não reconstrói os deslocamentos históricos da corretora.
5. Acompanhe um registro de decisões fictício
Apenas neste exemplo, use a sessão UTC [08:00, 17:00) em 2026-03-16. Mantenha a união hipotética das exclusões A/B [12:15, 13:05) do guia anterior. Toda a cobertura e os metadados necessários são considerados verificados; os eventos cobrem o dia UTC inteiro, suficiente para estas verificações diurnas e suas margens. Nenhum provedor ou divulgação real é afirmado.
Para ilustrar a conta, escolha idade máxima do snapshot de 30 minutos e da cotação do próprio símbolo de 5 segundos. São valores escolhidos pelo autor, não configurações recomendadas nem garantias de segurança. O primeiro snapshot foi verificado às 12:00:00; uma substituição completa e atual é verificada às 13:06:00. Às 17:00:00 há outro snapshot válido. As idades pressupõem medições de tempo verificadas e comparáveis.
| Decisão · UTC | Idade do snapshot | Idade da cotação do símbolo | Somente resultado de horário/dados |
|---|---|---|---|
12:10:00 | 10 min | 1 s | Passa nestas verificações; continuar as demais |
12:20:00 | 20 min | 1 s | Bloqueio: intervalo de notícias ativo |
13:05:00 | 65 min | 1 s | Espera: calendário antigo |
13:06:06 | 6 s | 12 s | Espera: cotação do símbolo antiga |
13:06:07 | 7 s | 1 s | Passa nestas verificações; continuar as demais |
17:00:00 | 0 s | 1 s | Bloqueio: fora da sessão |
Às 13:05:00, o intervalo de notícias termina, mas o snapshot antigo tem 65 minutos. Às 13:06:06, o novo tem 6 segundos, mas o último recebimento do símbolo às 13:05:54 tem 12 segundos. Um recebimento às 13:06:06 tem apenas 1 segundo às 13:06:07. Essa linha passa nos controles ilustrados de horário e dados, não nos de estratégia, execução ou risco. O limite das 17:00 é excluído. Não se simula ordem, saída ou retorno.
6. Preserve o gerenciamento e reconcilie ordens na corretora
Bloquear novas entradas não deve pular o monitoramento e o gerenciamento previstos das posições existentes. Ações de gerenciamento ainda precisam dos próprios dados e permissões válidos; preços ausentes não autorizam alterar um stop às cegas. Defina separadamente como manter ou cancelar ordens pendentes e verifique o estado aceito pela corretora, sem presumir que uma solicitação de cancelamento foi concluída.
O botão AutoTrading do MT4 proíbe solicitações automáticas de negociação, enquanto o EA e OnTick() podem continuar funcionando. Portanto, não é uma pausa exclusiva para novas entradas: o gerenciamento que exige essas solicitações também pode ser afetado. Diferencie esse botão da remoção de um EA ou da desconexão do terminal. Proteções existentes na corretora e gerenciamento no cliente são mecanismos distintos; veja o gerenciamento de risco.
7. Evite que a busca de dados bloqueie as decisões
Use um cache completo e validado para decidir e um processo controlado para atualizá-lo. Defina tempos limite, avisos de falha e ativação de novas versões. Executar o gerenciamento uma vez antes de uma solicitação lenta não o mantém funcionando enquanto ela bloqueia o mesmo EA.
Opcional: limites de rede e eventos do MT4
Em MQL4, WebRequest() é síncrona. Movê-la de OnTick() para OnTimer() no mesmo EA não a torna assíncrona; a espera ainda pode atrasar o programa. Um componente separado de busca pode fornecer um snapshot validado, mas a transferência e suas falhas também precisam ser verificadas. Um temporizador agenda chamadas, sem garantir gerenciamento ininterrupto.
A sequência lógica é: executar o caminho definido de gerenciamento e monitoramento, avaliar as verificações obrigatórias de novas entradas e, só após aprovação, considerar um setup atual com controles de execução e risco. Isso descreve responsabilidades, não código MQL4 executável nem garantia de processamento no prazo. Teste integração real, permissões e comportamento em falhas antes de depender deles.
8. Mantenha um registro que sobreviva à reinicialização
Registre horário UTC da decisão, horário do servidor e mapeamento verificado, versão das regras, identificador do snapshot e horários de origem e recebimento, cobertura, recebimento e idade da cotação, exclusões ativas e motivos do resultado. Preserve candidatos rejeitados além das verificações aprovadas. O registro deve explicar uma espera sem reconstruí-la depois com um calendário revisado.
Após reiniciar ou reconectar, reconcilie com a corretora posições existentes, ordens pendentes e solicitações não resolvidas. Restaure apenas o estado verificável: reiniciar não significa conta sem posições nem cache atualizado. Evite processar o mesmo candidato novamente. Se um estado necessário for desconhecido, suspenda entradas até a reconciliação e continue a resposta a falhas e o gerenciamento definidos.
9. Teste a correção antes de interpretar um backtest
Antes de medir desempenho de mercado, crie pequenos casos fixos com resultados esperados. Inclua:
- Início de sessão incluído, fim excluído e intervalos que atravessam a meia-noite.
- Início e fim das exclusões, eventos sobrepostos e agenda atrasada ou alterada.
- Dados de calendário ausentes, parciais, malformados ou fora de cobertura, incluindo resposta vazia não verificada.
- Idade exatamente no limite escolhido e logo acima, além de tick recente em outro símbolo enquanto o negociado continua antigo.
- Reinicialização, salto do relógio, atualização falha e substituição interrompida do snapshot sem zerar sua idade.
- Ordens na corretora e gerenciamento durante o bloqueio de entradas, incluindo cancelamento rejeitado e falta de permissão de negociação.
O Testador de Estratégias do MT4 não executa WebRequest() nem trata eventos Timer. Teste a lógica compartilhada com dados congelados e mapeamento histórico de horários verificado, por um caminho de teste suportado. Reproduza cada snapshot apenas quando ele teria ficado disponível. Uma tabela histórica de eventos sozinha não reproduz a busca em tempo real nem o agendamento de chamadas. Veja o guia de backtesting no MT4 para outras limitações.
10. Avalie o benefício separadamente do funcionamento correto
Um filtro correto pode excluir operações vencedoras e perdedoras. Compare a regra proposta com uma referência declarada usando a mesma estratégia, os mesmos dados e premissas de custos. Guarde todos os candidatos e motivos de rejeição, reserve dados posteriores para validação e inclua custos de execução realistas. Buscar muitas janelas e publicar apenas a melhor pode causar sobreajuste à amostra.
Depois observe a integração real em demo, com dados normais e falhas. Meça atualizações malsucedidas, esperas por dados antigos, lacunas de cotações, atrasos de gerenciamento e respostas da corretora. Um registro claro mostra o que o sistema fez; não comprova rentabilidade futura. Antes de ampliar o uso, confirme:
- A especificação com versão, o mapeamento de horários e a seleção de eventos estão documentados.
- Os controles de cobertura e idade distinguem estados livres, bloqueados e desconhecidos.
- Casos de limite e falha produzem os resultados esperados.
- Testes históricos respeitam a disponibilidade das informações e declaram histórico ausente.
- Testes demo verificam busca de dados, reinicializações, continuidade do gerenciamento e estado das ordens na corretora.
- Qualquer benefício alegado é avaliado separadamente, com custos e dados posteriores, sem números de desempenho inventados.
11. Perguntas sobre filtros de EAs
Um calendário livre significa que o EA deve entrar?
Não. Um calendário verificado sem restrições passa apenas em parte da decisão. Sessão, qualidade das cotações, execução, risco da conta e um setup atual da estratégia ainda importam. Notícias inesperadas podem chegar fora da agenda.
Por que um download recente ainda pode deixar o estado desconhecido?
A resposta pode ser antiga, incompleta, fora da cobertura necessária ou interpretada incorretamente. O horário de recebimento sozinho não valida os dados do provedor. Mantenha as entradas dependentes em espera até as verificações relevantes passarem.
Posso testar downloads de notícias ao vivo no testador MT4?
O testador documentado não executa WebRequest nem eventos Timer. Use entradas congeladas e com versão e um caminho suportado para testar a lógica comum; depois verifique separadamente em demo a busca e o agendamento reais.
Devo usar AutoTrading para pausar durante notícias?
Ele não se limita a novas entradas: também pode proibir solicitações automáticas usadas pelo gerenciamento. Aqui se discute um controle interno de entradas com responsabilidades de gerenciamento verificadas separadamente, não um interruptor universal para remover exposição.
12. Referências e escopo
A referência oficial MQL4 de WebRequest explica as solicitações síncronas e suas restrições. As limitações do Testador de Estratégias MT4 documentam a simulação de tempo e funções externas e eventos não suportados. Verifique as funções da sua plataforma e integração específicas, sem presumir compatibilidade com exemplos de outra plataforma. Referências verificadas em 2026-10-17.
Este guia conclui o grupo de guias de sessões e notícias com uma estrutura de regras e validação. Agendas, snapshots, idades e resultados são exemplos didáticos inventados. Os limites não são recomendações; não se afirma execução de EA nem resultado de negociação. Filtros não eliminam riscos de mercado, execução ou conta.