Bibliotheken: Init_Sync

Neuer Kommentar
 

Init_Sync:

Die Bibliothek synchronisiert Init/Deinit von Indikatoren

Autor: fxsaber

 
Und jetzt - ein super-duper Mega-Frage: Was ist das Leben Kontext von Ressourcen in MQL5 erstellt? Das ganze Terminal, irgendwelche internen Container wie "Symbol-Zeitrahmen"-Streams, Charts oder etwas anderes? Es steht nichts darüber in der Hilfe.
 
Stanislav Korotky:
Und jetzt - ein super-duper Mega-Frage: Was ist das Leben Kontext von Ressourcen in MQL5 erstellt? Das ganze Terminal, irgendwelche internen Container wie "Symbol-Zeitrahmen"-Streams, Charts oder etwas anderes? In der Hilfe steht nichts darüber.
Ich habe es nicht überprüft

Forum zum Thema Handel, automatisierte Handelssysteme und Testen von Handelsstrategien

Sequenz der Init() und DeInit() Ausführung

Nikolai Semko, 2017.04.16 09:42 AM

Natürlich Ressourcen - sie scheinen mir die optimale Lösung zu sein, denn sie sind unsichtbar, im Gegensatz zu glob. terminalen Variablen und Dateien, und schnell. Und außerdem kann man über sie Arrays übertragen, genauso wie über Dateien, nur schneller, weil alles im RAM passiert. Und auch sie gehören zum Fenster, nicht zum Terminal, wie im Falle der globalen. Außerdem kann man eine Ressource für alle dieselben Indikatoren im Fenster erstellen.

Ich habe es einfach geglaubt, deshalb habe ich es über Ressourcen gemacht. Ursprünglich waren es globale Indikatoren.

 
fxsaber:
Ich habe es nicht getestet

Ich habe es einfach geglaubt, also habe ich es über die Ressourcen gemacht. Ursprünglich war es durch Global.

Es wäre interessant, einige offizielle Quelle der Informationen zu hören.
 
Und noch eine Frage: Was passiert, wenn ein Indikator aus einem Expert Advisor erstellt wird?
 
Stanislav Korotky:
Und noch eine Frage: Was passiert, wenn ein Indikator aus einem Expert Advisor erstellt wird?
Versuchen Sie dies.
 

Hmmm...

Interessante Funktionsüberschreibungen...

Wie funktioniert das? Nehmen wir die Initialisierungsfunktion als Beispiel ?

Also...

Da die Bibliothek zuerst eingefügt wird, wird beim Kompilieren OnInit() der Bibliothek als Initialisierungsfunktion registriert.

Sie prüft die Synchronisation und ruft dann die Funktion OldOnInit() auf. Was ist diese Funktion? Sie ist noch nicht definiert!


Aha... Später, wenn die "alte" OnInit()-Funktion definiert ist, wird sie durch OldOnInit() ersetzt - dieselbe Funktion, die von der OnInit() der Bibliothek aufgerufen wird.


Hmm. Die ursprüngliche Verwendung von Defines. Meiner Meinung nach ziemlich gefährlich, was die weitere Unterstützung und die Möglichkeiten zur Änderung der Reihenfolge der Deklaration von Bezeichnern angeht. (Ich hatte den Eindruck, dass man keine nicht deklarierten Bezeichner verwenden kann). Aber vom Standpunkt der Verwendung aus ist alles sauber und korrekt.

 
George Merts:

Meiner Meinung nach ziemlich gefährlich, was die weitere Unterstützung und die Möglichkeiten zur Änderung der Reihenfolge der Deklaration von Bezeichnern angeht.

Ich habe kein gefährliches Beispiel gefunden.


Soweit ich mich erinnere, ist dies die einzige derartige Bibliothek, in der #include vorhanden ist, aber nirgendwo im Code wird etwas daraus vom Benutzer aufgerufen.

 
fxsaber:
Ich habe es nicht getestet

Ich habe es einfach geglaubt, also habe ich es über die Ressourcen gemacht. Ursprünglich war es global.


Ich entschuldige mich dafür. Ich wurde in die Irre geführt.

Wenn Sie einen leeren Indikator mit einem solchen OnInit verwenden (ohne die Ressource zu löschen):

int OnInit()
  {
   uint set[1];
   set[0]=3;
   uint w=1,h=1;
   if(ResourceReadImage("::Res_name",set,w,h))
      Print("Ressource existiert bereits set[0] = "+DoubleToString(set[0],0));
   else
     {
      if(ResourceCreate("::Res_name",set,1,1,0,0,0,COLOR_FORMAT_XRGB_NOALPHA))
         Print("Es wurde eine neue Ressource erstellt".);
      else Print("Es konnte keine Ressource erstellt werden.");
     }

   return(INIT_SUCCEEDED);
  }

können Sie die folgenden Schlüsse über die Ressource ziehen:

1. Die Ressource gehört zum Terminal, nicht zum Fenster. Daher ist es sinnvoll, dem Ressourcennamen z.B. ein Fensterhandle hinzuzufügen.

2. Die Lebensdauer der Ressource ist so lang, wie das Terminal aktiv ist, und die Ressource wird gelöscht, wenn das Terminal neu gestartet wird. Daher wäre es sinnvoll, die notwendigen Daten in der globalen Variable des Terminals (oder in der Datei über ResourceSave) zu speichern, wenn das Terminal geschlossen wird (der Grundcode ist REASON_CLOSE), und wenn das Terminal wieder geladen wird, eine neue Ressource zu erstellen, indem die Daten aus dem globalen PT (oder der Datei) übertragen werden, mit dem anschließenden Löschen des globalen PT (oder der Datei), so dass sie nicht stören (dann wird die globale Variable des Terminals nur zum Zeitpunkt des Schließens und Öffnens des Terminals existieren).

Auf der einen Seite ist das gut, weil es interessante Möglichkeiten der Datenübertragung und Synchronisation zwischen Fenstern und generell allem im Terminal gibt, aber auf der anderen Seite fügt es Code und einige Komplikationen hinzu.
Sorry nochmal für die Weitergabe von ungeprüften Informationen.

Aber jetzt gibt es Klarheit bei schlecht dokumentierten Ressourcen. Und, nebenbei bemerkt, ein sehr wertvolles Werkzeug.

 
Nikolai Semko:

Die Ressource gehört zum Terminal, nicht zum Fenster. Daher ist es sinnvoll, dem Ressourcennamen z. B. ein Fensterhandle hinzuzufügen.

Fügen Sie dann Folgendes in den Code ein
return("::" + (string)::ChartID() + (string)INIT_SYNC::crc64(Bytes) + ::MQLInfoString(MQL_PROGRAM_NAME));

Es scheint, dass nichts weiter benötigt wird.


Übrigens kann es in manchen Situationen sinnvoll sein, auf das Fensterhandle zu verzichten, wenn die Indikatorkopie EINS für das gesamte Terminal sein soll.


ZY Die aktualisierte Version enthält diese Korrektur.

 
fxsaber:

Übrigens, vielleicht, ohne Fensterhandle kann in einigen Situationen bequem sein, wenn der Indikator Kopie sollte ONE für das gesamte Terminal sein.


Ja, ich habe auch darüber nachgedacht

12
Neuer Kommentar