Errori, bug, domande - pagina 2556

 
Igor Makanu:

qui@Vict ha aiutato a fare un'eccezione con l'uscita al sistema operativo tramite la sostituzione della macro https://www.mql5.com/ru/forum/318246/page10#comment_12651045

, una soluzione generalmente praticabile, ma... Ma ha un aspetto inquietante e disgustoso! )))

È un vero casino... Per avvolgere il ritorno in una macro - devi sapere un sacco di perversioni ) Come trattare tale codice allora... Dovresti almeno rendere il nome della macro più descrittivo, come TRY_OR_RETURN
 
Alexey Navoykov:
Questo è davvero qualcosa di terribile. Bisognerebbe conoscere molto bene le perversioni per avvolgere il ritorno in una macro :) Come trattare tale codice allora... Dovremmo almeno rendere il nome della macro più descrittivo - TRY_OR_RETURN, ecc.

)))

Ho visto come appare e non lo uso, lo scrivo alla vecchia maniera if(!myfunc()) return; in OnTick() - il codice è tutto pieno di if ... sembra piuttosto carino e anche divertente ))))

 

Forum sul trading, sistemi di trading automatico e test di strategie di trading

Nuova versione di MetaTrader 5 build 2085: integrazione con Python e massicci miglioramenti nello strategy tester

Andrey Barinov, 2019.09.06 06:25

Puoi ancora spiegare perché ora c'è un avvertimento in questo codice?

I metodi hanno firme diverse...

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

 

Forum sul trading, sistemi di trading automatico e test di strategie di trading

Nuova versione di MetaTrader 5 build 2085: integrazione con Python e massicci miglioramenti nello strategy tester

Andrey Barinov, 2019.09.06 06:11

typename() rotto nella build 2136

Per favore, rimettilo a posto.

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

typename


 
@Ilyas

Questo indicatore blocca il sistema.
E con cambio di risoluzione dello schermo e con pixel lampeggianti e necessario riavvio del computer.
Inoltre, se non chiamate la funzione apparentemente innocua Crash() non andrete in crash.
Riprodotto come segue:

  • eseguire l'indicatore
  • iniziare a cambiare l'orizzonte temporale fino a quando ci sono dei ritardi
  • dopo di che provare a ridurre al minimo MT5



Ha giocato questo incidente ogni volta che l'ho fatto (6-8 volte)

File:
AnyTF.mq5  10 kb
iCanvas.mqh  21 kb
 
non è andato in crash su LTSC, errore di log: MemoryException 4424265936 byte non disponibili, risultato 0 heapmin

è andato in crash, dopo qualche altro cambio di TF e il sistema si è avviato a malapena, la ruota di avvio ha fatto 100 giri, pensavo che non si sarebbe avviato, meglio non controllare)
 
Fast235:
Non è andato in crash su LTSC, il seguente errore nel log: MemoryException 4424265936 byte non disponibili, 0 risultato heapmin

Sono ancora caduto dopo qualche altro cambio di TF e il sistema si è avviato a malapena, la ruota di caricamento ha fatto 100 giri, non pensavo che si sarebbe avviato, meglio non controllarlo)

Sì, l'incidente è molto difficile. Meglio non correre rischi.
È tutta una questione di memoria, ovviamente.
Se si pulisce la memoria in questo modo

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

non si blocca nemmeno. Almeno non è successo a me.
Ma quando il TF viene cambiato, gli array devono essere puliti automaticamente!

E non capisco cosa abbia a che fare la funzione Crash() senza di essa, perché legge solo informazioni sugli indicatori.
Forse, l'esecuzione di questa funzione rallenta OnDeinit quando si cambia il TF ed è per questo che MT5 non ha il tempo di cancellare la memoria.
Abbiamo avuto problemi con OnDeinit asincrono per molto tempo. Non è buono! Il sistema non deve bloccarsi a causa dell'asincronia...

 

Perché quando si scorre il grafico con gli indicatori il processore carica il core al 100%?

Dopo tutto, gli indicatori sono stati calcolati e disegnati, secondo l'idea, solo il carico dalla memoria dovrebbe essere.

 
Aleksey Vyazmikin:

Perché quando si scorre il grafico con gli indicatori il processore carica il core al 100%?

Dopo tutto, gli indicatori sono calcolati e disegnati, secondo l'idea, solo il carico dalla memoria dovrebbe essere.

Il carico della CPU durante il rendering dei grafici dipende direttamente dalle prestazioni della scheda grafica.

Su vecchi portatili con schede deboli o su server senza schede video/driver ci sarà inevitabilmente un picco istantaneo ma breve nel carico della CPU.

E la CPU stessa deve essere più potente per assorbire le richieste aumentate senza lasciare traccia.
 
Renat Fatkhullin:

Il carico della CPU durante il rendering dei grafici è direttamente collegato alle prestazioni della scheda video.

Sui vecchi portatili con schede deboli o sui server senza schede video/driver ci sarà inevitabilmente un salto immediato ma breve nel carico della CPU.

E la CPU stessa deve essere più potente per assorbire le maggiori richieste senza lasciare traccia.

Sto parlando del processore FX-8350 e di una scheda grafica Radeon HD 7950. Non ho la sensazione che la scheda video sia caricata da MT5.

Motivazione: