Erros, bugs, perguntas - página 2437

 
Alexey Navoykov:

Então OnTesterPass é chamado sem quadros presentes? Bem, então este é um erro óbvio. Este evento significa receber um quadro, não o fim de um passe.

Todas as molduras devem chegar ao OnTesterPass antes do evento OnTesterDeinit ser chamado. Esta é uma lógica saudável normal. A menos que, mais uma vez, estejamos a falar de uma interrupção forçada do teste.

OnTesterPass é chamado quando pelo menos uma moldura tiver chegado. Pode vir num pacote de molduras. Portanto, a OnTesterPass deve aceitar quadros em loop, e não um quadro de cada vez. Mas se "depois da última vez - nunca", OnTesterPass não é chamado.

A optimização pára quando chega o último resultado. Os quadros podem chegar mais tarde, especialmente se uma grande quantidade de dados for passada num quadro, ou se vários quadros forem passados de uma só vez num passe. Portanto, precisamos de organizar a recepção dos restantes quadros no OnTesterDeinit, que é lançado depois de a optimização ter terminado - também no loop.

Esta é uma lógica saudável normal.

Dei repetidamente exemplos de recepção de quadros exactamente no OnTesterDeinit, e não apenas no OnTesterPass. E é a recepção de quadros complexos de diferentes tipos

 
Slava:

se vários quadros forem passados de uma só vez em uma passagem.

Tentei isto uma vez, não funcionou. Apenas um FrameAdd funcionou.

 
Slava:

A optimização pára quando chega o último resultado. Os quadros podem chegar mais tarde, especialmente se uma grande quantidade de dados for transferida num quadro ou se vários quadros forem transferidos de uma só vez numa passagem. Por conseguinte, é necessário organizar a recepção dos restantes quadros no OnTesterDeinit, que é lançado quando a optimização termina - também no loop.

Se os quadros podem chegar mais tarde, não há garantia de que também chegarão de imediato ao OnTesterDeinit? isto é, é preciso fazer um laço para esperar quanto tempo?

Pensei anteriormente que a situação era a seguinte: OnTesterPass é chamado apenas para os quadros que chegaram desde o fim do OnTesterPass anterior, mas se um novo quadro chegou enquanto o OnTesterPass estava em progresso, e especificamente - desde a última chamada do FrameNext e antes da conclusão da função, este quadro ficará pendurado, até que um novo quadro gerador do evento chegue. É por isso que a OnTesterDeinit é obrigada a receber estas armações inactivas.

 
Alexey Navoykov:

Se os quadros podem chegar mais tarde, então não há garantia de que estarão imediatamente disponíveis no OnTesterDeinit? isto é, tem de fazer um ciclo de espera? E quanto tempo deve esperar?

Pensei anteriormente que a situação era a seguinte: OnTesterPass é chamado apenas para os quadros que chegaram desde o fim do OnTesterPass anterior, mas se um novo quadro chegou enquanto o OnTesterPass estava em progresso, e especificamente - desde a última chamada do FrameNext e antes da conclusão da função, este quadro ficará pendurado, até que um novo quadro gerador do evento chegue. É por isso que a OnTesterDeinit é obrigada a apanhar estas armações inactivas.

FrameNext é um ficheiro mqd idiota lido e nada mais.

FrameFirst é FileSeek.
 
fxsaber:

Experimentei isto uma vez, mas não funcionou. Apenas um FrameAdd funcionou.

Mostrei aqui um exemplo.
 

Obrigado.


O PS FrameFirst é redundante aqui

Fórum sobre comércio, sistemas de comércio automatizados e testes estratégicos

Estratégias de teste dentro do calendário previsto com a autosubstituição do resultado ao Consultor Especialista

Slava, 2013.04.10 15:04

Aqui está um exemplo. Na OnTester, o consultor especializado envia dois quadros - a história dos negócios e a história em que estava a trabalhar.

No OnTesterDeinit, recebe e processa todos os quadros do primeiro e do segundo tipos

void OnTesterDeinit()
  {
   string        name;
   ulong         pass;
   long          id;
   double        value;
   int           handle,i;
   BalanceInTime balance[];
   MqlRates      rates[];
//---
   FrameFirst();
   FrameFilter("",1);
   while(FrameNext(pass,name,id,value,balance))
     {
      handle=FileOpen(name+"_"+string(id)+"_"+IntegerToString(pass,5,'0')+".txt",FILE_WRITE|FILE_CSV|FILE_ANSI);
      if(handle!=INVALID_HANDLE)
        {
         for(i=0; i<ArraySize(balance); i++)
            FileWrite(handle,balance[i].date,EnumToString(balance[i].entry),DoubleToString(balance[i].price,5),DoubleToString(balance[i].balance,2));
         FileClose(handle);
        }
     }
//---
   FrameFirst();
   FrameFilter("",2);
   while(FrameNext(pass,name,id,value,rates))
     {
      handle=FileOpen(name+"_"+string(id)+"_"+IntegerToString(pass,5,'0')+".txt",FILE_WRITE|FILE_CSV|FILE_ANSI);
      if(handle!=INVALID_HANDLE)
        {
         for(i=0; i<ArraySize(rates); i++)
            FileWrite(handle,rates[i].time,DoubleToString(rates[i].open,5),DoubleToString(rates[i].high,5),DoubleToString(rates[i].low,5),DoubleToString(rates[i].close,5),string(rates[i].tick_volume));
         FileClose(handle);
        }
     }
//---
  }
 
fxsaber:


O PS FrameFirst é supérfluo aqui.

Não. Não supérfluo - puramente metodológico. Um bloco completo de código sem qualquer defeito

Este código foi arrancado de um código mais complexo. Foram transmitidos quatro tipos de moldura diferentes. Ao mesmo tempo, lemos também OnTesterPass. Aqui está o código "refinado".

 
Slava:

Não. Não redundante - puramente metodológico. Um bloco completo de código sem qualquer defeito

Este código foi arrancado de um código mais complexo. Foram transmitidos quatro tipos de moldura diferentes. Ao mesmo tempo, lemos também OnTesterPass. Aqui apresentamos o código "refinado".

Sobre o FrameFirst é sempre supérfluo se for chamado antes do FrameFilter.

Não recomendaria a transferência de dados através de mais do que um quadro.

 
fxsaber:

Sobre o FrameFirst é sempre redundante se for chamado antes do FrameFilter.

Não recomendaria a passagem de dados através de mais do que um quadro.

1. Sim, pode ser supérfluo.

2. um tipo de molduras é lido em OnTesterPass e terminado em OnTesterDeinit. Os outros quadros são lidos em OnTesterDeinit

Esta possibilidade de enviar e receber vários tipos de quadros permitiu-nos corrigir vários erros que eram difíceis de reproduzir no testador. E os quadros só foram transmitidos se houvesse uma diferença com algum valor de referência.

 
Slava:

Abrirá o opt-format?