Init() und DeInit() Ausführungsreihenfolge - Seite 24

Neuer Kommentar
 
fxsaber:
Das Beispiel, das Sie überarbeitet haben, war für das vorliegende Problem nicht optimal geeignet. Sie können ein anderes Beispiel zeigen, für das es keine Lösung durch UninitializeReason geben wird.

Das war's, ich beende diesen Dialog. Welchen Sinn hat es, darüber zu diskutieren, wie man sich am Ohr kratzen kann? Wenn es keine andere Lösung gibt, können Sie Ihren Code verwenden, aber Universalität ist nicht immer die ideale Lösung.

Zum Beispiel würde niemand auf die Idee kommen, einen Holzfäller zu rufen, um einen Himbeerstrauch zu fällen. Ihr Code ist also vergleichbar mit der Arbeit eines Holzfällers, der einen Himbeerstrauch fällen muss.

Mit freundlichen Grüßen Alexej.

 
Ich verstehe nicht, wenn alte DeInit und neue OnInit in verschiedenen Threads ausgeführt werden, was ist das Problem mit OnInit nur warten, bis DeInit auftreten und beenden. Verwenden Sie eine globale Variable als Semaphor.
 
Aleksei Radchenko:
Ich verstehe nicht, wenn alte DeInit und neue OnInit in verschiedenen Threads ausgeführt werden, was ist das Problem mit OnInit nur warten, bis DeInit auftreten und beenden. Verwenden Sie eine globale Variable als Semaphor.
In einem einzelnen Diagramm laufen alle Indikatoren nur in einem Thread.
 
Alexey Viktorov:

Welchen Sinn hat es, ein primitives Zwei-Bit-Beispiel zu verwenden?

Verwenden Sie stattdessen ein Beispiel für fast korrekten Code.

Alexey, dieses Beispiel wurde so gestaltet, dass auch ein Verlierer es verstehen kann. Deshalb habe ich auch geschrieben, dass es primitiv ist. Tut mir leid, es war nicht für Einsen gedacht.

Heute Morgen habe ich einen kleinen Hund gesehen, der die vorbeifahrenden Lastwagen anbellt. Sie lässt Sie grüßen.

 
Nikolai Semko:

Alexej, dieses Beispiel wurde so gestaltet, dass es auch von weniger begabten Menschen verstanden werden kann. Deshalb habe ich geschrieben, dass sie primitiv ist. Tut mir leid, es war nicht für Einsen gedacht.

Ich habe heute Morgen einen Hund gesehen, der vorbeifahrende Lastwagen anbellt. Sie lässt Sie grüßen.

Hast du mit ihr gebellt?

Was lässt sich aus dem Beispiel schließen, in dem die Existenz eines Objekts nicht überprüft wird, bevor es erstellt wird? Ansprüche gegen die Entwickler, dass sie es nicht möglich gemacht haben, irgendeine Art und Weise zu schreiben, mit groben Fehlern? Ich werde schreiben, wie ich will, und die Entwickler müssen mir alle Voraussetzungen dafür bieten. Die Entwickler müssen für alle möglichen Fehler vorsorgen, die ich in Zukunft machen könnte. War es das? Saugen Sie das Problem nicht dort heraus, wo es gar nicht existiert.

 
Alexey Viktorov:

Was geht aus dem Beispiel hervor, in dem es keine Prüfung für ein Objekt gibt, bevor es erstellt wird? Vorwürfe gegen die Entwickler, sie hätten es nicht möglich gemacht, so zu schreiben, wie sie wollen, mit groben Fehlern?


Alexey, du scheinst nicht ganz auf dem Laufenden zu sein. Lesen Sie bitte Primärquellen.
Hier ist ein Zitat: "Wenn ein Objekt bereits erstellt wurde, wird versucht, seine Koordinaten zu ändern. "

Ich weiß, dass es in großen Werken zum guten Ton gehört, verschiedene Arten von Schecks auszustellen. In diesem Fall ist diese Prüfung jedoch bedeutungslos. Denn wenn es kein Objekt gibt, wird ObjectCreate es erstellen, und wenn es eines gibt, werden einfach seine Koordinaten geändert. In diesem sehr primitiven Beispiel ging es darum, die Tatsache des Löschens eines Objekts durch Deunit of old TF zu zeigen, was es perfekt demonstriert.
Ihre "Fahrerflucht" hat nichts zu bedeuten. Wahrscheinlich ist das nur ein Versuch, die Aufmerksamkeit auf sich zu lenken.
Und wenn Sie überflüssige, sinnlose Codezeilen wollen, um Ihre Finger zu trainieren, empfehle ich Ihnen das hervorragende Hilfsmittel "Keyboard Solo".

 
Alexey Viktorov:

Bist du mit ihr gesprungen?

Was können Sie aus dem Beispiel verstehen, in dem es keine Prüfung für ein Objekt gibt, bevor es erstellt wird? Vorwürfe gegen die Entwickler, dass sie es nicht möglich gemacht haben, mit groben Fehlern zu schreiben, was man will? Ich werde schreiben, wie ich will, und die Entwickler müssen mir alle Voraussetzungen dafür bieten. Die Entwickler müssen für alle möglichen Fehler vorsorgen, die ich in Zukunft machen könnte. War es das? Saugen Sie das Problem nicht dort heraus, wo es gar nicht existiert.


Was ist so schlimm an dem Versuch, ein bestehendes Objekt zu erstellen? Wird sie verschwinden?
 
Dmitry Fedoseev:

Was ist so schlimm daran, wenn wir versuchen, ein bestehendes Objekt zu erstellen? Wird sie verschwinden?

Dimitri, du scheinst mir ein gebildeter Programmierer zu sein. Hat man Ihnen die Regeln der Etikette beim Programmieren nicht beigebracht?

Für den Rest kann man wie im alten mql4 schreiben, mit der Möglichkeit von Array-Überläufen und anderen Annahmen. Sie erhalten eine Fehlermeldung als Antwort... Also, zurückflaggen... Lass uns weitergehen, wir haben keine Zeit... Und dann stoßen wir auf ein Problem, das in einer strengeren Sprache keinen Pfifferling wert ist, und beginnen, uns bei den Entwicklern zu beschweren...

Christus ist auferstanden.

 
Nikolai Semko:


... Der Zweck dieses sehr primitiven Beispiels war es, die Tatsache zu zeigen, dass Deunit den Gegenstand der alten TF entfernt hat, was es perfekt demonstriert. ...

Die Tatsache des Scheiterns wird durch das Gegenbeispiel verdeutlicht. Man muss das Problem nicht da heraussaugen, wo es nicht existiert. Wenn Sie den Grund für die Deinitialisierung überprüfen, wird das Objekt nicht gelöscht, sondern es ändert nur seine Koordinaten.
 
Alexey Viktorov:
Die Tatsache des Scheiterns wird in dem Antwortbeispiel gezeigt. Es ist nicht notwendig, das Problem dort herauszusaugen, wo es nicht vorhanden ist. Wenn Sie den Grund für die Deinitialisierung überprüfen, wird das Objekt nicht gelöscht, sondern es ändert nur seine Koordinaten.
//Часть твоего кода:
void OnDeinit(const int reason)
  {
   if(UninitializeReason() != REASON_CHARTCHANGE)      // Что ты здесь сделал? - ЕСЛИ ПРОИСХОДИТ СМЕНА ТФ, ТО НИЧЕГО НЕ ДЕЛАЕМ. Бред! 
                                                       // И зачем здесь использовать функцию UninitializeReason(), когда можно уже существует переменная  reason?
    {
     ObjectDelete(0,"InitDeinit");
     ChartRedraw(0);                                   // Не нужная функция в данном случае, т.к. она обычно применяется после изменении свойств объктов. Объект удалится и так. 
     Print(__FUNCTION__, "  InitDeinit удалён");       // А где ж твоя любимая проверка, вдруг не удален.
    }
  }

Mein Beispiel diente dazu, das Problem der unklaren Reihenfolge der Einheit der neuen TF und der Einheit der alten TF aufzuzeigen, nicht als Lösung.

Sie haben das Problem nur umgangen, nicht gelöst.
In meinem Beispiel ist es nur wichtig, dass das Objekt in der Unit der alten TF auf jeden Fall gelöscht wird, auch wenn die TF geändert wird, und in der Unit des neuen Objekts wieder angelegt wird.

Wenn die Sequenz zuerst Deunit der alten TF ist, dann Unit der neuen TF, wie es logischerweise sein sollte. Dann wird das Objekt gelöscht und anschließend neu erstellt.

Wenn die Sequenz zuerst die Unit der neuen TF und dann die Deunit der alten TF ist, dann wird das Objekt einfach geändert, wenn Sie versuchen, es in der Unit zu erstellen, da es noch nicht gelöscht ist. Und dann wird sie von der Deunit der alten TF gelöscht. Das ist der Fehler.

Das war der Sinn dieses Beispiels - um zu zeigen, was ein Programmierer, der diesen Zweig nicht gelesen hat und sich dieser "Funktion" nicht bewusst ist, erleben kann.
Dieses Beispiel war nicht als Lösung gedacht. Als Varianten der Lösung werden hier und hier vorgestellt. Ich denke, ich werde später auch eine Lösung hinzufügen, aber ohne globale Variablen und Dateien des Terminals zu verwenden und damit diese Lösung auch funktioniert, wenn mehrere identische Indikatoren in einem Fenster gesetzt sind. Haben Sie versucht, dieses Problem zu lösen? Oder Sie sind nur in der Lage, Fehler im Code anderer Leute zu finden, vor allem, wenn sie nicht vorhanden sind.

Sei nicht mehr dumm!

1...171819202122232425262728
Neuer Kommentar