OnTradeTransaction-Verarbeitung - Seite 2

Neuer Kommentar
 
fxsaber:

Können wir >=2 Take- und Stop-Aufträge gleichzeitig haben?

Ja, das stimmt, wir haben einen ersten Einstieg gemacht und einen TP und eine Stop-Order gesetzt. Einige Zeit später können wir dann weitere Einträge hinzufügen und weitere TPs und Stopps setzen.

 

Im Falle eines verlorenen Ereignisses erinnere ich mich an die getätigten Bestellungen, das Ticket der letzten abgerechneten Transaktion, den Zeitpunkt der letzten Aufzeichnung (Änderung) des Zustands und synchronisiere in regelmäßigen Abständen sowie während der Eingabe die Liste der Bestellungen und prüfe auf nicht abgerechnete Transaktionen.

Das zufällige Auftreten von Ereignissen ist die Regel, das Fehlen von (vorläufigen) Aufträgen sowohl in Aufträgen als auch in der Historie ist nicht ungewöhnlich und kann sowohl vor als auch nach einem Geschäft auftreten.

Eine Position beim Netting erhält ein Ticket der ersten Order und speichert es bei weiteren Trades (Änderungen), bis sie geschlossen wird (d.h. 0,0 wird).

Nun, je nach Auftragsvolumen kann es zu mehreren Abschlüssen kommen.
 
Илья Ребенок:


Bitte teilen Sie uns Ihre Erfahrungen und Ideen mit.

Sie machen es nicht von Anfang an richtig.

Warum Magier und alle Arten von Kontrollen?

Das Ticket einer Bestellung ist eine eindeutige Kennung.

Wenn Sie einen synchronen Auftrag senden, erhalten Sie als Ergebnis der Funktion ein Ticket.

Wenn Sie einen asynchronen Auftrag senden, erhalten wir das Ticket in OnTradeTransaction.

Hinzugefügt

Und hierhttps://www.mql5.com/ru/forum/67298/page2#comment_2089220

ist eine gute Funktion, um die Reihenfolge zu überprüfen

ФОРТС: В помощь начинающим
ФОРТС: В помощь начинающим
  • 2015.11.25
  • www.mql5.com
Установка отложенного ордера командой OrderSend().
 
Илья Ребенок:

Ja, das stimmt, wir haben einen ersten Einstieg gemacht und einen TP und eine Stop-Order gesetzt. Nach einiger Zeit könnten wir dann eine Aufstockung vornehmen und eine weitere TP- und Stop-Order platzieren.

Limitaufträge, die TP/SL erfordern, können teilweise ausgeführt werden. Gleichzeitig werden TP in Form von Limit-Aufträgen auf dieselbe Weise ausgeführt. Zum Beispiel wird der TP um ein Drittel des Volumens ausgeführt - der SL sollte um den gleichen Betrag verringert werden.

Alles in allem eine ziemlich unangenehme Logik, um alle Tricks zu erkennen.


Die Aufgabe sollte in OnTrade implementiert werden. Es dürfte nicht schwer sein, sie umzusetzen.

 
prostotrader:

Sie machen von Anfang an alles falsch.

Warum Magier und alle Arten von Kontrollen?

Das Ticket einer Bestellung ist eine eindeutige Kennung.

Wenn Sie einen synchronen Auftrag senden, wird das Ticket als Ergebnis der Funktion empfangen.

Wenn Sie einen asynchronen Auftrag senden, erhalten wir das Ticket in OnTradeTransaction.

Hinzugefügt

Und hierhttps://www.mql5.com/ru/forum/67298/page2#comment_2089220

ist eine gute Funktion, um die Reihenfolge zu überprüfen

Danke, ich werde es lesen.
JRandomTrader:

Bei Verlust eines Ereignisses erinnere ich mich an die getätigten Bestellungen, an das Ticket der letzten verbuchten Transaktion, an den Zeitpunkt der letzten Eingabe (Änderung) des Zustands und synchronisiere in regelmäßigen Abständen die Liste der Bestellungen und überprüfe sie auf nicht verbuchte Geschäfte.

Das zufällige Auftreten von Ereignissen ist die Regel, das Fehlen einer (vorübergehenden) Ordnung sowohl in den Aufträgen als auch in der Geschichte ist nicht ungewöhnlich und kann sowohl vor als auch nach einem Geschäft auftreten.

Die Position beim Netting erhält ein Ticket für den ersten Auftrag und wird bei weiteren Geschäften (Änderungen) gespeichert, bis sie geschlossen wird (d.h. 0,0 wird).

Nun, je nach Auftragsvolumen kann es zu mehreren Geschäften kommen.

Eines der Ziele des Roboters war es, die lokale Abhängigkeit zu beseitigen. Das heißt, er empfängt nur Daten vom Markt, ohne an die Variablen des Terminals oder eines PCs gebunden zu sein. Das bedeutet, dass ich in dringenden Fällen auf einen anderen PC umschalten muss, und der Roboter holt alles ab.

Jetzt habe ich einen weiteren interessanten Fehler entdeckt. Ich habe 2 identische TRADE_TRANSACTION_DEAL_ADD Transaktionen erhalten. Tut mir leid, was zum Teufel ist das?) Der Roboter hat schließlich 2 Stopps für 1 Transaktion gesetzt.

2019.02.08 10:55:29 [INFO]: ( PChBreak_RTS-3.19_22 ) TRADE_TRANSACTION_DEAL_ADD
HANDEL_TRANSAKTION_GESCHAEFT_HINZUFUEGEN
Symbol: RTS-3.19
Deal-Ticket: 12674810
Angebotsart: DEAL_TYPE_BUY
Bestellschein: 82646001
Auftragsart: ORDER_TYPE_BUY
Auftragsstatus: ORDER_STATE_STARTED
Art der Auftragszeit: ORDER_TIME_GTC
Ablauf der Bestellung: 1970.01.01 00:00
Preis: 119700
Preisauslöser: 0
Stopp-Loss: 0
Gewinnmitnahme: 0
Band: 1
Standpunkt: 82646001
Position von: 0

2019.02.08 10:55:32 [INFO]: ( PChBreak_RTS-3.19_22 ) TRADE_TRANSACTION_DEAL_ADD
HANDEL_TRANSAKTION_GESCHAEFT_HINZUFUEGEN
Symbol: RTS-3.19
Deal-Ticket: 12674810
Angebotsart: DEAL_TYPE_BUY
Bestellschein: 82646001
Auftragsart: ORDER_TYPE_BUY
Auftragsstatus: ORDER_STATE_STARTED
Art der Auftragszeit: ORDER_TIME_GTC
Ablauf der Bestellung: 1970.01.01 00:00
Preis: 119700
Preisauslöser: 0
Stopp-Loss: 0
Gewinnmitnahme: 0
Band: 1
Standpunkt: 82646001
Position von: 0

 

Transaktionsereignisse(TRADE_TRANSACTION_DEAL_ADD) kommen mehrmals regelmäßig vor.

Glücklicherweise wird nur die aktuellste Sendung wiederholt (zumindest habe ich keine älteren Sendungen erwischt).

Zum Filtern reicht es aus, zu prüfen, ob der Transaktionsbeleg mit dem vorherigen identisch ist.

 
Ilya Baranov:

Transaktionsereignisse(TRADE_TRANSACTION_DEAL_ADD) kommen mehrmals regelmäßig vor.

Glücklicherweise wird nur die aktuellste Sendung wiederholt (zumindest habe ich keine älteren Sendungen erwischt).

Um sie zu filtern, genügt es, zu prüfen, ob das Transaktions-Ticket dasselbe ist wie das vorherige.

Nicht mehrfach, sondern nach der Anzahl der derzeit im Terminal arbeitenden EAs.

Daher sollte jeder EA seinen eigenen Auftrag bearbeiten

case TRADE_TRANSACTION_DEAL_ADD:
      if((BuyOrder.ticket > 0) && (trans.order == BuyOrder.ticket))  // Buy order
      {
        //Сделка этого советника
      }
break;
 
prostotrader:

Nicht mehrfach, sondern nach der Anzahl der derzeit im Terminal arbeitenden EAs.

Daher muss jeder EA seinen eigenen Auftrag bearbeiten

Ihr Code schützt vor der Tatsache, dass es sich um einen Handel mit diesem EA handelt.

Ich und TS sprechen von Fällen, in denen OnTradeTransaction mit dem TypTRADE_TRANSACTION_DEAL_ADD mehrmals für ein Geschäft aufgerufen wird, d.h. die anderen Felder von MqlTradeTransaction enthalten genau dieselben Daten.

Das bedeutet, dass der Verarbeitungscode in Ihrem Fall mehrmals ausgeführt werden kann.

Vielleicht ist dies nicht bei allen Maklern der Fall. Aber das passiert regelmäßig bei allen Börsenmaklern, mit denen ich gearbeitet habe.

 
Ilya Baranov:

Ihr Code schützt vor der Tatsache, dass es der Handel dieses EAs war.

Ich und TS sprechen über Fälle, in denen OnTradeTransaction mit dem TypTRADE_TRANSACTION_DEAL_ADD mehrmals für ein Geschäft aufgerufen wird, d.h. andere Felder von MqlTradeTransaction haben genau dieselben Daten.

Das bedeutet, dass der Verarbeitungscode in Ihrem Fall mehrmals ausgeführt werden kann.

Vielleicht ist dies nicht bei allen Maklern der Fall. Aber das passiert regelmäßig bei allen Maklern, mit denen ich gearbeitet habe.

Ich handele bei Otkryvashka auf real und testen Sie es auf Demo, aber ich habe nicht mehrere Auslöser.

Posten Sie Ihr Stück Code fürTRADE_TRANSACTION_DEAL_ADD

 
Ilya Baranov:

Transaktionsereignisse(TRADE_TRANSACTION_DEAL_ADD) kommen mehrmals regelmäßig vor.

Glücklicherweise wird nur die aktuellste Sendung wiederholt (zumindest habe ich keine älteren Sendungen erwischt).

Um zu filtern, genügt es, zu prüfen, ob das Transaktions-Ticket dasselbe ist wie das vorherige.

Ja, danke! Das habe ich gerade getan, nachdem ich das gesehen habe.

Was das ursprüngliche Problem anbelangt, so habe ich einen Beleg erstellt, um Zeit zu haben, den Vorgang des Löschens einer Bestellung und des Hinzufügens zur Historie zu pumpen. Beobachtet.

Die Unzulänglichkeit der Plattform in dieser Hinsicht ist sehr traurig. Dinge, die gebündelt werden sollten, werden getrennt.

Prostotrader:

Nicht mehrmals, sondern nach der Anzahl der EAs, die derzeit im Terminal arbeiten.

Deshalb muss jeder EA seinen eigenen Auftrag bearbeiten

In diesem Fall muss ich das Ticket des Auftrags vom Anforderer noch irgendwo speichern, um es mit dem Ticket des Handels zu vergleichen. Und ich möchte einfach alle Speicherung in lokalen Variablen loswerden und Informationen ausschließlich vom Markt/Terminal erhalten, um lokale Infrastrukturrisiken auszugleichen.
12345678910
Neuer Kommentar
Grund der Beschwerde: