Se for minutos, você pode comparar o tempo da última barra com o TimeCurrent(). Se não for M1, você pode perguntar ao iTime(_Symbol,PERÍODO_M1,0) e comparar com TimeCurrent().
Você pode comparar o Preço de Licitação ou Último preço (dependendo do símbolo) com o Preço de fechamento da última barra. Você pode pedir diretamente à SymbolInfoTick o símbolo atual. Além da Licitação e da Última, há também o tempo de carrapato
Obrigado, pelo menos algumas informações sobre onde e como procurar por bugs se algo deu errado.
mas eu acho, que todas as mesmas funções embutidas para verificar o status, ou melhor ainda, seria uma bandeira, como int _LastError, que armazenaria o número de carrapatos perdidos, seria conveniente ao chamar a OnCalculate() - em cálculos complexos, retornar imediatamente, para liberar o fluxo de símbolos
Obrigado, pelo menos algumas informações sobre onde e como procurar por bugs se algo deu errado.
mas eu acho, que todas as mesmas funções embutidas para verificar o status, ou melhor ainda, seria uma bandeira, como int _LastError, que armazenaria o número de carrapatos perdidos, seria conveniente ao chamar a OnCalculate() - em cálculos complexos, retornar imediatamente, para liberar o fluxo de símbolos
thought, pondered.... qual será o conhecimento dos carrapatos perdidos (Slava diz, que é garantido que o indicador recebe TODOS os carrapatos, e este fato leva a todos os pendências não só dos programas MQL, mas até mesmo do terminal do cliente)? em qualquer caso, esses carrapatos terão que ser coletados e processados, e isso significa, se perdemos um carrapato, por que de repente esperamos que da próxima vez isso seja possível? - é um círculo vicioso.
Eu estava pensando... talvez os desenvolvedores devam introduzir algo semelhante às exceções? A chegada de um novo tick deve interromper todas as operações, os cálculos no indicador naquele momento, e qualquer função MQL padrão deve retornar um erro durante sua execução, se um novo tick vier naquele momento... Então o trabalho com o indicador torna-se claro, conveniente e previsível. Para os outros tipos de programas (scripts, Expert Advisors) é quase desnecessário.
E todo tipo de verificações de carrapatos no indicador por sua relevância - para dizer de forma branda, esta não é a solução.
Temos uma idéia de indicadores, que não contêm a bandeira #property tester_everytick_calculate, para incluir o modo de cálculo com base no recebimento de um pacote de carrapatos, em vez de em cada carrapato.
Isto resolverá radicalmente o problema dos indicadores lentos, preservando a possibilidade de processamento garantido de cada tick para alguns indicadores.
Temos uma idéia de indicadores, que não contêm a bandeira #property tester_everytick_calculate, para incluir o modo de cálculo com base no recebimento de um pacote de carrapatos, em vez de em cada carrapato.
Isto resolverá dramaticamente o problema dos indicadores atrasados, preservando a possibilidade do processamento garantido de cada tick para alguns indicadores.
Então, você será capaz de ter um indicador muito rápido com tal design?
//+-------------------------------------------+intOnInit()
{
EventSetMillisecondTimer(200);
//-return(INIT_SUCCEEDED);
}
//+-------------------------------------------+intOnCalculate (constint rates_total,
constint prev_calculated,
constdatetime& time[],
constdouble& open[],
constdouble& high[],
constdouble& low[],
constdouble& close[],
constlong& tick_volume[],
constlong& volume[],
constint& spread[])
{
// Здесь ничего не делаем, нам не нужен в данном случае OnCalculatereturn(rates_total);
}
//+-------------------------------------------+voidOnTimer()
{
// Здесь расчёты, и вывод информации на график в виде графических объектов
}
Temos uma idéia de indicadores, que não contêm a bandeira #property tester_everytick_calculate, para incluir o modo de cálculo com base no recebimento de um pacote de carrapatos, em vez de em cada carrapato.
Isto resolverá radicalmente o problema dos indicadores lentos, preservando a possibilidade de processamento garantido de cada tick para alguns indicadores.
E se você fizer uma função padrão para obter uma matriz sincronizada de múltiplas moedas, será um verdadeiro feriado.
Temos uma idéia de indicadores, que não contêm a bandeira #property tester_everytick_calculate, para incluir o modo de cálculo com base no recebimento de um pacote de carrapatos, em vez de em cada carrapato.
Isto resolverá radicalmente o problema dos indicadores lentos, preservando a possibilidade do processamento garantido de cada tick para alguns indicadores.
Boa idéia!
E de preferência deve funcionar sem qualquer#propriedade por padrão.
Se alguém precisa disso de outra forma, então deixe-os colocar#propriedade.
A solução para receber carrapatos em pacotes é boa e provavelmente não muito cara, se não precisarmos de tempo real (mas não está claro como os EAs funcionarão com indicadores que funcionam a preços "de ontem", mas não importa).
Mas há outra classe de problemas - em tempo real, a cada tique. Neste caso, ou você tem tempo para fazer cálculos após o tique antes do próximo tique, ou não, e então a solução comercial não será relevante (não há terceira via). É por isso que existe apenas uma maneira correta de resolver o problema - interromper todos os cálculos atuais e retornar o erro quando um novo tick chegar. Caso contrário, podemos esquecer o tempo real. Agora os carrapatos estão ficando cada vez mais rápidos a cada dia, e é um longo caminho a percorrer, por isso é necessário planejar o futuro, sem mencionar o fato de que é impossível processar todos os carrapatos sem atrasos no tempo no presente.
_o0O: A solução para receber carrapatos em pacotes é boa e provavelmente não muito cara, se não precisarmos de tempo real (mas não está claro como os EAs funcionarão com indicadores que funcionam a preços "de ontem", mas não importa).
Mas há outro tipo de tarefas - em tempo real, a cada tique. Você tem tempo para fazer estimativas após o recebimento de um tick ou não, e a solução comercial será irrelevante (não há uma terceira alternativa). É por isso que existe apenas uma maneira correta de resolver o problema - interromper todos os cálculos atuais e retornar o erro quando um novo tick chegar. Caso contrário, pode-se esquecer o tempo real. Agora os carrapatos estão ficando cada vez mais rápidos a cada dia, e é um longo caminho a percorrer, por isso é necessário planejar o futuro, sem mencionar o fato de que é impossível processar todos os carrapatos sem atrasos no tempo no presente.
A maior parte dos indicadores EAs trabalha com barra fechada[1], por isso a omissão de carrapatos não importa, é real para indicadores que trabalham com carrapatos, mas não há muitos deles, para eles é possível alocar"#property tester_everytick_calculate".
E mais uma vez, se você precisar de super-pontas, não precisa de um indicador para isso, tudo isso pode ser escrito no código do Expert Advisor. Portanto, não é racional atrasar todo o trabalho do indicador para o bem de cada tique.
A maior parte dos indicadores EAs trabalha com barra fechada[1], por isso a omissão de carrapatos não importa, é real para os indicadores que trabalham com carrapatos, mas não há muitos deles, eles só podem ser atribuídos"#property tester_everytick_calculate".
E mais uma vez, se você precisar de super-pontas, não precisa de um indicador para isso, tudo isso pode ser escrito no código do Expert Advisor. Portanto, não é razoável retardar o trabalho do indicador para o bem de cada tique.
À espera de"#property tester_everytick_calculate"
OK, e como o que você disse discorda do que eu disse?
Pode ser útil para alguém. Tenho um indicador de múltiplas moedas, portanto os principais cálculos capacitivos que faço no bloco de inicialização e somente a renderização em oncalculus. Mas esta é uma solução para situações em que as próprias linhas indicadoras não contêm cálculos complexos. No meu caso é um indicador de carteira exibindo um gráfico de comportamento de carteira.
Para login e uso do site MQL5.com, você deve ativar o uso de cookies.
Ative esta opção no seu navegador, caso contrário você não poderá fazer login.
Você entrou na conta. A autenticação de dois fatores foi desativada. Configure-a novamente e escaneie um novo código QR ou continue com a autenticação de dois fatores desativada.
É possível tentar determinar.
Se for minutos, você pode comparar o tempo da última barra com o TimeCurrent(). Se não for M1, você pode perguntar ao iTime(_Symbol,PERÍODO_M1,0) e comparar com TimeCurrent().
Você pode comparar o Preço de Licitação ou Último preço (dependendo do símbolo) com o Preço de fechamento da última barra. Você pode pedir diretamente à SymbolInfoTick o símbolo atual. Além da Licitação e da Última, há também o tempo de carrapato
Obrigado, pelo menos algumas informações sobre onde e como procurar por bugs se algo deu errado.
mas eu acho, que todas as mesmas funções embutidas para verificar o status, ou melhor ainda, seria uma bandeira, como int _LastError, que armazenaria o número de carrapatos perdidos, seria conveniente ao chamar a OnCalculate() - em cálculos complexos, retornar imediatamente, para liberar o fluxo de símbolos
Obrigado, pelo menos algumas informações sobre onde e como procurar por bugs se algo deu errado.
mas eu acho, que todas as mesmas funções embutidas para verificar o status, ou melhor ainda, seria uma bandeira, como int _LastError, que armazenaria o número de carrapatos perdidos, seria conveniente ao chamar a OnCalculate() - em cálculos complexos, retornar imediatamente, para liberar o fluxo de símbolos
thought, pondered.... qual será o conhecimento dos carrapatos perdidos (Slava diz, que é garantido que o indicador recebe TODOS os carrapatos, e este fato leva a todos os pendências não só dos programas MQL, mas até mesmo do terminal do cliente)? em qualquer caso, esses carrapatos terão que ser coletados e processados, e isso significa, se perdemos um carrapato, por que de repente esperamos que da próxima vez isso seja possível? - é um círculo vicioso.
Eu estava pensando... talvez os desenvolvedores devam introduzir algo semelhante às exceções? A chegada de um novo tick deve interromper todas as operações, os cálculos no indicador naquele momento, e qualquer função MQL padrão deve retornar um erro durante sua execução, se um novo tick vier naquele momento... Então o trabalho com o indicador torna-se claro, conveniente e previsível. Para os outros tipos de programas (scripts, Expert Advisors) é quase desnecessário.
E todo tipo de verificações de carrapatos no indicador por sua relevância - para dizer de forma branda, esta não é a solução.
Temos uma idéia de indicadores, que não contêm a bandeira #property tester_everytick_calculate, para incluir o modo de cálculo com base no recebimento de um pacote de carrapatos, em vez de em cada carrapato.
Isto resolverá radicalmente o problema dos indicadores lentos, preservando a possibilidade de processamento garantido de cada tick para alguns indicadores.
Temos uma idéia de indicadores, que não contêm a bandeira #property tester_everytick_calculate, para incluir o modo de cálculo com base no recebimento de um pacote de carrapatos, em vez de em cada carrapato.
Isto resolverá dramaticamente o problema dos indicadores atrasados, preservando a possibilidade do processamento garantido de cada tick para alguns indicadores.
Então, você será capaz de ter um indicador muito rápido com tal design?
Se assim for, esta é uma ótima notícia!
Temos uma idéia de indicadores, que não contêm a bandeira #property tester_everytick_calculate, para incluir o modo de cálculo com base no recebimento de um pacote de carrapatos, em vez de em cada carrapato.
Isto resolverá radicalmente o problema dos indicadores lentos, preservando a possibilidade de processamento garantido de cada tick para alguns indicadores.
E se você fizer uma função padrão para obter uma matriz sincronizada de múltiplas moedas, será um verdadeiro feriado.
Temos uma idéia de indicadores, que não contêm a bandeira #property tester_everytick_calculate, para incluir o modo de cálculo com base no recebimento de um pacote de carrapatos, em vez de em cada carrapato.
Isto resolverá radicalmente o problema dos indicadores lentos, preservando a possibilidade do processamento garantido de cada tick para alguns indicadores.
Boa idéia!
E de preferência deve funcionar sem qualquer#propriedade por padrão.
Se alguém precisa disso de outra forma, então deixe-os colocar#propriedade.
Mas há outra classe de problemas - em tempo real, a cada tique. Neste caso, ou você tem tempo para fazer cálculos após o tique antes do próximo tique, ou não, e então a solução comercial não será relevante (não há terceira via). É por isso que existe apenas uma maneira correta de resolver o problema - interromper todos os cálculos atuais e retornar o erro quando um novo tick chegar. Caso contrário, podemos esquecer o tempo real. Agora os carrapatos estão ficando cada vez mais rápidos a cada dia, e é um longo caminho a percorrer, por isso é necessário planejar o futuro, sem mencionar o fato de que é impossível processar todos os carrapatos sem atrasos no tempo no presente.
A solução para receber carrapatos em pacotes é boa e provavelmente não muito cara, se não precisarmos de tempo real (mas não está claro como os EAs funcionarão com indicadores que funcionam a preços "de ontem", mas não importa).
Mas há outro tipo de tarefas - em tempo real, a cada tique. Você tem tempo para fazer estimativas após o recebimento de um tick ou não, e a solução comercial será irrelevante (não há uma terceira alternativa). É por isso que existe apenas uma maneira correta de resolver o problema - interromper todos os cálculos atuais e retornar o erro quando um novo tick chegar. Caso contrário, pode-se esquecer o tempo real. Agora os carrapatos estão ficando cada vez mais rápidos a cada dia, e é um longo caminho a percorrer, por isso é necessário planejar o futuro, sem mencionar o fato de que é impossível processar todos os carrapatos sem atrasos no tempo no presente.
A maior parte dos indicadores EAs trabalha com barra fechada[1], por isso a omissão de carrapatos não importa, é real para indicadores que trabalham com carrapatos, mas não há muitos deles, para eles é possível alocar"#property tester_everytick_calculate".
E mais uma vez, se você precisar de super-pontas, não precisa de um indicador para isso, tudo isso pode ser escrito no código do Expert Advisor. Portanto, não é racional atrasar todo o trabalho do indicador para o bem de cada tique.
Esperamos por"#property tester_everytick_calculate".
A maior parte dos indicadores EAs trabalha com barra fechada[1], por isso a omissão de carrapatos não importa, é real para os indicadores que trabalham com carrapatos, mas não há muitos deles, eles só podem ser atribuídos"#property tester_everytick_calculate".
E mais uma vez, se você precisar de super-pontas, não precisa de um indicador para isso, tudo isso pode ser escrito no código do Expert Advisor. Portanto, não é razoável retardar o trabalho do indicador para o bem de cada tique.
À espera de"#property tester_everytick_calculate"