Bibliotecas: Calendário - página 2
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
Em todos os calendários HTML (incluindo o padrão e o do Terminal), a tripla (Real, Previsão, Anterior) = (Real, Previsão, Revisado). Portanto, você não pode usar o campo Revisado no histórico até que ocorra o próximo evento correspondente. Os outros podem ser usados.
Não trabalhei com a API do calendário local - sua documentação deixa muito a desejar (portanto, seria necessária uma biblioteca mais lógica). Não é possível consultar uma matriz de alterações de eventos a partir do change_id especificado? Por algum motivo, não é baseado no tempo. Infelizmente, essas perguntas são mais para o calendário em si e não para a biblioteca, mas como a biblioteca está no topo do calendário, elas também permanecem abertas para ele. O problema com as alterações é que, em minha prática anterior de usar calendários externos, percebi que alguns campos podem ser ajustados retroativamente, por assim dizer, e é por isso que precisamos testar levando em conta a cronologia das alterações.
Não entendo como previous=revised(a estrutura MqlCalendarValue tem todos os 4 campos: actual, prev, revised, forecast) e por que não é possível usar revised no histórico - na minha opinião, revised pode aparecer (se previous for revised) a qualquer momento entre o lançamento do último evento e o próximo, ou seja, apenas no histórico.
Não trabalhei com a API do calendário local - sua documentação deixa muito a desejar (portanto, seria necessária uma biblioteca mais lógica). Não é possível consultar uma matriz de alterações de eventos a partir do change_id especificado? Por algum motivo, não há limite de tempo.
Cada alteração no calendário tem seu próprio change_id. Portanto, você pode consultar todas as alterações de um change_id específico até o change_id atual.
Não entendo como previous=revised(a estrutura MqlCalendarValue tem todos os 4 campos: actual, prev, revised, forecast) e por que você não pode usar revised no histórico - na minha opinião, revised pode aparecer (se previous for revised) a qualquer momento entre o último lançamento de evento e o próximo, ou seja, apenas no histórico.
Nos calendários, você só pode ver três campos para um evento. Na API, há quatro. Revisado é o valor de refinamento mais recente, que pode vir até mesmo uma semana após o recebimento do Real. Esse é o motivo da proibição, de certa forma lógica, de usar o Revised em backtests.
Vejo cenários bastante restritos de uso conveniente do calendário. Se você tiver suas próprias opções, fale com elas. Talvez a biblioteca tenha uma API que não seja ideal para seus cenários. Então pensaremos sobre isso.
O tópico parece ser bastante novo.
As funções GMT estão lá, mas não parecem estar sendo usadas. Não sei se elas são necessárias lá.
Elas são deixadas para o futuro. Já que o calendário está vinculado à hora do servidor e pode ser obtido de fora.
Eu vejo cenários bastante restritos de uso conveniente do calendário. Se você tiver suas próprias variantes, fale sobre elas. Talvez a biblioteca tenha uma API que não seja ideal para seus cenários. Então pensaremos no assunto.
O tópico parece ser bastante novo.
A julgar pela descrição dos recursos do calendário MT, deveríamos escrever algo como Observer com monitoramento de todas as alterações e a chegada de novos eventos por assinatura e alterações em Actual, Revised.
Então, acho que poderia ser conveniente.
A julgar pela descrição dos recursos do calendário MT, deveríamos escrever algo como Observador com monitoramento de todas as alterações e a chegada de novos eventos na assinatura e alterações nos valores de Real, Revisado.
Terminologicamente, não entendo.
Em termos terminológicos, não entendo.
https://refactoring.guru/ru/design-patterns/observer
https://refactoring.guru/ru/design-patterns/observer
Obrigado. Se estivermos falando de OnCalendar, será necessário algum tipo de simulação por meio do mecanismo change_id.
É melhor demonstrar os cenários de aplicativos com código esquemático, é claro.
Obrigado. Se estivermos falando de OnCalendar, haverá alguma simulação por meio do mecanismo change_id.
Você está falando de simulação de eventos de calendário, que podem ser introduzidos no MT5 no futuro.
Eu estava me referindo ao mecanismo de assinatura dos eventos de interesse, incluindo a mudança do Revised, já que ele pode mudar a qualquer momento.
Se você não estiver familiarizado com o padrão Observer, recomendo que leia o link do Andrei.
A essência da ideia é resumidamente essa, por exemplo:
Preciso conhecer todos os eventos do EUR com importância superior a 3 para negociação. Eu me inscrevo em um provedor (um objeto da classe que gerencia assinaturas e alertas, também chamado de editor, pode ser um único) e assino.
Em seguida, o próprio provedor monitora todas as alterações nos eventos nos quais estou interessado e me notifica (chamando o método de processamento de eventos com as informações correspondentes).
A essência da ideia é, em resumo, que, por exemplo:
Preciso saber todos os eventos de EUR de importância superior a 3 para negociar. Entro em contato com um provedor (objeto da classe que gerencia assinaturas e alertas, também chamado de editor, pode ser único), assino.
Em seguida, o próprio provedor monitora todas as alterações nos eventos nos quais estou interessado e me notifica (chamando o método de processamento de eventos com as informações correspondentes).
Nenhum objeto personalizado pode verificar a si mesmo sem uma chamada correspondente. Ou seja, ele deve ser escrito pelo usuário em seu código. Se ele o tiver escrito, ele mesmo fará o processamento.
O mecanismo change_id é muito simples: você executa o método Refresh. Depois disso, você obtém os dados, o que e onde foi atualizado na lista de eventos que você criou.