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
Fehler 1 ist ein normaler Fehler...
im Tester, tritt es normalerweise nicht auf (es sei denn, der Code ist gekrümmt und ändert unveränderte Auftragsparameter oder wenn der Tester Schlupf erzeugen kann).
im realen Markt ist dies (bei korrektem Orderänderungscode) möglich, wenn Sie Stops nahe am Markt ändern, insbesondere bei Slippage - die Art des Stop Loss bewegt sich direkt hinter dem Preis, wenn sich die Order ins Positive bewegt, und aufgrund von Slippage und Preisbewegung tritt der Fehler oft auf, und es ist klar, warum... guter Fehler...
Entschuldigung, SellLimit erfordert dist:
not if (New_OOP < Bid) continue; butif (New_OOP-dist*Point < Bid) continue;
Boris, meine Methode fOrderModify() berücksichtigt alle Prüfungen, sowohl auf STOPLEVEL als auch auf FRIZLEVEL. Wenn also eine dieser Bedingungen nicht erfüllt wäre, wäre die Änderung nicht abgeschlossen worden.
Sie liegen völlig falsch. Der letztgenannte Fehler wird in vielen wichtigen Funktionen immer noch zurückgesetzt. So funktioniert es auch in WinAPI.
Speichern Sie also den Fehlercode sofort nach seinem Auftreten in einer lokalen Variablen und versuchen Sie nicht, ihn nach zehnmaligem Löschen dieser Systemvariablen in einer Vielzahl Ihrer Zwischenfunktionen zu verwenden.
Nun, selbst wenn der Fehler als Option überschrieben würde, bliebe der letzte Fehler bestehen. Der letzte Fehler wäre in meinem Fall immer noch eine 1. Ist es nicht so?
Wenn ich auf diese Weise nicht einmal mit Fehlern arbeite. Darf ich Ihnen an einem Beispiel zeigen, was Sie meinen?
Hier ist meine Änderungsfunktion mit allen Druckern, weil ich sie gerade debugge.(Achten Sie nicht auf andere darin verwendete Methoden).
Der Kellner antwortet: "Was willst du, alter Mann?
Oder: Du sagst mir, was du willst, vielleicht gebe ich dir, was du willst.
Ich habe weder Kritik noch ein herzliches russisches "Merci" erhalten. Traurig, Mädchen...
Ich habe weder Kritik noch ein herzliches russisches "Merci" erhalten. Traurig, Mädchen...
Entschuldigung, SellLimit erfordert dist:
not if (New_OOP < Bid) continue; butif (New_OOP-dist*Point < Bid) continue;
Victor, Ihr erster Beitrag enthielt bereits alle notwendigen Informationen. Sie senden einfach Aufträge, um einen Auftrag zu ändern, ohne neue Werte für die Parameter dieses Auftrags.
Boris, nehmen wir mal an, dass das der Fall ist... Angenommen. Wenn die Funktion jedoch einen Auftrag erneut sendet, um den Auftrag zu ändern, sollte der Signifikanzton geändert werden. Und bei mir ändert es sich überhaupt nicht. Selbst wenn wir uns das Protokoll im Protokoll ansehen, sehen wir Folgendes:
Warum wird die Bestellung abgeschickt? Wären die Parameter nicht korrekt, würde die Funktion abstürzen... Und hier ist es irgendwie in Ordnung... ...es wurde gesendet. Dann stellte sich heraus, dass ein Fehler vorlag. Was ist die Logik dahinter?Was hat das mit Fehlern zu tun? Ich habe einen Fehlerausdruck direkt vor die Änderungsfunktion gesetzt:
Und hier ist das Protokoll dieses Codestücks:
Sie können deutlich sehen, dass es vor der Änderungsfunktion keine Fehler gibt! Was hat das mit Fehlern zu tun?