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
Oh, mein Gott! Ist sie in der Geschichte gültig?
papaklass meinte wahrscheinlich, dass OnTradeTransaction Fehler zurückgibt?
Wenn die Informationen in OnTradeTransaction möglicherweise nicht gültig sind, müssen wir sie aus der Historie entnehmen, um sicherzustellen, dass sie gültig sind.
Wenn onTradeTransaction-Informationen nicht immer zuverlässig sind, müssen wir sie aus der Historie entnehmen, um sicherzustellen, dass die Informationen verarbeitet wurden.
Die Frage ist, warum zum Teufel brauchen wir OnTradeTransaction, wenn wir die Informationen sowieso aus der Historie nehmen müssen? - Sie wird nur für die Fehlerprüfung benötigt. Der Broker lehnte die Order ab und wir erhielten die Antwort, warum sie abgelehnt wurde, in OnTradeTransaction und analysierten sie.
aber warum über 9 Seiten sabbern?
Bitte seien Sie nicht unhöflich! Übrigens, es ist schon 10!
Und es ist Ihr gutes Recht, das, was hier steht, gar nicht zu lesen!
C-4, wird natürlich verarbeitet, aber wozu braucht man OnRefresh()?
Viele Ereignisse -> ein Handler.
Fehler aus allen Ecken auf einen Haufen! :)
Es sind nicht die Fehler, die gesendet werden, sondern die Daten. Fehler können im Handler liegen, aber sie sind leicht zu beheben, da es nur einen Handler gibt.
Das ist genau das, was ich meine. Sie brauchen eine Trennung der Ereignisse.
Es sind nicht die Fehler, die gesendet werden, sondern die Daten. Fehler können im Handler liegen, aber sie sind leicht zu beheben, da es nur einen Handler gibt.
Sie müssen nicht die Ereignisse, sondern die Handler voneinander trennen. Ereignisse erzeugen Daten. Jede Art von Daten wird von einem anderen Handler bearbeitet. Es spielt keine Rolle, wer die Daten erhalten hat, wichtig ist nur, dass es für jeden Datentyp einen eigenen Handler gibt.Was wird hier nicht getrennt?
Und dann gibt es noch
Was wird hier nicht geteilt?
Was Sie vorschlagen (Verarbeitung von Datentypen) ist das, was MK im Moment hat. Der OnTradeTransaction-Handler behandelt einen bestimmten MqlTradeTransaction-Datentyp. Es stimmt, sie haben viele Dinge in diesen Datentyp gepackt, z.B. Datentypen, die verschiedenen Ereignissen entsprechen.
Ich schlage vor, dass jedes Ereignis seine eigenen Daten und seinen eigenen Handler hat. So viele Ereignisse, so viele Handler. Die Aufteilung der Ereignisse (Eröffnung einer Position, Schließung einer Position, Erteilung eines Auftrags, Änderung eines Auftrags, Änderung einer Position usw.). Und es ist Sache der Entwickler, zu entscheiden, welche Datentypen welchen Ereignissen zugeordnet werden sollen.
Mit dem Wort "Handler" meine ich nicht eine Systemfunktion, die ein Ereignis empfängt, sondern ein Expert Advisor-Modul, das dieses Ereignis analysiert. Um die Anzahl der Funktionen zu multiplizieren... Jeder von ihnen für sein eigenes Ereignis - das macht keinen Sinn, zumal es elementar ist, eine notwendige Anzahl von Custom Handlern zu erstellen. So wird es in meinem Fall gehandhabt:
Es mag seltsam erscheinen, dass ein und dieselbe Ereignisklasse an völlig unterschiedliche Handler übergeben wird, die völlig unterschiedliche Datentypen benötigen. OnMouseMove erfordert beispielsweise eine Maske der gedrückten Maustasten und deren Koordinaten, OnKeyDown() erfordert den Code einer gedrückten Taste, OnOrderChange erfordert ein Ticket der geänderten Reihenfolge und wahrscheinlich eine Aufzählung, die die genaue Änderung beschreibt. Man könnte meinen, dass die Ereignisklasse Felder für alle möglichen Ereignisse enthält. Aber das ist nicht der Fall. Tatsächlich kann das Objekt der Ereignisklasse nicht einmal existieren, da sein Konstruktor im geschützten Bereich verborgen ist. Aber es gibt eine Vielzahl von Nachkommen - jeder Nachkomme kann nur ein anderes Ereignis behandeln. Für jedes Ereignis gibt es jedoch eine Kennung, die angibt, zu welchem Typ es gehört. Mit dieser Kennung können Sie sicher von einer größeren auf eine kleinere Schrift umstellen. Dies ist der Typ des untergeordneten Elements, in den die implizite Konvertierung erfolgt, wenn der Handler übergeben wird. Schauen wir uns an, wie unsere Handler das Ereignis tatsächlich sehen:
Schön... Es sieht so aus, als gäbe es nur ein Ereignis, aber in Wirklichkeit könnte es Dutzende davon geben. Das Ereignis scheint fast keine Informationen zu enthalten, mit Ausnahme seines Typs, aber in Wirklichkeit verweisen die Handler frei auf Methoden, die nur ihnen bekannt sind.Es gibt keine "externen" und "internen" Ereignisse, sondern nur Ereignisse. Und die Zahl dieser Ereignisse ist potenziell unendlich. Ein Ereignis kann alles sein. Ein Ereignis kann alle Arten von Daten enthalten. Mit dieser Philosophie erreichen wir eine neue, höhere Ebene der Datenabstraktion. Warum sollte man in seinem Kopf Einschränkungen schaffen, warum sollte man eine Klassifizierung auferlegen, die die Abstraktion einschränkt!
Der wesentliche Unterschied zwischen internen und externen Ereignissen ist die Ausführungszeit. Interne Ereignisse haben praktisch keine Ausführungszeit, während externe Ereignisse Hunderte von Millisekunden bis Sekunden dauern.
Ereignisse haben keine Ausführungszeit. Wenn ein Ereignis eingetroffen ist, wird es bereits ausgeführt. So funktioniert der asynchrone Modus. Es ist also falsch, Ereignisse in interne und externe zu unterteilen, weil sie so schnell ausgeführt werden. Es ist richtig, überhaupt nicht zu klassifizieren, sondern sehr abstrakt von der konkreten Umsetzung her zu denken.