![MQL5 - Sprache von Handelsstrategien, eingebaut ins Kundenterminal MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
beim Verlassen der Startfunktion
Bis zu 100000 ohne sichtbare Verbesserung
Ersetzt durch
unter
Derselbe Pfeffer.
Fehler 146.
d.h. wir selbst warten darauf, dass unser eigener Handelskontext freigegeben wird
und generell ist dies eine äußerst merkwürdige Situation. nach der Durchführung einer Handelsoperation wird der Kontext sofort freigegeben. sonst wäre es unmöglich, Positionen in einer Schleife zu schließen
Noch einmal.
Der obige Code führt dazu, dass der Expert Advisor hängen bleibt, wenn die Handelsflagge gelöscht wurde.
Dies führt dazu, dass der Handel vollständig zum Erliegen kommt, weil niemand das Semaphor signalisiert. Diese Situation ist zumindest einigermaßen beherrschbar, da die Flagge nur manuell entfernt werden kann.
Noch schlimmer ist der Fall des Semaphors. GlobalVariableSet kann auf einen anderen EA fallen, wenn dieser die Semaphore schließt. Dies hat zur Folge, dass mehrere EAs versuchen werden, gleichzeitig zu handeln.
Wie wir sehen, verstehen die Entwickler nicht, welche asynchronen Prozesse im Terminal ablaufen. Und dieses Missverständnis wird in das Forum exportiert.
Kein Wunder, dass fatale Fehler, wie der hier besprochene, auftreten und diese Fehler nicht behoben werden können.
Warum schädliche Ratschläge geben?
Die Annahme ist, dass wenn der Berater diesen Punkt erreicht hat, dann steht die Handelsflagge!
Die Annahme ist, dass wenn der EA diesen Punkt erreicht hat, die Handelsflagge oben ist!
Worauf stützt sich diese Annahme? Wenn die Annahmen nicht mit der Realität übereinstimmen, treten unerwartete Fehler auf.
Die Flagge ist nichts.
Synchronisierung, Mutexe, gemeinsame Ressourcen - das Problem ist real. Es ist unsinnig, vorzuschlagen, dass man das Problem mit globalen Variablen auf Benutzerebene lösen soll. Zumal das Beispiel nicht umsetzbar ist.
Leider. "Seit 12 Uhr nachts" ist keine Statistik. Aus unbekannten Gründen treten die Probleme in Wellen auf, dann keine, dann mehrere auf einmal...
Ich dachte - wen kümmert's (Fiddler's Ton von Kindzadz) :))
Über die Realität des Schließens/Öffnens - ich habe Prüfungen in allen f-Funktionen und Fehler erscheinen, aber sie sind FALSE Fehler. Ich habe die Protokolle und den Auftragsverlauf überprüft, alle Positionen wurden geschlossen. Der Auftrag hatte einfach keine Zeit, sich in der Geschichte zu bewegen. Ich habe eine 1-Sekunden-Verzögerung vor der Überprüfung gemacht - aber das ist nicht genug... Als ich nachfragte, gab man mir keine Antwort.
Gutes Argument. Aber ich habe Fälle erlebt, in denen die Bestellung auch eine Stunde später noch nirgendwo angekommen ist, das heißt, manchmal sind sie nicht falsch.
Ich habe auch eine Verzögerung von 10 Sekunden.
Alle meine Fehler lagen, wie sich herausstellte, im Code =) d.h. ich habe die falsche Prüfung nach dem Orderclose durchgeführt.
Nachdem ich es korrigiert hatte, gab es keine. Es stimmt, es ist noch nicht viel Zeit vergangen, wir müssen noch warten...
Nachdem ich es korrigiert hatte, gab es keine. Es stimmt, es ist noch nicht viel Zeit vergangen, wir müssen noch warten...
Wie sieht der korrigierte Code aus?
für Auftragsklauseln:
für ordersand - nur ein 5-facher Versuch , einen Auftrag auszuwählen, mit einer zweiten Pause,
für modifiersand - Vergleich der alten Werte mit den aktuellen Werten