Init() und DeInit() Ausführungsreihenfolge - Seite 7
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Wenn sich der Zeitrahmen innerhalb eines Symbols ändert, ist die Reihenfolge der Initialisierung und Deinitialisierung im Prinzip vorhersehbar. Laden Sie den neuesten Build 1580 herunter - wir haben dort einige Dinge korrigiert, jetzt werden die Indikatoren zuletzt entfernt, so dass es keine vorzeitige Deiniteration mehr geben sollte.
Indikatoren gibt es in allen Formen und Größen. Auch die gebremsten. Und nicht alle von ihnen sind ihre eigenen und im Quellcode.
Ein paar Sekunden sind lustig. Die Schnittstelle fühlt sich Dutzende von Millisekunden, Unbehagen sofort erscheint.
Verstehen Sie das nicht falsch. Es geht nicht um die Schnittstelle, sondern um die Transienten - die TF-Umschaltung. Dauert das Umschalten der TF auf einer leeren Karte unendlich lange? Nein. Dann haben die Indikatoren nichts damit zu tun.
Und vor allem: Es gibt keine Antwort auf meine Frage:
In welchen Situationen, abgesehen von der einfachen Arbeit mit grafischen Objekten (ohne einen TF-Namen im Namen), ist die DeInit-Init-Sequenz wichtig?
In fast allen Situationen. Es sei denn, wir haben es mit Spielzeugen vom Typ MAshek und ähnlichen Primitiven zu tun:
Einverstanden. Andere Probleme als das zweite sind lösbar, wenn man sie kennt. Das heißt, wir müssen jetzt die gesamte Logik in OnCalculate packen, während Init und DeInit nicht verwendet werden sollten. Aber wozu brauchen wir sie dann?
Wie auch immer, wir sprechen jetzt nicht von plattformübergreifender Zusammenarbeit. Es hat sich herausgestellt, dass MT4 und MT5 unterschiedliche Ansätze für Init und DeInit haben.
Wenn es nicht um die Finanzen ginge, gäbe es vielleicht keine solche Diskussion.
Und da ein Trading Advisor von dem einen oder anderen Indikator abhängt, wird er bei einem einfachen Wechsel der TF einfach nicht mehr richtig funktionieren. Das ist das, was am stressigsten ist.
Wie können Sie ihm also Ihre Finanzen anvertrauen?
In dieser Frage sind wir vielleicht mit den MT-Entwicklern uneins.Es gibt eine Vielzahl von Möglichkeiten, dieses Problem zu lösen. Und fast alle davon wurden in diesem Thread geäußert.
1. Wenn der Indikator vom Expert Advisor geschrieben wird, sollte der Expert Advisor so geschrieben werden, dass er nicht von Periodenänderungen des Charts beeinflusst wird. Der Indikator wird also nicht neu initialisiert.
2. Wenn Sie beim Deinitieren grafische Objekte löschen oder das Design des Diagramms ändern müssen, prüfen Sie den Grund für die Deinitialisierung.
3) Wenn der Indikator einige Parameter speichern muss, dann sollten diese Daten, wie bereits erwähnt, nicht bei Deinit gespeichert werden, sondern wenn diese Daten vorbereitet oder geändert werden.
4) Wähle von zwei Haufen Mist immer den, der weniger stinkt. Wenn ich also zwischen der Geschwindigkeit, von der ALLE Indikatoren abhängen, und der Komplexität der Speicherung einiger Daten in MEHREREN Indikatoren wählen muss, entscheide ich mich für die Geschwindigkeit.
Das verstehe ich nicht. Bitte klären Sie das. Wird das Deinit nach dem Init garantiert?
Wenn der Zeitrahmenwechsel nach unten geht, wird zuerst OnInit auf dem niedrigeren (neuen) Zeitrahmen und dann OnDeinit auf dem höheren (alten) Zeitrahmen ausgeführt.
Wenn der Schalter nach oben geht, ist es umgekehrt. Zuerst OnDeinit auf dem unteren (alten) Zeitrahmen und dann OnInit auf dem oberen (neuen) Zeitrahmen.
Dabei ist zu beachten, dass die Caches vom niedrigsten zum höchsten Zeitrahmen abgearbeitet werden
Laden Sie den neuesten Build 1580 herunter - wir haben dort einige Dinge korrigiert, die Indikatoren werden jetzt zuletzt entfernt, so dass es keine vorzeitige Deiniteration mehr geben sollte.
:(( Oh Mann, das sind "gute Nachrichten". Jetzt muss ich vielleicht den Code in einigen Programmen neu schreiben, weil er für die umgekehrte Reihenfolge konzipiert wurde - erst Deunit, dann Unit.
Um ehrlich zu sein, ist das eine seltsame Logik. Das bedeutet, dass die alte und die neue Indikatorkopie eine Zeit lang eindeutig zusammenleben, bis die Einheit in der neuen Indikatorkopie zuerst ausgeführt wird und danach Deunit in der alten. Zu diesem Zeitpunkt gibt es keine Möglichkeit, die neue Kopie über Deunit über einige Informationen zu informieren. Dies ist offensichtlich ein Chaos. Denn Einheiten sind in der Regel viel umständlicher als Einheiten. Warum eine so seltsame Reihenfolge der Ausführung! Dann wird dieses Thema immer wieder neu belebt werden. Aber wenn der Programmierer im Indikator einige Variablen erstellen könnte, die beim Wechsel der TF nicht neu initialisiert werden, dann sollten wir uns mit dieser Sequenz von OnInit und OnDeinit befassen. Ich habe schon ein paar Mal darüber geschrieben(1 und 2). Ich stimme mit der Logik der Entwickler überein, dass Zeiger und Referenzen aus Sicherheitsgründen kein Luxus für Programmierer sind, aber wenn Sie einen Mechanismus eines speziellen Typs von gemeinsam genutzten Variablen für alle Kopien des Indikators schaffen, müssen wir denselben Mechanismus für alle Kopien des Indikators schaffen. Der Indikator ist derselbe, die Indikatoreigenschaften werden "irgendwo" gespeichert.
Wenn der Zeitrahmenschalter ausfällt, wird zuerst OnInit auf den niedrigsten (neuen) Zeitrahmen und dann OnDeinit auf den höchsten (alten) Zeitrahmen angewendet.
Wenn der Schalter nach oben geht, ist es umgekehrt. Zuerst OnDeinit auf dem unteren (alten) Zeitrahmen und dann OnInit auf dem oberen (neuen) Zeitrahmen.
Dabei ist zu beachten, dass die Caches von unten nach oben abgearbeitet werden
Dies ist noch verwirrender.
Denn wenn der Indikator nicht vom Autor selbst verwendet wird, kann er nach Belieben wechseln, ohne auf init und deinit zu warten? Und was wird geschehen? Und wenn für eine Variante des Schalters in deinit einige Aktionen notwendig sind, dann macht es keinen Unterschied, ob es für eine Richtung des Schalters oder für beide Richtungen geschrieben ist. Aber sie haben Bremsen für die "schweren" Blinker hinzugefügt.
Dies ist noch verwirrender.
Schließlich, wenn der Indikator nicht vom Autor selbst verwendet wird, dann kann er wechseln, wie er will und ohne auf das init und deinit zu warten? Und was wird passieren??? Und wenn für eine Variante des Schalters in deinit einige Aktionen notwendig sind, dann macht es keinen Unterschied, ob es für eine Richtung des Schalters oder für beide Richtungen geschrieben ist. Aber sie haben Bremsen für "schwere" Blinker hinzugefügt.
Wo wurden die Bremsen hinzugefügt? Was haben sie im Vergleich dazu hinzugefügt?
Bitte unterstützen Sie Ihre Aussagen mit Code, damit jeder sie nachvollziehen kann.
Noch einmal. Da beim Wechselder Symbolperiode eine weitere Kopie des Indikators erstellt wird, ist die Reihenfolge von OnInit bei der neuen Symbolperiode und OnDeinit bei der alten Symbolperiode undefiniert
Wo wurden die Bremsen hinzugefügt? Was haben Sie im Vergleich dazu hinzugefügt?
Seien Sie so freundlich, Ihre Behauptungen mit Code zu belegen, damit jeder sie nachvollziehen kann.
Noch einmal. Da beim Ändern einer Symbolperiode eine weitere Kopiedes Indikators erstellt wird, ist die Reihenfolge der Ausführung von OnInit für die neue Symbolperiode und OnDeinit für die alte Symbolperiode undefiniert
In dieser Nachricht
Wenn das Umschalten der Zeitrahmen scheitert, dann zuerst OnInit auf dem jüngsten (neuen) Zeitrahmen und dann OnDeinit auf dem ältesten (älteren) Zeitrahmen.
Wenn der Schalter nach oben geht, dann ist es genau umgekehrt. Zuerst OnDeinit für den unteren (älteren) Zeitrahmen und dann OnInit für den oberen (neueren) Zeitrahmen.
Sie sollten bedenken, dass die Caches von einem Zeitrahmen niedriger Ordnung zu einem Zeitrahmen hoher Ordnung verarbeitet werden.
Haben Sie es so gesagt, wie es ist, oder wie Sie es bei der Vorbereitung des Neubaus getan haben?
Wenn ja, dann habe ich mich geirrt und nehme es zurück.
In dieser Nachricht.
Sagten Sie, so wie es ist oder so wie es gemacht wird, um einen Neubau vorzubereiten?
Wenn es so ist, habe ich es falsch verstanden und nehme es zurück.
Dies ist in Build 1580 der Fall.
Davor erfolgte die Deinitialisierung bei Zeitrahmenwechsel fast immer früher. Aber nur wenn der Zeitrahmenschalter ausfällt, wurde die Deinitialisierung mit Code 1 durchgeführt, nicht mit Code 3, wie es sein sollte
Dies ist in Build 1580 geschehen.
Davor erfolgte die Deinitialisierung beim Wechsel des Zeitrahmens fast immer früher. Aber nur wenn der Zeitrahmenschalter ausfällt, wurde die Deinitialisierung mit Code 1 und nicht wie vorgesehen mit Code 3 durchgeführt.
Wie kann man dann diese Codes der Deinitialisierung in Inite des Indikators verarbeiten, was bewirken diese Codes? Da es keine Möglichkeit gibt, im Indikator zu warten, funktioniert Sleep nicht.