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.
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.
Ab 12 Uhr gestern Abend arbeiteten die Experten an der MQ-Demo und der Alpari-Demo. Während der gesamten Zeit gab es auch keinen Fehler 128, auf Alpari gab es einen Fehler 6 (Ping-Fehler), und auf beiden - mehrere alte Ticks. Die Bestellungen funktionierten ohne Fehler. Build 1.8.3 vom 05.10. Vielleicht ist es etwas anderes? Zum Beispiel die Besonderheiten der Verbindung über Port 443 bei verschiedenen Internetanbietern? MT3 hatte Fehler, aber nicht so viele.
Leider. "Seit 12 Uhr nachts" ist keine Statistik. Aus unbekannten Gründen treten die Probleme in Wellen auf, dann keine, dann mehrere auf einmal...
<br / translate="no"> Quark, haben Sie ein Gewissen, posten Sie solche Protokolle nicht im Forum =)))))
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.
Das ist ein gutes Argument. Aber ich habe Fälle erlebt, in denen die Bestellung auch eine Stunde später noch nirgendwo angekommen ist, d. h. manchmal sind sie nicht falsch. <br / translate="no"> Ich habe auch eine Verzögerung von jeweils 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...
<br / translate="no"> Alle meine Fehler schienen im Code zu liegen =) d.h. ich habe die falsche Prüfung nach orderclose. Nachdem ich es korrigiert hatte, gab es keine. Es stimmt, es ist noch nicht viel Zeit vergangen, wir müssen noch warten...
//---- prüft, ob die Position tatsächlich geschlossen wurde, und wenn nicht, gibt es die Information aus und beendet sich, indem es -5 zurückgibt for ( int x = 0; x < 5; x ++ ) { Sleep(1000);
if ( OrderSelect( Close_OrderTicket, SELECT_BY_TICKET ) ) { if ( OrderCloseTime() <= 0 ) { Processing_Error ( 0, "OrderClose" ); _Return_ ( 3, "Error", 0, "Position wurde nicht geschlossen", "OrderClose(...)", "Die Position wurde nicht geschlossen" ); return(-5); } else { break; } } Close_GetLastError = GetLastError(); _Print_ ( 3, "OrderSelect( " + Close_OrderTicket + ", SELECT_BY_TICKET )", "Fehler #" + Close_GetLastError + " ( " + ErrorDescription( Close_GetLastError ) + " )" ); }
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
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Erlauben Sie die Verwendung von Cookies, um sich auf der Website MQL5.com anzumelden.
Bitte aktivieren Sie die notwendige Einstellung in Ihrem Browser, da Sie sich sonst nicht einloggen können.
Sie sind angemeldet. Die Zwei-Faktor-Authentifizierung wurde deaktiviert. Richten Sie sie erneut ein und scannen Sie einen neuen QR-Code oder fahren Sie mit deaktivierter Zwei-Faktor-Authentifizierung fort.
beim Verlassen der Startfunktion
Bis zu 100000 ohne sichtbare Verbesserung
Ersetzt durch
if(!IsTesting()) { Sleep(1000); GlobalVariableSet(strTradeSemaphore, 0.0); }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:
//---- prüft, ob die Position tatsächlich geschlossen wurde, und wenn nicht, gibt es die Information aus und beendet sich, indem es -5 zurückgibt for ( int x = 0; x < 5; x ++ ) { Sleep(1000); if ( OrderSelect( Close_OrderTicket, SELECT_BY_TICKET ) ) { if ( OrderCloseTime() <= 0 ) { Processing_Error ( 0, "OrderClose" ); _Return_ ( 3, "Error", 0, "Position wurde nicht geschlossen", "OrderClose(...)", "Die Position wurde nicht geschlossen" ); return(-5); } else { break; } } Close_GetLastError = GetLastError(); _Print_ ( 3, "OrderSelect( " + Close_OrderTicket + ", SELECT_BY_TICKET )", "Fehler #" + Close_GetLastError + " ( " + ErrorDescription( Close_GetLastError ) + " )" ); }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