Discussão do artigo "Ordens, posições e negócios no MetaTrader 5"
Depois de ler, não encontrei a melhor resposta para essa pergunta.
Como carregar no cache, por exemplo, apenas uma última ordem do histórico (para complicar a tarefa, deixe a última por símbolo).
Por exemplo, o consultor tem uma frequência diferente de ordens. Ele pode fazer 30 ordens por dia e pode ficar "silencioso" por vários dias ou semanas.
Há variantes após o envio de uma ordem ao servidor para lembrar seu tíquete em algum lugar e, em seguida, recuperar essa ordem por tíquete - sem problemas. É possível memorizar tanto em variáveis globais quanto dentro da lógica do EA. Mas aqui está o problema se, por exemplo, o Expert Advisor se conectar à conta de outro terminal e não tiver um tíquete da última ordem.
Tenho que carregar o histórico por meio do HistorySelect. A data final é mais ou menos clara, mas como calcular a data inicial.
Porque mesmo em um intervalo pequeno é possível obter vários pedidos - o que não é um problema, mas não é o ideal em termos de carregamento de dados desnecessários. Ou nenhum deles pode se enquadrar no intervalo.
Você pode pegar um intervalo de datas ainda menor e fazer um loop (deslocar o intervalo para o histórico) para preencher o cache - não é o ideal em termos de lógica de trabalho - loops extras, consultas ao banco de dados do histórico.
Proposta - organizar o carregamento da quantidade necessária por ordens/negociações por instrumento.
E mais: se o objetivo do artigo fosse mostrar os algoritmos ideais de acesso a ordens/negociações/posições. Acho que, se formos mais longe em termos de otimização, seria bom ter um modo de carregar dados do histórico no cache por campos, por exemplo, somente os tíquetes e a hora de envio da ordem para o servidor são necessários, por que então carregar todos os outros dados desse intervalo para essas ordens (mágica, comentário e muito mais).
select * from HistiryOrder where a_date_send>@datestart and a_date_send<@dateend
Para aqueles que desenvolvem aplicativos de DBMS, acho que uma consulta desse tipo não seria aprovada para uso em produção. É verdade que há situações em que todos os dados estão envolvidos em algumas ações, mas isso é uma exceção e não uma regra.
Depois de ler, não encontrei a melhor resposta para essa pergunta.
Como carregar no cache, por exemplo, apenas uma última ordem do histórico (para complicar a tarefa, deixe a última por símbolo).
Por exemplo, o consultor tem uma frequência diferente de ordens. Ele pode fazer 30 ordens por dia e pode ficar "silencioso" por vários dias ou semanas.
Há variantes após o envio de uma ordem ao servidor para lembrar seu tíquete em algum lugar e, em seguida, recuperar essa ordem por tíquete - sem problemas. É possível memorizar tanto em variáveis globais quanto dentro da lógica do EA. Mas aqui está o problema se, por exemplo, o Expert Advisor se conectar à conta de outro terminal e não tiver um tíquete da última ordem.
Tenho que carregar o histórico por meio do HistorySelect. A data final é mais ou menos clara, mas como calcular a data inicial.
Porque mesmo em um intervalo pequeno é possível obter vários pedidos - o que não é um problema, mas não é o ideal em termos de carregamento de dados desnecessários. Ou nenhum deles pode se enquadrar no intervalo.
Você pode pegar um intervalo de datas ainda menor e fazer um loop (deslocar o intervalo para o histórico) para preencher o cache - não é o ideal em termos de lógica de trabalho - loops extras, consultas ao banco de dados do histórico.
Proposta - organizar o carregamento da quantidade necessária por ordens/negociações por instrumento.
E mais: se o objetivo do artigo fosse mostrar os algoritmos ideais de acesso a ordens/negociações/posições. Acho que, se formos mais longe em termos de otimização, seria bom ter um modo de carregar dados do histórico no cache por campos, por exemplo, somente os tíquetes e a hora de envio da ordem para o servidor são necessários, por que então carregar todos os outros dados desse intervalo para essas ordens (mágica, comentário e muito mais).
select * from HistiryOrder where a_date_send>@datestart and a_date_send<@dateend
Para aqueles que desenvolvem aplicativos de DBMS, acho que uma consulta desse tipo não seria aprovada para uso em produção. É verdade que há situações em que todos os dados estão envolvidos em algumas ações, mas isso é uma exceção e não uma regra.
Carregar e processar até mesmo um histórico muito grande não levará muito tempo. Outra coisa é que se esse carregamento for realizado a cada tick, isso já é um problema.
Mesmo um histórico muito grande será processado em alguns segundos. Portanto, a primeira conclusão é reduzir o número de carregamentos completos.
Inicie o carregamento completo do histórico em OnInit(). Lembre-se das datas necessárias. Depois, você pode girar a história "como um cigano com o sol" em OnTicket().
Carregar e processar até mesmo um histórico muito grande não levará muito tempo. Outro aspecto é que, se esse carregamento for realizado a cada tick, isso já será um problema.
Mesmo um histórico muito grande será processado em alguns segundos. Portanto, a primeira conclusão é reduzir o número de carregamentos completos.
Inicie o carregamento completo do histórico em OnInit(). Lembre-se das datas necessárias. Depois disso, você pode girar a história "como um cigano com o sol" em OnTicket().
Para ser mais específico, o histórico deve ser totalmente carregado somente no bloco de inicialização e nos fins de semana (nos fins de semana, você também deve otimizar os parâmetros).
Um aspecto que me confundiu foi o fato de o texto conter muitos avisos sobre a necessidade de carregar o histórico no cache com moderação (cuidadosamente), mas não há nenhum exemplo real de como implementar essa tarefa. Isso me incomodou bastante:
//--- definir o limite inicial para 3 dias atrás datetime start=end-3*PeriodSeconds(PERIOD_D1);
Esse código (abordagem) será realmente usado em qualquer Expert Advisor normal? A menos que estejamos falando de uma tarefa simples específica (por exemplo, encontrar ordens para vários dias), e então - com reservas (nesse exemplo, os fins de semana não são levados em conta, portanto, o código não é adequado para processar vários dias de negociação ), a abordagem não resiste a nenhuma crítica.
No entanto, existem todas as ferramentas para implementar o carregamento econômico. E, no que me diz respeito, um exemplo dessa implementação deveria estar no artigo.
Por exemplo, usando este modelo:
- OnInit() - carregamento de todo o histórico no cache, busca da última ordem significativa para o Expert Advisor (por exemplo, por meijik ou apenas por instrumento), salvando seu tempo em uma variável.
- OnTrade() - atualiza o histórico carregado no cache (a partir do tempo memorizado), atualiza o tempo da última ordem (se uma nova ordem significativa tiver aparecido).
- OnTick() - trabalhar com o cache carregado atualmente ou, se necessário, carregar o cache a partir do horário memorizado.
Essa abordagem já é sinônimo de estabilidade e universalidade. Além disso, em termos de utilização de recursos, ela pode se tornar ainda mais econômica do que "selecionar os últimos 3 dias".
De qualquer forma, obrigado novamente pelo artigo. Essas "especificações dos desenvolvedores" são necessárias, caso contrário, não haverá código normal.
O artigo dá um exemplo de carregamento do histórico de negociação de um dia (um código tem um exemplo de carregamento do histórico de 3 dias). Sim, essa é uma limitação e o exemplo não é universal. Mas se o leitor entender essa peculiaridade ao ler o artigo, ele poderá decidir por si mesmo a questão - para qual intervalo e a partir de qual momento ele precisa carregar o histórico de negociação no cache.
O leitor recebeu os exemplos e algoritmos mais simples e agora pode aplicá-los de forma independente nas funções de processamento de eventos necessárias. Ele pode criar de forma independente sua própria base de histórico de negociação e fazer sua inicialização e sincronização, e assim por diante.
Uma tentativa de fornecer receitas e funções específicas para o trabalho ideal com o histórico de negociação para todos os casos exigirá pelo menos mais um artigo. Mais precisamente, não os exemplos em si, mas as abordagens para resolver determinadas tarefas. O objetivo deste artigo foi entender como funcionam as funções de negociação e quais nuances devem ser observadas para não desperdiçar seu próprio tempo em pesquisas.
Tenho certeza de que, depois de ler este artigo, tudo ficará mais simples.
Você pode me dizer se há uma descrição da operação do terminal no modo OfLine em algum lugar? O problema é que não consegui carregar o terminal devido à falta de atualização dos dados do gráfico. Eu queria testá-lo no trabalho (não há Internet lá), mas não consegui: os gráficos estão aguardando a atualização e não há um único símbolo no testador. O artigo diz que, depois de iniciar o terminal, a sincronização de dados com o servidor é realizada. Mas o que acontece se não houver conexão (na verdade, isso não deveria acontecer). Talvez faça sentido dizer explicitamente ao terminal que ele deve funcionar no OfLine e não girar essa roda infeliz. Talvez haja menos falhas no trabalho do testador. Para ser justo, é preciso dizer que não tenho esse problema há muito tempo, mas as pessoas reclamam dele no fórum. Talvez haja alguns truques (bem, há algum arquivo a ser removido) para resolver a situação (eu tentei - nada ajudou até que eu estabelecesse conexão com o servidor em casa).
- www.mql5.com
Após a transferência do catálogo do terminal para o novo equipamento, parte dos bancos de dados de configuração (símbolos, configurações de conta, histórico de transações etc.) é especialmente excluída porque é criptografada por chaves com fio. O histórico de gráficos não é afetado.
Isso significa que, após a migração, você precisa se conectar a qualquer conta de negociação pelo menos uma vez para permitir que o terminal ajuste o ambiente de mercado. Depois disso, você pode apagar a senha, desconectar-se da Internet e trabalhar com o testador off-line.
Após a transferência do catálogo do terminal para o novo equipamento, parte dos bancos de dados de configuração (símbolos, configurações de conta, histórico de transações etc.) é especialmente excluída porque é criptografada por chaves com fio. O histórico de gráficos não é afetado.
Isso significa que, após a migração, você precisa se conectar a qualquer conta de negociação pelo menos uma vez para permitir que o terminal ajuste o ambiente de mercado. Depois disso, você pode apagar a senha, desconectar-se da Internet e trabalhar com o testador off-line.
Eu não movi nem mudei nada. Apenas vim trabalhar com meu laptop e quis testar o Expert Advisor. Tenho uma conta e, naturalmente, tentei fazer login, mas o registro diz que não há conexão com o servidor. Talvez tenha sido apenas uma falha aleatória, mas não consegui fazer nada.
Não mexi nem mudei nada. Apenas vim trabalhar com meu laptop e quis testar o EA. Tenho uma conta e, naturalmente, tentei fazer login, mas o registro diz que não há conexão com o servidor. Talvez seja apenas uma falha aleatória, mas não consegui fazer nada.
Forneça uma captura de tela completa de toda a janela do terminal, incluindo todas as zonas do Market Watch, do gráfico e do testador.
Tente se conectar à conta em casa, extraia os dados completamente e execute pelo menos um teste. Em seguida, desconecte-se da Internet, reinicie o terminal e tente novamente.
Forneça uma captura de tela completa de toda a janela do terminal, incluindo todas as zonas do Market Watch, do gráfico e do testador.
Tente se conectar à conta em casa, faça o download completo dos dados e execute pelo menos um teste. Depois disso, desconecte-se da Internet, reinicie o terminal e tente novamente.
Isso não exige nada, pois tudo funciona como antes. Aparentemente, foi uma falha acidental. Anteriormente, o terminal solicitava autorização, mas agora ele inicia sem ela. Verifiquei cerca de 10 vezes com e sem reiniciar o computador. Está tudo bem, obrigado.
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Você concorda com a política do site e com os termos de uso
Novo artigo Ordens, posições e negócios no MetaTrader 5 foi publicado:
A criação robusta de um robô de negócio não pode ser feita sem um entendimento dos mecanismos do sistema de negócio do MetaTrader 5. O terminal do cliente recebe as informações sobre as posições, ordens e negócios a partir do servidor de negócio. Para manipular estes dados adequadamente utilizando o MQL5, é necessário ter um bom entendimento da interação entre o programa MQL5 e o terminal do cliente.
Autor: MetaQuotes Software Corp.