Erros, bugs, perguntas - página 2556

Novo comentário
 
Igor Makanu:

aqui@Vict ajudou a fazer uma excepção com a saída para OS via substituição de macros https://www.mql5.com/ru/forum/318246/page10#comment_12651045

uma solução geralmente exequível, mas... Mas parece assustador e nojento! )))

É uma verdadeira confusão... Para embrulhar retorno numa macro - é preciso saber muito sobre perversões ) Como lidar com tal código então... Devemos pelo menos tornar o nome da macro mais descritivo, como TRY_OR_RETURN
 
Alexey Navoykov:
Isto é realmente algo terrível. Seria preciso saber muito sobre perversões para embrulhar o retorno numa macro :) Como lidar com tal código então... Deveríamos pelo menos tornar o nome da macro mais descritivo - TRY_OR_RETURN, etc.

)))

Já vi como parece e não o uso, escrevo-o à moda antiga se(!myfunc()) voltar; em OnTick() - o código está todo cheio de ifs ... fica muito bonito e engraçado também ))))

 

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

Nova versão do MetaTrader 5 build 2085: integração com Python e melhorias maciças no testador de estratégia

Andrey Barinov, 2019.09.06 06:25

Ainda pode explicar por que razão existe agora um aviso neste código?

Os métodos têm assinaturas diferentes...

class A
  {
   public:
                     A(void) {}
                    ~A(void) {}
      //===============
      void           Test(void) {}
      //===============
  };
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+  
class B : public A
  {
   public:
                     B(void) {}
                    ~B (void) {}
      //===============
      void           Test(int a) {}
      //===============
  };
//+------------------------------------------------------------------+
//| Expert initialization function                                   |
//+------------------------------------------------------------------+
int OnInit()
  {
//---
   B b;

   b.Test(); //deprecated behavior, hidden method calling will be disabled in a future MQL compiler versions
   b.Test(5);
//---
   return(INIT_SUCCEEDED);
  }

 

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

Nova versão do MetaTrader 5 build 2085: integração com Python e melhorias maciças no testador de estratégia

Andrey Barinov, 2019.09.06 06:11

Nome tipográfico partido() na construção 2136

Por favor, conserte-o de volta.

enum eTest
  {
   TEST
  };
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
int OnInit()
  {
//---
   Alert(typename(eTest)); // eTest::eTest а правильно (и раньше так было) eTest
//---
   return(INIT_SUCCEEDED);
  }

nome tipográfico


 
@Ilyas

Este indicador bloqueia o sistema.
E com alteração da resolução do ecrã e com pixels intermitentes e reinicialização necessária do computador.
Além disso, se não chamar Crash() à função aparentemente inofensiva, não irá cair.
Reproduzido como se segue:

  • executar o indicador
  • começar a alterar o período de tempo até que haja alguns atrasos
  • depois disso, tentar minimizar o MT5



Joguei este crash cada vez que o fiz ( 6-8 vezes)

Arquivos anexados:
AnyTF.mq5  10 kb
iCanvas.mqh  21 kb
 
não falhou no LTSC, erro de registo: MemoryException 4424265936 bytes não disponíveis, 0 resultado heapmin

caiu, depois de mais algumas mudanças TF e o sistema mal arrancava, a roda da bota passou por 100 rotações, pensou que não iria arrancar, é melhor não verificar)
 
Fast235:
Não se despenhou no LTSC, o seguinte erro no registo: MemoryException 4424265936 bytes não disponíveis, 0 resultado heapmin

ainda me despistei após mais algumas mudanças TF e o sistema mal arrancava, a roda de carregamento passou por 100 rotações, não pensei que arrancasse, é melhor não a verificar)

Sim, o acidente é muito difícil. É melhor não correr quaisquer riscos.
É tudo uma questão de memória, claro.
Se limpar a memória desta forma:

int OnInit()
  {
   ChartSetInteger(0,CHART_FOREGROUND,false);
   if(erase)
      ChartSetInteger(0,CHART_SHOW,false);
   Canvas.Erase();
   Canvas.Comm("Идет загрузка всех тиков. Подождите пожалуйста");
   Canvas.Update();
   N=CopyTicks(_Symbol,ticks,COPY_TICKS_ALL,(TimeCurrent()-Weeks*7*24*60*60)*1000,INT_MAX);
   Print("Скачено "+string(N)+" тиков");
   if(N>0) N=CalculateNewTF(ticks,bars,TF);
   ArrayFree(ticks);
   Print("Сформировано "+string(N)+" баров");
   if(N>0) ShowBars(bars);
   Crash();
   return(INIT_SUCCEEDED);
  }
//+------------------------------------------------------------------+
void OnDeinit(const int reason) 
  {
    ArrayFree(bars); 
    if(erase) ChartSetInteger(0,CHART_SHOW,true); 
  }

também não cai. Pelo menos isso não me aconteceu.
Mas quando a TF está a ser mudada, as matrizes devem ser automaticamente limpas!

E não compreendo o que é que a função Crash() tem de fazer sem ela, porque lê apenas informação sobre indicadores.
Talvez, a execução desta função abrande o OnDeinit ao alterar a TF e é por isso que o MT5 não tem tempo para limpar a memória.
Temos tido problemas com o OnDeinit assíncrono há muito tempo. Não é bom! O sistema não deve falhar devido à assíncronia.

 

Porquê quando se percorre o gráfico com indicadores o processador carrega o núcleo a 100%?

Afinal, os indicadores foram calculados e desenhados, de acordo com a ideia, apenas a carga da memória deve ser.

 
Aleksey Vyazmikin:

Porquê quando se percorre o gráfico com indicadores o processador carrega o núcleo a 100%?

Afinal, os indicadores são calculados e desenhados, de acordo com a ideia, apenas a carga da memória deve ser.

A carga da CPU ao renderizar os gráficos depende directamente do desempenho da placa gráfica.

Em computadores portáteis antigos com cartões fracos ou em servidores sem placas de vídeo/condutores, haverá inevitavelmente um pico instantâneo mas breve na carga da CPU.

E o próprio CPU precisa de ser mais poderoso para consumir os pedidos crescentes sem deixar rasto.
 
Renat Fatkhullin:

A carga da CPU ao renderizar gráficos está directamente relacionada com o desempenho da placa de vídeo.

Em computadores portáteis mais antigos com cartões fracos ou em servidores sem placas de vídeo/condutores, haverá inevitavelmente um salto imediato mas curto na carga da CPU.

E o próprio CPU precisa de ser mais poderoso para consumir as crescentes exigências sem deixar rasto.

Estou a falar do processador FX-8350 e de uma placa gráfica Radeon HD 7950. Não tenho a sensação de que a placa de vídeo seja carregada pelo MT5.

1...254925502551255225532554255525562557255825592560256125622563...3184
Novo comentário