Ao dar um exemplo com IsStopped(), eu estava apenas tentando responder à primeira parte. Às vezes é necessário completar o processamento de um evento antes, e às vezes é urgente como no seu caso. Leia a descrição desta função IsStopped() na documentação, talvez ela leve a algumas idéias. Mas parece que é de outra direção. Se for o caso, desculpe por um possível palpite. Mas como dizem em possíveis sugestões, e resolve o problema. A solução definitiva não dirá a ninguém, porque ninguém conhece toda a lógica de seu código, e provavelmente não se aprofundará nela.
Roman, mais uma vez, você não está citando até o fim. E você o destacou entre todos os destacados.
Bem, está bem, digamos que um desligamento forçado é iniciado. E preciso que este evento de término seja executado até o final e a complexidade dos cálculos exceda 3 segundos. E como posso evitar o término do programa e deixar que ele seja executado até o fim? Esse é exatamente o problema. A conversa não foi sobre como terminar, mas como evitar uma terminação invocada de forma incorreta. Ou não para evitar, mas para adiar até um certo ponto, em particular até que o processamento do evento esteja completo.
será trabalhado exatamente da mesma maneira. E você terá novamente um "impasse". Mas o impasse não está em mql, mas em sua mente. Isto não é maneira de fazer programação. Antes de esperar qualquer coisa do código, imagine-se no lugar de um idiota e caminhe cegamente, como faz um computador, através de todo o código várias vezes. Certifique-se de onde a execução deve ser aprovada em um determinado caso. Quais parâmetros devem ser recebidos em um caso em particular. Em seguida, iniciar a execução e verificar se conseguimos o que esperamos. Se não, então devemos descobrir onde obtemos o que vemos durante o processo de depuração.
Não pode ser de outra forma. E é absolutamente impossível depurar os fragmentos do código.
Roman, mais uma vez, você não está citando até o fim. E você destacou entre todos os destacados.
Bem, está bem, digamos que uma rescisão forçada é acionada. E eu preciso de um evento em que esta rescisão seja acionada para ser executada até o final e a complexidade dos cálculos exceda 3 segundos. E como posso evitar o término do programa e deixar que ele chegue ao fim? Esse é exatamente o problema. A conversa não foi sobre como terminar, mas como evitar uma terminação invocada de forma incorreta. Ou não para prevenir, mas para atrasar até um certo ponto, em particular até que o processamento do evento esteja completo.
Temos de esperar que o cálculo seja concluído.
Infelizmente, o mql não contém funções como esperar. Podemos tentar experimentar com Sleep(), mas escorregar não é um sinal explícito de término, por isso não é muito adequado. Tente criar outra condição, se (o cálculo for executado), então já iniciaremos uma rescisão forçada.
será trabalhado exatamente da mesma maneira. E, mais uma vez, você terá um "impasse". Mas o impasse não está em mql, mas em sua mente. Não se pode entrar para uma programação como essa. Antes de esperar qualquer coisa do código, imagine-se no lugar de um idiota e caminhe cegamente, como faz um computador, através de todo o código várias vezes. Certifique-se de onde a execução deve ser aprovada em um determinado caso. Quais parâmetros devem ser recebidos em um caso em particular. Em seguida, iniciar a execução e verificar se conseguimos o que esperamos. Se não, então devemos descobrir onde obtemos o que vemos durante o processo de depuração.
Não pode ser de outra forma. Mas não se pode depurar o fragmento de código por fragmentos.
Bem, esse é o ponto é que tudo estava funcionando antes da atualização e agora eu simplesmente não sei o que fazer.
Além disso, todo o código é, em princípio, aberto.
Além disso, eu queria abrir um tópico para discutir o aperfeiçoamento de minha versão OnTester() e aqui está ela...
Como se viu, o problema não está nele, mas na execução do TesterStop() alterado. Na verdade, não tem conexão direta com a OnTester(), mas estragou meu humor...
Aí é que está, antes da atualização tudo funcionava, mas agora eu simplesmente não sei o que fazer.
Além disso, em princípio, todo o código é aberto.
Além disso, eu já queria abrir um tópico para discutir o aperfeiçoamento da minha versão OnTester() e aqui está ela...
Como se viu, o problema não está nele, mas na execução do TesterStop() alterado. Na verdade não está relacionado com a OnTester(), mas estragou meu humor...
Vou tentar outra coisa agora...
Você deu um link para construções anteriores. Substituir os arquivos e verificá-los. Então, você pode dizer a todos que obras de construção agora. Se não funcionar, isso significa que os parâmetros que não levaram a essa parte do código onde os problemas apareceram agora eram simplesmente os mesmos.
Assim, você tem uma ligação com as construções anteriores. Substituir os arquivos e verificar. Então, você pode dizer a todos quais são as obras de construção agora. Se não funcionar, significa que os parâmetros que não levam a esta parte do código, onde os problemas apareceram agora, foram simplesmente os mesmos.
Foi assim que eu tentei. Colocar a construção de 2007 e aí todos esses problemas desapareceram. Examinei especificamente todo o tronco após a otimização. Eu encontrei 4 (apenas 4 !) erros de divisão por zero. Essas foram as que ocorreram quando não havia negócios. É claro que isto precisava ser corrigido, mas não teve efeito no resultado geral da otimização! Mas a nova construção causou uma quantidade alarmante de erros e tornou a otimização impossível.
Obrigado, foi um bom trabalho. Mas no meu caso, parecia ser inútil para o TesterStop() porque o TesterStop() exige que o teste já tenha passado em alguma porcentagem desconhecida. E não há uma palavra sobre isso na documentação.
Mas funcionou bem com a ExsprtRemove(). Não importa para esta função quantos testes foram aprovados ali. Mas tivemos que embrulhar todo o código de trabalho no se
if(!IsStopped())
{
тут рабочий код
}
Bem, eu consegui consertar o código com muletas. Mais uma vez, obrigado.
P.S. Na verdade eu tinha que fazer uma muleta para outra muleta. Engraçado ))))
P.S. Na verdade, foi preciso fazer uma muleta para a outra muleta. Isso é engraçado ))))
Não acredito que não haja opções. Se você gosta de programar muletas para muletas, eu não tenho o direito de impedir. Slava respondeu sobre este assunto.
Interromper o Expert Advisor imediatamente significa corrupção da memória. Após uma parada imediata do Expert Advisor, pode haver bloqueios de memória não liberados. Portanto, a parada imediata do Expert Advisor só é usada quando o terminal do cliente ou o agente testador é encerrado e somente se o Expert Advisor não processar a bandeira de parada e continuar a execução.
O TesterStop dá o comando para terminar os testes. Isso significa que depois que o atual manipulador OnInit, OnTick, OnTimer, OnChartEvent estiver terminado, nenhum evento do testador será mais tratado, pois o ciclo de processamento está terminado. Em vez disso, OnTester e OnDeinit serão chamados.
Talvez, você tenha usado um bug na construção anterior. Agora este bug foi corrigido e temos que procurar uma solução adequada.
Foi assim que eu tentei. Colocar a construção de 2007 e aí todos esses problemas desapareceram. Examinei especificamente todo o tronco após a otimização. Eu encontrei 4 (apenas 4 !) erros de divisão por zero. Essas foram as que ocorreram quando não havia negócios. É claro que isto precisava ser corrigido, mas não teve efeito no resultado geral da otimização! Mas a nova construção causou uma quantidade alarmante de erros e tornou a otimização impossível.
Obrigado, foi um bom trabalho. Mas no meu caso, parecia ser inútil para o TesterStop() porque o TesterStop() exige que o teste já tenha passado em alguma porcentagem desconhecida. E não há uma palavra sobre isso na documentação.
Mas funcionou bem com a ExsprtRemove(). Não importa para esta função quantos testes foram aprovados ali. Mas tivemos que embrulhar todo o código de trabalho no se
Bem, eu consegui consertar o código com muletas. Mais uma vez, obrigado.
P.S. Na verdade eu tinha que fazer uma muleta para outra muleta. Engraçado ))))
Isto não é uma muleta, mas uma prática recomendada pelos desenvolvedores. Encontrei esta função na descrição do ciclo de tempo
while(!IsStopped())
{
}
É por isso que tive uma idéia: se esta função verificao fato do término forçado do programa, por que não usá-la para o TesterStop(). É uma pena que não funcione para o TesterStop(), saberemos disso agora. Mas é justo perguntar aos desenvolvedores se a funçãoIsStopped() deve funcionar para a função TesterStop()? Talvez seja um bug?
Não acredito que não haja opções. Se você gosta de programar muletas para muletas, eu não tenho o direito de interferir. Slava respondeu sobre este assunto
Talvez você tenha usado um deslize que os desenvolvedores fizeram na construção anterior. Agora este bug está consertado e temos que procurar uma solução adequada.
Eu entendo tudo e não preciso de muletas. E eu tive que procurar uma muleta aqui, lê-la para quê.
Talvez. Mas não me lembro de alguém reclamando sobre isso.
Neste contexto, não podemos fazer a verificação?
Infelizmente, este cheque não rendeu nada...
Ao dar um exemplo com IsStopped(), eu estava apenas tentando responder à primeira parte.
Às vezes é necessário completar o processamento de um evento antes, e às vezes é urgente como no seu caso.
Leia a descrição desta função IsStopped() na documentação, talvez ela leve a algumas idéias.
Mas parece que é de outra direção. Se for o caso, desculpe por um possível palpite.
Mas como dizem em possíveis sugestões, e resolve o problema.
A solução definitiva não dirá a ninguém, porque ninguém conhece toda a lógica de seu código, e provavelmente não se aprofundará nela.
Roman, mais uma vez, você não está citando até o fim. E você o destacou entre todos os destacados.
Bem, está bem, digamos que um desligamento forçado é iniciado. E preciso que este evento de término seja executado até o final e a complexidade dos cálculos exceda 3 segundos. E como posso evitar o término do programa e deixar que ele seja executado até o fim? Esse é exatamente o problema. A conversa não foi sobre como terminar, mas como evitar uma terminação invocada de forma incorreta. Ou não para evitar, mas para adiar até um certo ponto, em particular até que o processamento do evento esteja completo.
Aqui está uma verificação da sua opção. Acabou com uma mensagem como esta:
É um beco sem saída...
Portanto, a opção sugerida é
será trabalhado exatamente da mesma maneira. E você terá novamente um "impasse". Mas o impasse não está em mql, mas em sua mente. Isto não é maneira de fazer programação. Antes de esperar qualquer coisa do código, imagine-se no lugar de um idiota e caminhe cegamente, como faz um computador, através de todo o código várias vezes. Certifique-se de onde a execução deve ser aprovada em um determinado caso. Quais parâmetros devem ser recebidos em um caso em particular. Em seguida, iniciar a execução e verificar se conseguimos o que esperamos. Se não, então devemos descobrir onde obtemos o que vemos durante o processo de depuração.
Não pode ser de outra forma. E é absolutamente impossível depurar os fragmentos do código.
Roman, mais uma vez, você não está citando até o fim. E você destacou entre todos os destacados.
Bem, está bem, digamos que uma rescisão forçada é acionada. E eu preciso de um evento em que esta rescisão seja acionada para ser executada até o final e a complexidade dos cálculos exceda 3 segundos. E como posso evitar o término do programa e deixar que ele chegue ao fim? Esse é exatamente o problema. A conversa não foi sobre como terminar, mas como evitar uma terminação invocada de forma incorreta. Ou não para prevenir, mas para atrasar até um certo ponto, em particular até que o processamento do evento esteja completo.
Temos de esperar que o cálculo seja concluído.
Infelizmente, o mql não contém funções como esperar.
Podemos tentar experimentar com Sleep(), mas escorregar não é um sinal explícito de término, por isso não é muito adequado.
Tente criar outra condição, se (o cálculo for executado), então já iniciaremos uma rescisão forçada.
Portanto, a opção que estou propondo
será trabalhado exatamente da mesma maneira. E, mais uma vez, você terá um "impasse". Mas o impasse não está em mql, mas em sua mente. Não se pode entrar para uma programação como essa. Antes de esperar qualquer coisa do código, imagine-se no lugar de um idiota e caminhe cegamente, como faz um computador, através de todo o código várias vezes. Certifique-se de onde a execução deve ser aprovada em um determinado caso. Quais parâmetros devem ser recebidos em um caso em particular. Em seguida, iniciar a execução e verificar se conseguimos o que esperamos. Se não, então devemos descobrir onde obtemos o que vemos durante o processo de depuração.
Não pode ser de outra forma. Mas não se pode depurar o fragmento de código por fragmentos.
Bem, esse é o ponto é que tudo estava funcionando antes da atualização e agora eu simplesmente não sei o que fazer.
Além disso, todo o código é, em princípio, aberto.
Além disso, eu queria abrir um tópico para discutir o aperfeiçoamento de minha versão OnTester() e aqui está ela...
Como se viu, o problema não está nele, mas na execução do TesterStop() alterado. Na verdade, não tem conexão direta com a OnTester(), mas estragou meu humor...
Vou tentar outra coisa agora...
Aí é que está, antes da atualização tudo funcionava, mas agora eu simplesmente não sei o que fazer.
Além disso, em princípio, todo o código é aberto.
Além disso, eu já queria abrir um tópico para discutir o aperfeiçoamento da minha versão OnTester() e aqui está ela...
Como se viu, o problema não está nele, mas na execução do TesterStop() alterado. Na verdade não está relacionado com a OnTester(), mas estragou meu humor...
Vou tentar outra coisa agora...
Você deu um link para construções anteriores. Substituir os arquivos e verificá-los. Então, você pode dizer a todos que obras de construção agora. Se não funcionar, isso significa que os parâmetros que não levaram a essa parte do código onde os problemas apareceram agora eram simplesmente os mesmos.
Assim, você tem uma ligação com as construções anteriores. Substituir os arquivos e verificar. Então, você pode dizer a todos quais são as obras de construção agora. Se não funcionar, significa que os parâmetros que não levam a esta parte do código, onde os problemas apareceram agora, foram simplesmente os mesmos.
Foi assim que eu tentei. Colocar a construção de 2007 e aí todos esses problemas desapareceram. Examinei especificamente todo o tronco após a otimização. Eu encontrei 4 (apenas 4 !) erros de divisão por zero. Essas foram as que ocorreram quando não havia negócios. É claro que isto precisava ser corrigido, mas não teve efeito no resultado geral da otimização! Mas a nova construção causou uma quantidade alarmante de erros e tornou a otimização impossível.
Agora, a respeito da dica de@Roman.
Obrigado, foi um bom trabalho. Mas no meu caso, parecia ser inútil para o TesterStop() porque o TesterStop() exige que o teste já tenha passado em alguma porcentagem desconhecida. E não há uma palavra sobre isso na documentação.
Mas funcionou bem com a ExsprtRemove(). Não importa para esta função quantos testes foram aprovados ali. Mas tivemos que embrulhar todo o código de trabalho no se
Bem, eu consegui consertar o código com muletas. Mais uma vez, obrigado.
P.S. Na verdade eu tinha que fazer uma muleta para outra muleta. Engraçado ))))
P.S. Na verdade, foi preciso fazer uma muleta para a outra muleta. Isso é engraçado ))))
Não acredito que não haja opções. Se você gosta de programar muletas para muletas, eu não tenho o direito de impedir. Slava respondeu sobre este assunto.
Fórum sobre comércio, sistemas automatizados de comércio e testes estratégicos
Bichos, insetos, perguntas
Slava, 2019.06.16 14:04
Interromper o Expert Advisor imediatamente significa corrupção da memória. Após uma parada imediata do Expert Advisor, pode haver bloqueios de memória não liberados. Portanto, a parada imediata do Expert Advisor só é usada quando o terminal do cliente ou o agente testador é encerrado e somente se o Expert Advisor não processar a bandeira de parada e continuar a execução.
O TesterStop dá o comando para terminar os testes. Isso significa que depois que o atual manipulador OnInit, OnTick, OnTimer, OnChartEvent estiver terminado, nenhum evento do testador será mais tratado, pois o ciclo de processamento está terminado. Em vez disso, OnTester e OnDeinit serão chamados.
Foi assim que eu tentei. Colocar a construção de 2007 e aí todos esses problemas desapareceram. Examinei especificamente todo o tronco após a otimização. Eu encontrei 4 (apenas 4 !) erros de divisão por zero. Essas foram as que ocorreram quando não havia negócios. É claro que isto precisava ser corrigido, mas não teve efeito no resultado geral da otimização! Mas a nova construção causou uma quantidade alarmante de erros e tornou a otimização impossível.
Agora, a respeito da dica de@Roman.
Obrigado, foi um bom trabalho. Mas no meu caso, parecia ser inútil para o TesterStop() porque o TesterStop() exige que o teste já tenha passado em alguma porcentagem desconhecida. E não há uma palavra sobre isso na documentação.
Mas funcionou bem com a ExsprtRemove(). Não importa para esta função quantos testes foram aprovados ali. Mas tivemos que embrulhar todo o código de trabalho no se
Bem, eu consegui consertar o código com muletas. Mais uma vez, obrigado.
P.S. Na verdade eu tinha que fazer uma muleta para outra muleta. Engraçado ))))
Isto não é uma muleta, mas uma prática recomendada pelos desenvolvedores.
Encontrei esta função na descrição do ciclo de tempo
É por isso que tive uma idéia: se esta função verificao fato do término forçado do programa, por que não usá-la para o TesterStop().
É uma pena que não funcione para o TesterStop(), saberemos disso agora.
Mas é justo perguntar aos desenvolvedores se a funçãoIsStopped() deve funcionar para a função TesterStop()?
Talvez seja um bug?
Mas o principal é a solução para o problema.
Não acredito que não haja opções. Se você gosta de programar muletas para muletas, eu não tenho o direito de interferir. Slava respondeu sobre este assunto
Eu entendo tudo e não preciso de muletas. E eu tive que procurar uma muleta aqui, lê-la para quê.
Talvez. Mas não me lembro de alguém reclamando sobre isso.