Init() und DeInit() Ausführungsreihenfolge - Seite 6
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
Warum sollten sie langsam sein? Es sei denn, der Indikator ist schlecht geschrieben. Ein gut geschriebener DeInit-Indikator benötigt recht wenig Zeit. Außerdem ist der TF-Wechsel kein so häufiger Vorgang. In einigen besonders schwerwiegenden Fällen (bei "falschen" Indikatoren) können Sie beim Wechsel der TFs ein oder zwei Sekunden warten.
Daher ist das Argument des Abbremsens beim TF-Wechsel mehr als zweifelhaft. Außerdem kommt es zu einer erheblichen Zeitverzögerung, wenn wir zu der noch nicht gebauten TF wechseln. Und niemand weint über die Bremsen des Terminals.
Die Indikatoren sind unterschiedlich. Es gibt auch langsame. Und nicht alle von ihnen sind ihre eigenen und im Quellcode.
Ich amüsiere mich ein paar Sekunden lang. Ich fühle Dutzende von Millisekunden in der Schnittstelle, ich fühle Unbehagen auf einmal.
Und vor allem gibt es keine Antwort auf meine Frage:
In welchen Situationen, außer bei der einfachen Arbeit mit grafischen Objekten (ohne TF-Name im Titel), ist die DeInit-Init-Sequenz wichtig?
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. Sie können Dutzende von Millisekunden in der Schnittstelle fühlen, gibt es Unbehagen auf einmal.
Und, was am wichtigsten ist, es gibt keine Antwort auf meine Frage:
In welchen Situationen, abgesehen von der einfachen Arbeit mit grafischen Objekten (ohne TF-Name im Namen), ist die DeInit-Init-Sequenz wichtig?
Normalerweise verwende ich keine globalen Variablen, aber manchmal passiert es.
Bei der Arbeit mit globalen Variablen entsteht ein Chaos. Wenn Sie den Indikator aus dem Diagramm löschen, müssen Sie hinter sich aufräumen und die globalen Variablen löschen. An welcher Stelle des Indikators werden Sie die globalen Variablen löschen? Wahrscheinlich sollte es in Deinite gelöscht werden, es gibt keinen anderen Ort. Wenn Sie also den Zeitrahmen ändern und neue Variablen erstellen, kommt Deinite und löscht alles. Es hat sich herausgestellt, dass globale Variablen nicht in Indikatoren verwendet werden können.
Normalerweise verwende ich keine globalen Variablen, aber manchmal passiert es.
Wenn Sie mit globalen Variablen arbeiten, werden Sie abgehackt. Wenn Sie den Indikator aus dem Diagramm entfernen, müssen Sie hinter sich aufräumen und die globalen Variablen entfernen. An welcher Stelle des Indikators werden Sie die globalen Variablen löschen? Wahrscheinlich sollte es in Deinite gelöscht werden, es gibt keinen anderen Ort. Wenn Sie also den Zeitrahmen ändern und neue Variablen erstellen, kommt Deinite und löscht alles. Es hat sich herausgestellt, dass globale Variablen nicht in Indikatoren verwendet werden können.
Sergiy, hast du ein konkretes Beispiel, das nicht aus der Luft gegriffen ist? Ich kann mir auch ein solches Beispiel vorstellen, aber ich habe in der Praxis keine Probleme damit gehabt.
Hinweis: Globale Variablen können auch je nach TF benannt werden.
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.
Und, was am wichtigsten ist, es gibt keine Antwort auf meine Frage:
In welchen Situationen, abgesehen von der einfachen Arbeit mit grafischen Objekten (ohne einen TF-Namen im Titel), ist die DeInit-Init-Sequenz wichtig?
Auf Seite 3 habe ich ein praktisches Beispiel angeführt:
bei jeder Änderung der relevanten Variablen im Terminal-Kopf zu speichern, nicht bei ini/deinit.
im Hauptterminal jedes Mal daran denken, wenn die entsprechenden Variablen geändert werden, nicht bei ini/deinit.
Ich werde es mir merken)
Und denken Sie auch daran, dass in der aktuellen Implementierung nichts in Deinit gemacht werden kann, was dann verwendet werden muss (weder in globalen Variablen noch beim Schreiben in Dateien)...
finci ist mit einer derart unterbrochenen Sequenz im Grunde nutzlos geworden.
Ich werde mich daran erinnern (gut, dass ich zufällig über diesen Thread gestolpert bin), aber andere Programmierer (die hier nicht nachschauen werden) werden die natürliche logische Konsequenz nutzen und Deinit verwenden, in der Hoffnung, dass es funktioniert, und dann wird init auf einer neuen TF laufen.
Ich werde es mir merken)
Denken Sie auch daran, dass die aktuelle Implementierung des Terminals es nicht erlaubt, in Deinit etwas zu tun, das später verwendet werden soll (weder in globalen Variablen noch in Dateien)...
im Grunde genommen ein nutzloser Finkzi, mit einer derart unterbrochenen Sequenz
Verstehen Sie einfach, dass es auch eine andere Logik gibt. Die Logik der MT-Entwickler im Besonderen. Nach dieser anderen Logik sieht alles ganz logisch aus. Daher die Schlussfolgerung: Passen Sie sich dieser Logik an und versuchen Sie nicht, die Meinung von Menschen zu ändern, die in dieser Hinsicht wahrscheinlich mehr Erfahrung haben als Sie. Es ist nutzlos... Niemand wird zustimmen, die etablierte Logik um eines Indikators willen zu ändern.
Wenn es nicht um Finanzen ginge, hätte es vielleicht keine solche Diskussion gegeben.
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.Stellen Sie sich vor, wie langsam die Charts wären, wenn das Terminal vor dem Wechsel der TF auf das Entladen aller Indikatoren der alten TF warten würde und erst dann die neue TF aufbauen und initialisieren würde.
In welchen Situationen, abgesehen von der einfachen Arbeit mit grafischen Objekten (ohne den Namen von TF im Namen), ist die DeInit-Init-Sequenz wichtig?
Ihr verwechselt alle eine Menge verschiedener Dinge. Wir sollten uns auf mindestens zwei Anforderungen an das Terminal als kritische Software einigen:
- es muss vorhersehbar funktionieren und strikt der gleichen Logik folgen (auch bei Multithreading);
- es muss schnell gehen.
(es ist nicht wichtig, ob die Kopie des Indikators über andere Kopien Bescheid weiß, aber es ist wichtig, dass die globalen Daten, die dem Terminal zur Speicherung zugewiesen werden, konsistent sind - dies ist das Anliegen des Terminals, nicht das der einzelnen Indikatorentwickler)
Außerdem stellt sich die Frage, wie sie umgesetzt werden kann. Jetzt wird sie unter Berücksichtigung von Anforderung 2 umgesetzt. Ich schlage vor, sie unter Berücksichtigung von Anforderung 1 umzusetzen, ohne Anforderung 2 zu beeinträchtigen.
Es wird keine spürbaren Verlangsamungen geben, wenn wir beachten, dass die Ereignisse von init/deinit chart und init/deinit des Indikators unterschiedliche Dinge sind. Das Diagramm zeigt sofort das neue Hauptdiagramm an, aber für ältere Indikatoren wird das OnInit-Ereignis nach der Verarbeitung des vorherigen OnDeinit in eine Warteschlange gestellt. Die Ereignisse stehen ohnehin in der Warteschlange des Terminals.
Wenn MQ möchte, kann er mir zu seinen Bedingungen NDA-Charts von Klassen und Sequenzen schicken, ich werde sie korrigieren ;-).