Init() und DeInit() Ausführungsreihenfolge - Seite 4
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
In Deinit alle Daten in Globals schreiben. Setzen Sie eine der Globals als Semaphore überGlobalVariableSetOnCondition.
In Init write, dass, wenn die Semaphore im "data dumped"-Status ist, wir lesen und arbeiten, indem wir die Semaphore auf "read all"-Status setzen.
Wenn die Semaphore "unverständlich" ist, warten wir einfach auf die Semaphore (entweder durch eine Schleife Sleep oder OnTimer).
Wenn es überhaupt keine Semaphore gibt, bedeutet das, dass wir zum ersten Mal starten und alles zählen und gleichzeitig eine Semaphore für den nicht zukünftigen Wechsel der TF erstellen.
Was ist so kompliziert an einer solchen Umsetzung? Einmal mit einer Bibliothek verschreiben und das war's.
Wenn Schlaf in Indikatoren arbeiten würde, wäre es einfacher. Schlaf funktioniert nicht über Indikatoren.
Multipliziert man die Anzahl der kleinen Leute, die - jeder für sich, immer und immer wieder - ein gemeinsames Problem lösen sollen, dann übersteigen die verschwendeten Arbeitsstunden um ein Vielfaches (im Grenzfall um ein unendliches Vielfaches ;-)) die Zeit, die für jede Variante der Bearbeitung im Terminal selbst benötigt wird. Selbst das Vorhandensein einer hypothetischen Bibliothek garantiert nicht, dass jeder von ihrer Existenz weiß und sie nutzen muss. Im Allgemeinen ist nicht klar, warum eine solche "Harke" zu machen und zu verlassen?
Es handelt sich also nicht um einen Fehler, sondern um ein logisches Verhalten, wenn die neue Kopie des Indikators die alte nicht kennt. Das ist logisch!
Aber EINE Tausendschaft von Leuten wünscht sich zusätzliche Funktionen, damit die Kopie es auch weiß! Was hindert diese Einheiten also daran, eine Lösung einmal zu schreiben und sie dann zu verwenden?
Warum so tun, als ob man sich um andere Menschen kümmert. Wer es wirklich braucht, wird zuerst nach einer Lösung suchen. Und wenn sie das nicht tun, werden sie versuchen, einen zu schreiben. Eine zentralisierte Codebasis dient genau diesem Zweck.
Wenn Sleep in den Indikatoren arbeiten würde, wäre es einfacher. Schlaf funktioniert nicht über Indikatoren.
Es handelt sich also nicht um einen Fehler, sondern um ein logisches Verhalten, wenn die neue Kopie des Indikators die alte nicht kennt. Das ist logisch!
Aber EINE Tausendschaft von Leuten wünscht sich zusätzliche Funktionen, damit die Kopie es auch weiß! Was hindert diese Einheiten also daran, eine Lösung einmal zu schreiben und sie dann zu verwenden?
Warum so tun, als ob man sich um andere Menschen kümmert. Wer es wirklich braucht, wird zuerst nach einer Lösung suchen. Und wenn sie das nicht tun, werden sie versuchen, einen zu schreiben. Eine zentralisierte kodobase dient genau diesem Zweck.
Nein, so einfach ist das nicht. Die Indikatoren befinden sich innerhalb einer anderen Entität - einem Diagramm - und sind diesem untergeordnet (ich bin mir ihrer komplexen Eins-zu-Viel-Beziehung bewusst, aber das ändert nichts am Kern der Sache). Ein Diagramm hat seinen eigenen Lebenszyklus, der eine Art von internen Init- und Deinit-Ereignissen umfasst, die die Grenzen für den Lebenszyklus der Indikatoren bilden. Mit anderen Worten: Ein Indikator kann sein Diagramm nicht überdauern. Das Deinit des Diagramms muss auf das Deinit oder Timeout des Deinits aller Indikatoren warten. Erst dann kann das Chart-Init für den neuen Zeitrahmen gestartet werden, und von dort aus können die Inits der angehängten Indikatoren aufgerufen werden.
Eine Harke ist per Definition etwas, auf das man treten kann. Bereits betreten. Eine gute Software lässt grundsätzlich keinen Rake zu.
Es handelt sich also nicht um einen Fehler, sondern um ein logisches Verhalten , wenn die neue Kopie des Indikators die alte nicht kennt. Das ist logisch!
Aber EINE Tausendschaft von Leuten wünscht sich zusätzliche Funktionen, damit die Kopie es auch weiß! Was hindert diese Einheiten also daran, eine Lösung einmal zu schreiben und sie dann zu verwenden?
Warum so tun, als ob man sich um andere Menschen kümmert. Wer es wirklich braucht, wird zuerst nach einer Lösung suchen. Und wenn sie das nicht tun, werden sie versuchen, einen zu schreiben. Eine zentralisierte kodobase dient genau demselben Zweck.
Wie kommt es, dass Sie nicht wissen, wann Sie den Zeitrahmen wechseln und die Eingabeparameter erneut eingeben?
Und dann wird Deinit sein Werk vollenden und alles verderben. Es macht keinen Sinn, ein reguläres Init und Deinit zu verwenden, wenn Sie Ihr eigenes Init und Deinit erstellen.
Dieses Problem ist auch bei mir aufgetreten. (
Ich habe Ihnen bereits allesgesagt, aber ich werde noch etwas hinzufügen.
Die Besonderheit aller Programme für MT ist, dass sie auf der Grundlage von Ereignissen arbeiten. OnInit und OnDeinit funktionieren ganz logisch und angemessen nach dem Ereignismodell.
Es gibt jedoch eine merkwürdige Nuance im Verhalten der Eingabevariablen: Alle Basisindikatoren, einschließlich der internen Terminalindikatoren und der in der Standardauslieferung enthaltenen Indikatoren, werden jedes Mal mit denselben Eingabeparametern gestartet, die seit dem letzten Start aufgerufen wurden. Das ist sehr praktisch. Aber für benutzerdefinierte Indikatoren und alle Expert Advisors und Skripte, einschließlich der Standardindikatoren, gibt es so etwas nicht, was eine gewisse Unannehmlichkeit darstellt(Wunsch an MQ: dasselbe Verhalten für Eingabevariablen wie für Standardindikatoren hinzufügen).
Und was die Arbeit mit Init und Deinit betrifft, so habe ich mich persönlich nie auf Gründe der Deinitialisierung von Programmen festgelegt, wenn ich mit globalen Variablen des Programms arbeite, ich baue die Logik immer nach der spezifischen Idee des Programms. Zum Beispiel ist es sehr oft notwendig, die globalen Variablen eines Programms nach der Deinitialisierung eines EA zu speichern (die Gründe können unterschiedlich sein, z.B. verursacht dieselbe Unterbrechung OnDeinit und das nachfolgende OnInit), warum also alles noch einmal neu berechnen und neue Indikator-Handles erstellen, usw.?
Das ist der Grund, warum, wie ich zuvor und fxsaber schrieb, wenn Sie globale Variablen eines Programms in einigen Fällen speichern müssen - Sie können es in globalen Variablen des Terminals mit den entsprechenden Flags tun.
Leider läuft in MQL nicht alles glatt, aber die Arbeit von OnInit und Ondeinit ist logisch und verständlich, so dass es keine Zeitverschwendung ist).
Was meinen Sie damit, dass Sie nicht wissen, ob Sie beim Wechsel des Zeitrahmens die Eingabeparameter erneut eingeben müssen?
Aber die Funktionsweise von OnInit und Ondeinit ist logisch und verständlich, so dass es keinen Grund gibt, eine große Sache daraus zu machen).
Bitte erklären Sie die Logik der Abfolge von OnInit und OnDeinit im Indikator, wenn Sie den Zeitrahmen wechseln. Dafür wäre ich sehr dankbar. Und ich glaube, ich bin nicht der Einzige.
Bitte erklären Sie die Logik der Abfolge der OnInit- und OnDeinit-Operationen im Indikator, wenn Sie den Zeitrahmen wechseln. Ich wäre Ihnen sehr dankbar. Und ich glaube, ich bin nicht der Einzige.
Herr Slava hat es deutlich gesagt.
Es wird eine Kopie des Indikators erstellt und der alte Indikator wird nach einiger Zeit entladen.
Wenn wir globale Variablen des Programms speichern wollen, sollten wir das schon vorher beim Aufruf von OnInit erledigen (globale Variablen des Client-Terminals sind für diesen Zweck gut geeignet).
Und die Indikatorpuffer werden sowieso neu berechnet, weil sich die Balken (Candlesticks) geändert haben, deshalb passiert das so (die Kopie wird gestartet und die vorherige Indikatorinstanz wird vom Terminal beendet).
Wenn der Entwickler des Indikators das Problem in der Arbeit mit grafischen Objekten sieht, dann ist es am Anfang des Indikators notwendig, die Namen der grafischen Objekte an den Namen der TF zu binden, dann wird die neue Kopie des Indikators neue Objekte erstellen, und die vorherige Kopie des Indikators wird die alten Objekte bereinigen.
Überhaupt kein Problem.
Forum zum Thema Handel, automatisierte Handelssysteme und Testen von Handelsstrategien
Init() und DeInit() Ausführungsreihenfolge
Slawa, 2017.04.07 15:31
Welche Art von Logik wird dabei durcheinander gebracht?
Wenn Sie den Zeitrahmen wechseln, wird eine neue Kopie des Indikators erstellt, die nichts über die vorherige Kopie weiß. Eine Zeit lang (eine sehr kurze Zeit) existieren beide Kopien des Indikators parallel. Dann wird die vorherige Kopie entladen.
Dokumentation lesen https://www.mql5.com/ru/docs/runtime/running
Herr Slava hat es deutlich gesagt.
Es wird eine Kopie des Indikators erstellt und der alte Indikator wird nach einiger Zeit entladen.
Wenn wir globale Variablen des Programms speichern wollen, sollten wir das schon vorher beim Aufruf von OnInit erledigen (globale Variablen des Client-Terminals sind für diesen Zweck gut geeignet).
Und die Indikatorpuffer werden sowieso neu berechnet, weil sich die Balken (Candlesticks) geändert haben, deshalb passiert es so (die Kopie wird gestartet und die vorherige Indikatorinstanz wird vom Terminal beendet).
Wenn der Entwickler des Indikators das Problem bei der Arbeit mit grafischen Objekten sieht, sollten Sie beim Starten des Indikators die Namen der grafischen Objekte an den Namen der TF binden, dann wird die neue Kopie des Indikators neue Objekte erstellen, und die vorherige Kopie des Indikators wird ihre Daten bereinigen.
Es gibt kein Problem.
Ja, das ist klar. Ich habe nach der Logik des Ablaufs der Ausführung gefragt. Die Sache ist die, dass es eine solche Logik nicht gibt. Manchmal wird OnDeinit zuerst ausgeführt (wie es nach der Logik des Normalbürgers sein sollte), und manchmal wird OnInit zuerst ausgeführt.
Meines Erachtens liegt die Antwort in der Bemerkung"Für eine bestimmte Zeit (eine sehr kurze Zeit) existieren beide Kopien des Indikators parallel". Aber das macht die Frage nicht klarer.