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
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? Hätte sie nicht die richtigen Parameter gehabt, wäre die Funktion explodiert... Es ist wie OK... ...es wurde gesendet. Dann stellte sich heraus, dass es einen Fehler gab... Was ist die Logik dahinter?Gerade eingeschaltet! Victor, wenn "ok", bedeutet dies, dass sich ein Parameter geändert hat, aber Fehler 1 bedeutet, dass ein Parameter als geändert deklariert wurde, sich aber als unverändert herausstellte. Deshalb müssen wir Ihre Logik korrigieren, um solche Fälle zu vermeiden, und all diese Ungenauigkeiten werden zu erneuten Notierungen und einer Menge Fehler auf dem realen Markt führen!
Sie wissen, dass ich diese Art von Programmierstil nicht verwende, dass alles über den ganzen Platz verstreut ist. Ich schreibe das Programm als logisches Skript, alle Ereignisse entwickeln sich sequentiell, und alles ist immer griffbereit mit allen Bedingungen, ohne dass man etwas suchen muss. Und ich verwende externe Funktionen, um die letzte Aktion durchzuführen und auf Fehler zu prüfen.
Aber in Ihrem Fall ist es für den Uneingeweihten unklar, was Sie haben und wo es angekreuzt ist, alles ist versteckt, und Sie müssen raten, ob Sie die Voraussetzung angekreuzt haben oder nicht! Das sind viele Worte, genau wie bei mir jetzt, aber Ihr Programm bringt es nicht auf den Punkt. Sie sollte klar und prägnant sein!
Boris, mir ist natürlich klar, dass ich nicht alles an einem Ort habe. Aber die Eingabeparameter unmittelbar vor der Änderungsfunktion sind angedockt. Ich habe gerade ein Bildschirmfoto davon gemacht. Es gibt aktuelle und neue PLOs, SL und TP. Und sie sind alle unterschiedlich. Warum sollte ich mich mit Details beschäftigen, wenn alles in der Nähe ist? Wenn sie unbedruckt ist und Sie sehen können, dass die Parameter unterschiedlich sind, bedeutet das, dass sie tatsächlich unterschiedlich sind. Oder sollten Sie vielleicht auch dem Druck nicht trauen?
Und davor gibt es, wie ich oben gezeigt habe, einen Test:
Wie können Sie genauer sein? Oben sind ein paar Clowns, die anfangen, Geschichten zu erfinden. Offensichtlich konnten oder wollten sie nicht verstehen, was ich wollte. Sie lachen also grundlos. Aber die Frage ist interessant.
Wenn wir z.B. einen Parameter eines anderen Typs oder eine falsche Menge in OrderModify() einfügen, wird dies einen Fehler verursachen. Und hier wird es ausgeführt, sagt wie OK, aber dann stellt sich heraus, dass kein Parameter geändert wurde.
Die Frage ist, woher wir wissen, was dort falsch ist. Ich habe meine Funktion dargelegt. Dort sollte alles klar sein. Hier ist sie:
Ich habe absichtlich alle Zeilen auskommentiert. Sie könnten nur den Code verderben. Wenn Sie Anmerkungen haben, helfen Sie uns bitte.
Boris, mir ist natürlich klar, dass ich nicht alles an einem Ort habe. Aber die Eingabeparameter unmittelbar vor der Änderungsfunktion sind angedockt. Ich habe gerade ein Bildschirmfoto davon gemacht. Es gibt aktuelle und neue PLOs, SL und TP. Und sie sind alle unterschiedlich. Warum sollte ich mich mit Details beschäftigen, wenn alles in der Nähe ist? Wenn sie unbedruckt ist und Sie sehen können, dass die Parameter unterschiedlich sind, bedeutet das, dass sie tatsächlich unterschiedlich sind. Oder sollten Sie vielleicht auch dem Druck nicht trauen?
Und davor gibt es, wie ich oben gezeigt habe, einen Test:
AllesTut mir leid, ich kann mir keinen Reim darauf machen, da ich keine Bedingungen in der Schleife sehe, die sicherstellen, dass die Auftragsparameter nicht miteinander verwechselt werden!
Das Vorhandensein eines Fehlers zeigt Ihnen, dass Sie irgendwo einen logischen Fehler machen. Es heißt aber auch, dass das Programm funktioniert, aber wir sind an der Qualität des Programms interessiert!
Leider kann ich das nicht herausfinden, da ich keine Bedingungen in der Schleife sehe, die sicherstellen, dass die Bestellparameter nicht miteinander verwechselt werden!
Das Vorhandensein eines Fehlers zeigt Ihnen, dass Sie irgendwo einen logischen Fehler machen. Es heißt aber auch, dass das Programm funktioniert, aber wir sind an der Qualität des Programms interessiert!
Alle Operationen mit Aufträgen finden in einer Schleife statt! An dieser Stelle wird die Methode fOrderModify() aufgerufen, deren Code ich oben zitiert habe:
Sie können dort alles sehen... Sie können auch sehen, dass der Fehler nach jeder Iteration der Schleife gelöscht wird. Auf diese Weise ist gewährleistet, dass ein Fehler in der vorherigen Bestellung, falls es einen gab, nicht auf die nächste überspringt (ich meine natürlich seinen Wert).
Wie viel einfacher kann es sein? Es ist so einfach...
Ich habe eine Nachricht gefunden.
Es handelt sich um denselben Terminalfehler. Ich habe noch nie einen solchen Fehler gehabt. Ich habe noch nie versucht, die 3 Parameter (OOP, SL und TP) von schwebenden Aufträgen zu ändern. Aber ich musste es tun. Und ich bin über einen Fehler gestolpert.
Ich sehe, wenn sich zum Beispiel der Eröffnungskurs und der Stop Loss nicht geändert haben und wir stattdessen die gleichen Werte erhalten, aber die Take Points sich geändert haben. Verursacht sie auch den Fehler? Dann stellt sich heraus, dass die Unterlagen falsch sind. Und dieser Punkt wird nicht unterstützt oder was?
Ich habe eine Nachricht gefunden.
Es handelt sich um denselben Terminalfehler. So etwas habe ich noch nie erlebt. Ich habe noch nie versucht, die 3 Parameter (OOP, SL und TP) von schwebenden Aufträgen zu ändern. Aber ich musste es tun. Und ich bin über einen Fehler gestolpert.
Ich sehe, wenn sich zum Beispiel der Eröffnungskurs und der Stop Loss nicht geändert haben und wir stattdessen die gleichen Werte erhalten, aber die Take Points sich geändert haben. Verursacht sie auch den Fehler? Dann stellt sich heraus, dass die Unterlagen falsch sind. Und dieser Punkt wird nicht unterstützt oder was?
Überprüfen Sie auch die Entfernung bei jedem Ticken? Ich habe mir vor langer Zeit die Regel zu eigen gemacht, Aufträge bei der Eröffnung des TF-Balkens zu eröffnen und sie nur bei der Eröffnung des Balkens auf M1 zu ändern und zu schließen! Der obige Code erinnert mich an einen Fortschrittsbericht, der alles zu enthalten scheint, aber nichts Konkretes! Ich sehe keine Schleife, in der Sie alle Aktionen durch bestimmte Bedingungen definieren! Ich sehe nur eine Schleife, die mir sagt, dass ich nichts ändern soll, dann ändere ich einfach nichts, und es treten keine Fehler auf.
Beachten Sie Renats wichtigen Hinweis, dass Ihre Fehler von der Verwirrung darüber herrühren können, was global und was lokal zu tun ist, und Fehler sind immer letztere, die früheren werden ohne Ihr Zutun mit Funktionsende zurückgesetzt!
Überprüfen Sie auch die Entfernung bei jedem Ticken?!
Nein! Ich erlaube Änderungen nur, wenn eine Bedingung erfüllt ist. In diesem Fall besteht die Bedingung für die Änderung darin, die berechneten Werte zu ändern. Einfach so:
Einfach? Einfach....
Ich habe vor langer Zeit die Regel aufgestellt, Aufträge bei der Eröffnung eines Balkens in TF zu eröffnen und nur bei der Eröffnung eines Balkens auf M1 zu ändern und zu schließen! Der obige Code erinnert mich an einen Fortschrittsbericht, der alles zu enthalten scheint, aber nichts Spezifisches! Ich sehe keine Schleife, in der Sie alle Aktionen durch bestimmte Bedingungen definieren! Ich sehe nur eine Schleife, die mir sagt, dass ich nichts ändern soll, dann ändere ich einfach nichts und es gibt keine Fehler.
Ich hatte auch ähnliche Gedanken, nur bei der Öffnung von M1 zu ändern, und das gilt, wenn die Änderung durch einen vordefinierten Wert erfolgt. Es gibt jedoch Situationen, in denen ich diese Daten nicht auf M1 überprüfen muss. Ich habe zum Beispiel einen Stopp auf einem Niveau gezogen, das bereits berechnet wurde. Dann, wie ich oben gezeigt habe, habe ich eine Prüfung in der OnInit()-Funktion:
D.h. wenn sich die Ebene geändert hat,... modifiziert. Dadurch werden unnötige Änderungsversuche vermieden. Sozusagen eine Änderung durch Signal und nicht durch Zeitschaltuhr. Haben Sie das hier verstanden?Ich sehe keine Schleife, in der Sie alle Aktionen durch bestimmte Bedingungen definieren! Ich sehe nur eine Schleife, die mir sagt, dass ich nichts ändern soll, dann ändere ich einfach nichts und es treten keine Fehler auf.
Ich habe da draußen alles ausgezogen. Was gibt es da nicht zu verstehen... :(
Beachten Sie Renats wichtigen Hinweis, dass Ihre Fehler von der Verwirrung darüber herrühren können, was global und was lokal zu tun ist, und Fehler sind immer letztere, die früheren werden ohne Ihr Zutun mit dem Funktionsende zurückgesetzt!
Und es scheint, dass dieses Problem nicht gelöst wurde und auch nicht gelöst werden wird. Vielleicht sind die Entwickler zu faul? Wenn ich mit Fehlern arbeite, könnte jemand, auch Renat, in den Code hineingeschaut haben und nicht nur sagen, dass ich es falsch gemacht habe.
Denn wenn die neuen und aktuellen Werte der zu ändernden Parameter vor der Änderungsfunktion ausgegeben werden, ist es klar, dass diese Werte vorhanden sind. Warum sollte man irgendwo weiter nach oben gehen? Es gibt Werte, es ist klar, dass es keine Fehler gibt (ich habe dort für Fehler gedruckt). Es bedeutet, dass in der Logik alles in Ordnung ist. Der Fehler liegt also in der Änderungsfunktion.
Nein! Ich erlaube Änderungen nur, wenn eine Bedingung erfüllt ist. In diesem Fall besteht die Bedingung für die Änderung darin, die berechneten Werte zu ändern. Einfach so:
Einfach? Einfach....
Ich hatte auch ähnliche Gedanken, nur bei der Öffnung von M1 zu modifizieren, und das gilt, wenn die Modifikation um einen vorgegebenen Wert durchgeführt wird. Es gibt jedoch Situationen, in denen ich diese Daten nicht bei M1 überprüfen muss. Ich habe zum Beispiel einen Stopp auf einem Niveau gezogen, das bereits berechnet wurde. Dann gibt es, wie ich oben gezeigt habe, eine Prüfung in der Funktion OnInit():
D.h. wenn sich die Ebene geändert hat,... modifiziert. Dadurch werden unnötige Änderungsversuche vermieden. Sozusagen eine Änderung durch Signal und nicht durch Zeitschaltuhr. Haben Sie das hier verstanden?Ich habe dort alles aufgedreht. Was gibt es da nicht zu verstehen... :(
Dieses Problem tritt, wie ich herausgefunden habe, nicht nur bei mir auf. Hier ist ein Beispiel...Und es scheint, dass dieses Problem nicht gelöst wurde und auch nicht gelöst werden wird. Vielleicht sind die Entwickler zu faul? Wenn ich mit Fehlern nicht richtig arbeite, könnte jemand, auch Renat, im Code herumstochern, und nicht nur sagen, dass ich es falsch mache.
Denn wenn die neuen und aktuellen Werte der zu ändernden Parameter vor der Änderungsfunktion ausgegeben werden, ist es klar, dass diese Werte vorhanden sind. Warum sollte man irgendwo höher hinaufgehen? Es gibt Werte, es ist klar, dass es keine Fehler gibt (ich habe dort für Fehler gedruckt). Es bedeutet, dass in der Logik alles in Ordnung ist. Der Fehler liegt also in der Änderungsfunktion.
Ich habe mir dieses Beispiel bereits angesehen. Aber wir müssen uns auf alle Bedingungen einstellen, bis es nichts Besseres mehr gibt. Ihr Code überzeugt mich nicht. Ich werde jetzt zu Mittag essen, dann gebe ich Ihnen ein Beispiel für eine Schleife, die für die Einstellung von SL, die Übersetzung in B/S und die Suche nach nur einem Aufruf einer Änderungsfunktion gut funktioniert, bei der Fehler behandelt werden, die, wenn sie plötzlich in der Arbeit auftreten, nicht im Tester auftreten.
Möchten Sie die Funktion Modify()?
Denn wenn die neuen und aktuellen Werte der zu ändernden Parameter vor der Änderungsfunktion ausgegeben werden, ist klar, dass diese Werte vorhanden sind. Warum sollte man irgendwo weiter nach oben gehen? Es gibt Werte, es ist klar, dass es keine Fehler gibt (ich habe dort für Fehler gedruckt). Es bedeutet, dass in der Logik alles in Ordnung ist. Der Fehler liegt also in der Änderungsfunktion.
Victor, warum haben Sie den SL und TP in den schwebenden Positionen geändert? Im Allgemeinen ist es sinnvoll, den SL erst nach der Eröffnung einer Position zu setzen und den TP nach der Übertragung des SL auf den B/S! Warum also den Server umsonst so sehr belästigen und warum müssen Sie sich all diese Mühe machen?!
Wir müssen den Code minimieren und vereinfachen, damit er schnell und klar funktioniert, und dann wird es einfacher sein, ihn aufgrund der Launen des Marktes zu optimieren! Denken Sie sorgfältig über alle Nuancen im Zusammenhang mit den Marktrealitäten nach!