trade.PositionClose führt zu keinem Aufruf von OnTradeTransaction?

Neuer Kommentar
 

Hallo.

Ich habe da eine Verständnisfrage.

Normalerweise wenn irgendwelche "Aktionen" durchgeführt werden, git es doch immer auch einen Aufruf von OnTradeTransaction()?
Soweit richtig?

Nun wundere ich mich, wenn ich die Ctrade klasse nutzen, und hier mit der Funktion trade.PositionClose eine Position schließe, dass offenbach kein Aufruf von  OnTradeTransaction() mehr stattfindet. 
Folgender Testcode soll dies verdeutlichen.

void OnTradeTransaction(const MqlTradeTransaction &trans,
                        const MqlTradeRequest &request,
                        const MqlTradeResult &result)
{
   ENUM_TRADE_TRANSACTION_TYPE type=trans.type;
   Print("");
   Print("OnTradeTransaction > trans.typ:"+type+"/"+EnumToString(trans.type)+" trans.order: "+trans.order+" tans.deal: "+trans.deal);
 }

if(trade.PositionClose(ticket)){   Print("Error Ticket: "+ticket+" closed"); }

Die Position wird soweit auch richtig geschlossen und im Logfile steht auch z.B.
"Trade 2022.12.01 00:09:03   market sell 0.01 EURUSD, close #2 (1.04054 / 1.04062)

CS 0 09:01:08.413 Trades 2022.12.01 00:09:03   deal #3 sell 0.01 EURUSD at 1.04054 done (based on order #3)
CS 0 09:01:08.413 Trade 2022.12.01 00:09:03   deal performed [#3 sell 0.01 EURUSD at 1.04054]
CS 0 09:01:08.413 Trade 2022.12.01 00:09:03   order performed sell 0.01 at 1.04054 [#3 sell 0.01 EURUSD at 1.04054]"

Was ich vermisse ist jedoch der Aufruf von onTradeTransaction(), hätte hier nicht auch ein entsprechender Aufruf erfolgen müssen?

Am Ende möchte ich das Ereignis abfangen, wenn die Position abschließend geschlossen wurde.

Habe ich etwas falsch verstanden!?

 

Doch, je nach Ereignis sogar bis zu viermal! Versuch mal:

void OnTradeTransaction(const MqlTradeTransaction &trans,
                        const MqlTradeRequest &request,
                        const MqlTradeResult &result)
{
      Print(__FUNCTION__," ",__LINE__," tSec: ",(ulong)TimeCurrent());
}

Leider werden fast nie die relevanten Informationen oder mal hier mal da mitgeschickt :(

https://www.mql5.com/de/docs/event_handlers/ontradetransaction
Dokumentation zu MQL5: Ereignisbehandlung / OnTradeTransaction
Dokumentation zu MQL5: Ereignisbehandlung / OnTradeTransaction
  • www.mql5.com
OnTradeTransaction - Ereignisbehandlung - Nachschlagewerk MQL5 - Nachschlagewerk über die Sprache des algothitmischen/automatischen Handels für MetaTrader 5
 
MQL5-Kochbuch: Verarbeitung des TradeTransaction-Ereignisses
https://www.mql5.com/de/articles/1111
 
So eine einfache Anforderung eines EAs an so eine Funktion und doch so eine komplizierte Umsetzung. Ein EA ist doch kein Buch- oder Bilanzprüfer. :(
 
Carl Schreiber #:
So eine einfache Anforderung eines EAs an so eine Funktion und doch so eine komplizierte Umsetzung. Ein EA ist doch kein Buch- oder Bilanzprüfer. :(

Du hast Recht, der Artikel ist ein Bisschen Overkill, aber er bietet umfangreiche Antworten über die Funktion von CTrade und OnTradeTransaction mit ihren Strukturen MqlTransaction, MqlRequest und MqlResult.

 

Naja, den Artikel kannte ich nicht wirklich, aber dass:

  1. OnTradeTransaction für eine Sache zwischen 1 und 4 Mal aufgerufen wird - welcher Aufruf ist der entscheidende?
  2. Die drei Strukturen fast immer leer sind.
  3. Wichtige Dinge wir die Ticketnummern von Deal, Position und Order, mal hier mal da mal gar nicht eingetragen sind.
  4. Manchmal gibt es in result den return-code 10009 (=OK) manchmal nicht.
  5. bei ORDER_TYPE_BUY nicht weiß ist das (immer noch) 0, weil die Struktur vor der Wertezuweisung insgesamt immer auf 0 gesetzt wurde oder wurde tatsächlich ORDER_TYPE_BUY gesetzt?
Und da betrifft eine der eigentlich wichtigsten Funktionen für den Handel: Was wurde aus meinem Auftrag.


Ich würde mir wünsche, das wäre eine Ereignisfunktion mit eine Struktur, die das Ergebnis beinhaltet und die für jeden Vorgang NUR 1 MAL aufgerufen wird mit allen Informationen, sodass man die Struktur zum Positions-Update weiter verwenden kann und dem Ergebnis: 1) zur Gänze durchgeführt, 2) teilweise durchgeführt und 3) fehlgeschlagen mit Fehlernummer, um sofort darauf reagieren zu können.

Mehr braucht es nicht bzw mehr bedeutet doch nur einen zusätzlichen (unnötigen) Aufwand.

Da bemüht sich MQ das Terminal mit seinen Testmöglichkeiten immer noch schneller zu machen und dann zwingt man uns zu sinnlosen Extrarunden.

:(

 
Carl Schreiber #:

Naja, den Artikel kannte ich nicht wirklich, aber dass:

  1. OnTradeTransaction für eine Sache zwischen 1 und 4 Mal aufgerufen wird - welcher Aufruf ist der entscheidende?
  2. Die drei Strukturen fast immer leer sind.
  3. Wichtige Dinge wir die Ticketnummern von Deal, Position und Order, mal hier mal da mal gar nicht eingetragen sind.
  4. Manchmal gibt es in result den return-code 10009 (=OK) manchmal nicht.
  5. bei ORDER_TYPE_BUY nicht weiß ist das (immer noch) 0, weil die Struktur vor der Wertezuweisung insgesamt immer auf 0 gesetzt wurde oder wurde tatsächlich ORDER_TYPE_BUY gesetzt?
Und da betrifft eine der eigentlich wichtigsten Funktionen für den Handel: Was wurde aus meinem Auftrag.


Ich würde mir wünsche, das wäre eine Ereignisfunktion mit eine Struktur, die das Ergebnis beinhaltet und die für jeden Vorgang NUR 1 MAL aufgerufen wird mit allen Informationen, sodass man die Struktur zum Positions-Update weiter verwenden kann und dem Ergebnis: 1) zur Gänze durchgeführt, 2) teilweise durchgeführt und 3) fehlgeschlagen mit Fehlernummer, um sofort darauf reagieren zu können.

Mehr braucht es nicht bzw mehr bedeutet doch nur einen zusätzlichen (unnötigen) Aufwand.

Da bemüht sich MQ das Terminal mit seinen Testmöglichkeiten immer noch schneller zu machen und dann zwingt man uns zu sinnlosen Extrarunden.

:(

Hm. Okay ich hab mir das immer so zurecht erklärt (haha...) dass es ja eine asynchrone bearbeitung gibt und wie Du sagtest, erst schickst du einen Auftrag, dann kommt die Bestätigung zurück (oder nicht?!?), dann gibt es order, deal und position und das mach es nicht einfacher. Aber was bräuchte man denn prinzipiell als Wrapper für das Durcheinander um einfach damit arbeiten zu können? Also OnTradeTransaction beinhaltet viele verschiedene Enums. Da könnte man mit EnumToString Alles in Stringketten verwandeln und dann Alles parsen...? Das wäre vielleicht nicht schnell, aber man würde ein paar Zusammenhänge herausfinden, ein paar Grundregeln, die IMMER gelten.

Vielleicht könnte man, wenn man sämtliche Enums in Integers casten und dann DARAUS eine lange Stringkette machen würde, auch diese auf wiederkehrende Muster durchparsen. Da würde man wahrscheinlich nur ein Zehntel an RAM und Rechenleistung brauchen, wie bei dem ersten Ansatz.

Oder man könnte die so hergestellten Zahlen als eine Art Rückgabecode (Transaktionskennzahlen) verwenden?

Ja das Problem mit ORDER_TYPE_BUY wurde schon von mehreren Mitgliedern bemängelt und das gehört wirklich gefixt. Die Struktur ist schon kompliziert genug, den Fehler braucht man da nicht wirklich.

Gibt es eigentlich viele Leute die MT4Orders.mqh verwenden, um die Sache zu vereinfachen?

 

Ja das Problem mit ORDER_TYPE_BUY wurde schon von mehreren Mitgliedern bemängelt und das gehört wirklich gefixt. Die Struktur ist schon kompliziert genug, den Fehler braucht man da nicht wirklich.

ORDER_TYPE_BUY wird wohl nicht gefixt, weil sonst bestehende Programme durcheinander kommen werden - seufz ist wohl eine Last der Geschichte.

ZB, alle ORDER_TYPE_... %2==0 heißt buys und alle ORDER_TYPE_... %2==1 sind Sells.

Immerhin habe sie das Problem schon erkannt, denn bei ENUM_TRADE_TRANSACTION_TYPE gibt es keine (offizielle) 0, aber eine nicht-offizielle ENUM_TRADE_REQUEST_ACTIONS::0, die ist 0 und bedeutet nix wurde zugewiesen.

Aber mit einer (neuen) überladenen Funktion OnTradeTransaction() mit nur einer (neuen) Ergebnisstruktur und eigenen ENUMS mit 0 = "nix passiert" wäre das Problem behoben und vieles für uns einfacher und schneller - schade Weihnachten ist schon vorbei.

 
Carl Schreiber #:

ORDER_TYPE_BUY wird wohl nicht gefixt, weil sonst bestehende Programme durcheinander kommen werden - seufz ist wohl eine Last der Geschichte.

Ich verstehe die Begründung nicht. Wenn eine Funktion falsche Enum Werte liefert, benutzt die doch eh keiner. Was soll denn da durcheinander kommen, wenn der Wert jetzt korregiert wird. Lasse mich gern eines Besseren belehren, aber ich glaube nicht dass das passieren wird.

Im Gegensatz zu OnTradeTransaction, welche wirklich eine Last der Geschichte ist. Wenn Du da Alles umstellst, wird das je nachdem richtig Probleme geben, Leute müssen ihre ganzen Tools ne schreiben usw. 

Kombiniere, kombiniere... OnTradeTransaction wird sich wohl eher nicht verändern, das wäre sonst schlecht fürs Geschäft. Bei ORDER_TYPE würde ich es nicht vertehen warum es so (falsch) bleiben sollte...
 
Tobias Johannes Zimmer #:
Ich verstehe die Begründung nicht. Wenn eine Funktion falsche Enum Werte liefert, benutzt die doch eh keiner. Was soll denn da durcheinander kommen, wenn der Wert jetzt korregiert wird. Lasse mich gern eines Besseren belehren, aber ich glaube nicht dass das passieren wird.

Im Gegensatz zu OnTradeTransaction, welche wirklich eine Last der Geschichte ist. Wenn Du da Alles umstellst, wird das je nachdem richtig Probleme geben, Leute müssen ihre ganzen Tools ne schreiben usw. 

Kombiniere, kombiniere... OnTradeTransaction wird sich wohl eher nicht verändern, das wäre sonst schlecht fürs Geschäft. Bei ORDER_TYPE würde ich es nicht vertehen warum es so (falsch) bleiben sollte...
Die 0 für BUY gibt es bereits seit MT4 (oder noch früher). Würde das geändert werden, würden viel alte EAs (CodeBase, Artikel, Dok., Market ...)  plötzlich falsche handeln (kaufen statt verkaufen?) ....
 
Carl Schreiber #:

Immerhin habe sie das Problem schon erkannt, denn bei ENUM_TRADE_TRANSACTION_TYPE gibt es keine (offizielle) 0, aber eine nicht-offizielle ENUM_TRADE_REQUEST_ACTIONS::0, die ist 0 und bedeutet nix wurde zugewiesen.

Ich glaube ich habe da ein anderes Problem reininterpretiert, kann aber das Thema nicht mehr finden. 

Glaube aber jetzt zu sehen was Du meintest, wenn 0 default ist, dann sollte 0 nicht mit einem Ergebnis verwechselbar sein und man müsste dann die ganzen Enums von order type um eins verschieben. 

Aber immerhin gut zu wissen, dass man die 0 bei order type ignorieren kann wenn transaction type auch 0 ist

Neuer Kommentar
Grund der Beschwerde: