Errores, fallos, preguntas - página 2556

Nuevo comentario
 
Igor Makanu:

aquí@Vict ayudó a hacer una excepción con la salida al sistema operativo a través de la sustitución de macros https://www.mql5.com/ru/forum/318246/page10#comment_12651045

...una solución generalmente factible, pero... ¡Pero se ve espeluznante y asqueroso! )))

Es un verdadero desastre... Para envolver el retorno en una macro - hay que saber mucho de perversiones ) Cómo tratar ese código entonces... Deberíamos al menos hacer el nombre de la macro más descriptivo, como TRY_OR_RETURN
 
Alexey Navoykov:
Esto es realmente algo horrible. Habría que saber mucho de perversiones para envolver el retorno en una macro :) Cómo tratar ese código entonces... Deberíamos al menos hacer el nombre de la macro más descriptivo - TRY_OR_RETURN, etc.

)))

He visto cómo queda y no lo uso, lo escribo a la antigua usanza if(!myfunc()) return; en OnTick() - el código está todo lleno de ifs ... se ve muy lindo y divertido también ))))

 

Foro sobre trading, sistemas de trading automatizados y pruebas de estrategias de trading

Nueva versión de MetaTrader 5 build 2085: integración con Python y mejoras masivas en el probador de estrategias

Andrey Barinov, 2019.09.06 06:25

¿Aún puede explicar por qué hay una advertencia en este código ahora?

Los métodos tienen diferentes firmas...

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);
  }

 

Foro sobre trading, sistemas de trading automatizados y pruebas de estrategias de trading

Nueva versión de MetaTrader 5 build 2085: integración con Python y mejoras masivas en el probador de estrategias

Andrey Barinov, 2019.09.06 06:11

Tipename() roto en la compilación 2136

Por favor, vuelve a arreglarlo.

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

typename


 
@Ilyas

Este indicador bloquea el sistema.
Y con el cambio de resolución de la pantalla y con el parpadeo de los píxeles y el necesario reinicio del ordenador.
Además, si no llamas a la aparentemente inofensiva función Crash() no te estrellarás.
Reproducido como sigue:

  • ejecutar el indicador
  • empezar a cambiar el marco temporal hasta que haya algunos desfases
  • después de eso tratar de minimizar MT5



Se ha estrellado cada vez que lo he hecho (6-8 veces)

Archivos adjuntos:
AnyTF.mq5  10 kb
iCanvas.mqh  21 kb
 
no se estrelló en LTSC, error de registro: MemoryException 4424265936 bytes no disponibles, 0 resultado de heapmin

sí que se estrelló, después de algunos cambios más de TF y el sistema apenas arrancó, la rueda de arranque pasó por 100 vueltas, pensó que no arrancaría, mejor no comprobarlo)
 
Fast235:
No se estrelló en LTSC, el siguiente error en el registro: MemoryException 4424265936 bytes not available, 0 heapmin result

aun asi me estrello despues de unos cuantos cambios de TF y el sistema apenas arranco, la rueda de carga dio 100 vueltas, no crei que fuera a arrancar, mejor no comprobarlo)

Sí, el choque es muy duro. Es mejor no arriesgarse.
Se trata de la memoria, por supuesto.
Si limpias la memoria así:

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); 
  }

tampoco se bloquea. En cualquier caso, no me ha funcionado.
Pero cuando se modifica el TF, ¡las matrices deben limpiarse automáticamente!

Y no entiendo qué tiene que ver la función Crash() sin ella, porque sólo lee información sobre los indicadores.
Tal vez, la ejecución de esta función ralentiza OnDeinit al cambiar el TF y por eso MT5 no tiene tiempo para limpiar la memoria.
Hemos tenido problemas con OnDeinit asíncrono durante mucho tiempo. ¡No es bueno! El sistema no debe fallar debido a la asincronía...

 

¿Por qué cuando se desplaza el gráfico con indicadores el procesador carga el núcleo al 100%?

Después de todo, los indicadores se han calculado y dibujado, de acuerdo con la idea, sólo la carga de la memoria debe ser.

 
Aleksey Vyazmikin:

¿Por qué cuando se desplaza el gráfico con indicadores el procesador carga el núcleo al 100%?

Después de todo, los indicadores se calculan y dibujan, de acuerdo con la idea, sólo la carga de la memoria debe ser.

La carga de la CPU al renderizar gráficos depende directamente del rendimiento de la tarjeta gráfica.

En los portátiles viejos con tarjetas débiles o en los servidores sin tarjetas de vídeo/drivers se producirá inevitablemente un pico instantáneo pero breve en la carga de la CPU.

Y la propia CPU tiene que ser más potente para poder absorber el aumento de peticiones sin dejar rastro.
 
Renat Fatkhullin:

La carga de la CPU al renderizar gráficos está directamente relacionada con el rendimiento de la tarjeta de vídeo.

En los portátiles más antiguos con tarjetas débiles o en los servidores sin tarjetas de vídeo/drivers se producirá inevitablemente un salto inmediato pero corto en la carga de la CPU.

Y la propia CPU tiene que ser más potente para absorber el aumento de la demanda sin dejar rastro.

Me refiero al procesador FX-8350 y a una tarjeta gráfica Radeon HD 7950. No me da la sensación de que la tarjeta de vídeo esté cargada por MT5.

1...254925502551255225532554255525562557255825592560256125622563...3187
Nuevo comentario