OnTradeTransaction-Verarbeitung - Seite 6
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
Guten Tag.
Niemand wird von irgendjemandem eingeschüchtert.
Sie haben nicht switch(trans.type)
Nun, der vorliegende Fall ist natürlich in switch(trans.type). Da es einen weiteren Fall gab, wollte ich nicht den gesamten Code anzeigen, um ihn nicht mit unnötigen Informationen zu überfrachten.
fxsaber , vielen Dank für das Beispiel!
Alexey, das ist genau dasselbe. Ich verwende 2 verschiedene Roboter für den Handel mit demselben Symbol im Netting-Modus. Die beiden von Ihnen zitierten Beiträge ergänzen sich gegenseitig.
Es ist interessant, das Problem ausgehend von dem primären Änderungsauslöser - onTradeTransaction- zu lösen.
Insgesamt aufgetretene aktuelle Probleme:
1. deal_add löst aus, aber keine Pose. Bislang keine Gedanken.
2. deal_add wird ausgelöst, aber der Auftrag befindet sich in der dritten Dimension. Legen Sie einen Slip an, in den letzten Tagen scheint das zu helfen. Der Auftrag schafft es, in 1 Sekunde in die Geschichte einzugehen. Ich habe keine Hochfrequenz-Handelsroboter und verwende keine Marktaufträge, daher wäre diese Lösung angemessen.
3. deal_add wird 2 mal ausgelöst, d.h. ein und derselbe deal_add wird 2 mal ausgelöst. Dieses Problem kann gelöst werden, indem man das Ticket eines früheren Geschäfts überprüft und es mit dem aktuellen vergleicht.
Es gibt noch Punkt 1. Erklärungen dazu.
Gestern habe ich sell_limit gesetzt, es hat funktioniert, deal_add kam, aber die Position erschien nicht und wir eröffneten eine Stop-Order für nichts. Ich habe mir die Transaktionsbeschreibung angesehen und festgestellt, dass die Geschäftsart DEAL_TYPE_SELL lautet, die Auftragsart aber ORDER_TYPE_BUY. Gleichzeitig gehört der Bestellschein uns. Das schien nicht ganz logisch zu sein. Ich beschloss, zu überprüfen, ob die Auftragsart und die Geschäftsart in OnTradeTransaction gleich sein sollten, ob die Auftragsart und die Geschäftsart gleich sein sollten.
Ich aktivierte den Expert Advisor in der Demo und erhielt eine weitere ähnliche Transaktion, aber dieses Mal hat sich die Position geändert. Aufgrund unserer Prüfung wurde der Stoppauftrag jedoch nicht ausgeführt. Was ist hier los?
Ich werde Ihnen gleich sagen, dass das hier in den Terminal kommt. Ohne dass ich es erfunden hätte.
Gestern habe ich sell_limit platziert, es wurde ausgelöst, deal_add kam, aber keine Position erschien und wir öffneten Stop-Orders für nichts. Ich habe mir die Transaktionsbeschreibung angesehen und festgestellt, dass die Geschäftsart DEAL_TYPE_SELL und die Auftragsart ORDER_TYPE_BUY ist. Gleichzeitig gehört der Bestellschein uns. Das schien nicht ganz logisch zu sein. Ich habe beschlossen, zu prüfen, ob Auftragstyp und Transaktionstyp in OnTradeTransaction bei deal_add übereinstimmen.
Aber hier lohnt es sich, die Hilfe zumThema "Struktur der Handelstransaktion" noch einmal zu lesen - im Hinblick darauf, welche Felder für den Typ deal_add ausgefüllt werden.
Und die Auftragseigenschaften nicht aus der Transaktion zu übernehmen (wo sie nicht ausgefüllt sind, aber Nullen auch einigen Werten im Enum-Typ entsprechen), sondern aus dem Auftrag selbst, wenn er im Moment verfügbar ist (und nicht während des Übergangs von Aufträgen zur Historie).
Dies erleichtert die Analyse der Entwicklung.
Sie können hinzufügen, dass der Status von Positionen, aktuellen Aufträgen und der Handelsverlauf zusammen mit den Transaktionen protokolliert werden können. Dann wird das gesamte Bild verfügbar sein.
An dieser Stelle lohnt es sich, die Hilfe zumThema "Aufbau eines Handelsgeschäfts" noch einmal zu lesen - im Hinblick darauf, welche Felder für den Typ deal_add ausgefüllt werden.
Und die Auftragseigenschaften nicht aus der Transaktion zu übernehmen (wo sie nicht ausgefüllt werden, sondern Nullen auch einigen Werten im Aufzählungstyp entsprechen), sondern aus dem Auftrag selbst, wenn er gerade verfügbar ist (und nicht beim Übergang von Aufträgen in die Historie).
Ich stimme zu, ich war mir dessen bewusst, habe aber nicht darauf geachtet. Danke, dass Sie mich daran erinnern.
Das Problem, dass eine Position in einem Fall nicht auftaucht, in einem anderen aber schon, bleibt jedoch bestehen und ist unklar.
Илья Ребенок:
Das Problem, dass die Position in einem Fall nicht auftaucht und im anderen Fall schon, bleibt jedoch bestehen und ist unklar.
Die Position wurde in der Transaktion deal_add erfasst, aber die Position existierte vorher nicht und wurde nicht angezeigt? Das muss geklärt werden.
Die Position wurde in der Transaktion deal_add erfasst, aber die Position war vorher nicht vorhanden und wurde nicht angezeigt? Das muss geklärt werden.
die Position war vorher nicht vorhanden
die Position war vorher nicht vorhanden
Gab es bei der Transaktion ein Positionsticket?
Gab es bei der Transaktion ein Positionsticket?
Im obigen Beitrag ist mir wohl ein kleines Missverständnis unterlaufen. Es gab eine Position, die dann durch Stop-Orders geschlossen wurde. Das heißt, die Anzahl der Positionen wurde zu 0. Dann wurde ein Handel ausgelöst, aber die Position erschien nicht.
Ich glaube, das ist es, was Sie meinen. Die Transaktion enthielt Informationen über das Ticket der Position, aber dieses Ticket = Ticket der vorherigen Bestellung. So wie es im Netzmodus sein sollte, wenn ich es richtig verstehe.
Position: 82675534Im obigen Beitrag ist mir wohl ein kleines Missverständnis unterlaufen. Es gab eine Position, die dann durch Stop-Orders geschlossen wurde. Das heißt, die Anzahl der Positionen wurde zu 0. Dann wurde ein Handel ausgelöst, aber die Position erschien nicht.
Ich glaube, das ist es, was Sie meinen. Die Transaktion enthielt Informationen über das Ticket der Position, aber dieses Ticket = Ticket der vorherigen Bestellung. Wie im Allgemeinen sollte es im Netzmodus sein, wenn ich es richtig verstehe.
Wenn die Position auf dem Symbol (kumulativ, alle Robots und manuellen Trades zusammen) 0,0 wurde, wird die nächste Transaktion eine neue Position mit einem neuen Ticket (==Orderticket) eröffnen (DEAL_ENTRY_IN).
Ich habe den Eindruck, dass beim Netting die Position überhaupt nicht berücksichtigt werden muss - jeder Roboter muss "seine" Positionen berücksichtigen, d. h. die Ergebnisse der Geschäfte auf seine Aufträge.
Das Vorhandensein von Positionen und DEAL_ENTRY-Flags sollte in keiner Weise in die Logik einbezogen werden.
Wir brauchen nur die Magie und den Kommentar zu neuen Geschäften und laufenden Aufträgen zu betrachten, um zu erkennen, ob es sich um eigene oder fremde Geschäfte handelt.
Der funktionierende Code zeigte. Es ist genau dasselbe.
Der Versuch, das Problem über OnTradeTransaction zu lösen, ist angesichts der zahlreichen Fallstricke eine schlechte Idee. Was bei einer bestimmten Aufgabe manchmal noch umgangen werden kann. Aber wenn Sie die Aufgabe nur ein wenig ändern, wird die gesamte Logik während der OnTradeTransaction-Implementierung unterbrochen.
Die Entwickler haben ein ereignisgesteuertes Handelsmodell entwickelt, aber sie haben kein einziges funktionierendes Beispiel geliefert. Denn es ist ein komplettes Arschloch, in was sich der Code ergießt und wie sehr er von jedem Beispiel abhängt.
Daher würde ich empfehlen, sich mit synchronen Handelsoperationen und der OnTrade-Funktion zu beschäftigen. Dort ist alles viel einfacher und die Logik ist sehr flexibel für Änderungen. Außerdem ist sie zuverlässiger.
Der Übergang zu Async+Transactions ist vergleichbar mit dem Übergang von der Hochsprache zum Assembler. D.h. es sollte in der allerletzten Phase der TS-Erstellung geschehen, wenn sie VOLLSTÄNDIG erforscht und bereit für den ECHTEN Handel ist und das Letzte ist, den Handel zu beschleunigen, OHNE die Handelslogik zu verändern.