Wie man im MT5 mit OrderSend korrekt arbeitet - Seite 10
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
Verwenden Sie es.
Dies ist ein gutes Beispiel. Aber ich habe eine Frage. Was passiert, wenn OnTradeTransaction() die Daten bei der Auftragsverarbeitung nicht zurückgibt? Nun, sie könnten irgendwie verloren gegangen sein. Der Server hat sie gesendet, aber das Terminal hat sie nicht erhalten. Inwieweit ist gewährleistet, dass ich die erforderliche Anzahl von Aufrufen der Funktion OnTradeTransaction() für 100 % der gesendeten Aufträge erhalte und alle Transaktionsberichte das Terminal erreichen (ich interessiere mich hauptsächlich für transaction.type = TRADE_TRANSACTION_REQUEST).
Denn wenn ich diese Antwort nicht erhalte (z. B. wegen einer Unterbrechung der Verbindung), kann ich das Kennzeichen nicht löschen und alles bleibt bestehen.
Ich habe es nicht überprüft, aber vielleicht erhalten ALLE EAs nach OrderSend ein entsprechendes Ereignis für OnTradeTransaction.
Dann ist alles ohne Krücken und für mehrere EAs auf demselben Symbol gelöst.
Dies ist ein gutes Beispiel. Aber hier ist eine Frage, die mich stört. Was passiert, wenn OnTradeTransaction() die Daten der Auftragsabwicklung nicht zurückgibt? Nun, sie könnten irgendwie verloren gegangen sein. Der Server hat sie gesendet, aber das Terminal hat sie nicht empfangen. Inwieweit ist gewährleistet, dass ich die erforderliche Anzahl von Aufrufen der Funktion OnTradeTransaction() für 100 % der gesendeten Aufträge erhalte und alle Transaktionsberichte das Terminal erreichen (ich interessiere mich hauptsächlich für transaction.type = TRADE_TRANSACTION_REQUEST).
Denn wenn ich diese Antwort nicht erhalte (z. B. wegen eines Verbindungsabbruchs), werde ich die Kennzeichnung nicht entfernen und alles bleibt bestehen.
Ich hatte mehrere Male, dass das Ereignis OnTradeTransaction nicht auftrat,
Deshalb habe ich eine Funktion geschrieben, die den Status der Aufträge mit Hilfe eines Timers mit einer Periode von 0,5 Sekunden überprüft.
Die Implementierung verkompliziert den allgemeinen Code des Expert Advisors, aber es gibt keine 100%ige Garantie, wenn man über das Internet arbeitet,
dass alles wie am Schnürchen läuft.
Hinzugefügt von
Ich kam auf die Idee, hier nachzusehen
https://www.mql5.com/ru/blogs/post/557544
Ich hatte mehrere Male, dass das Ereignis OnTradeTransaction nicht stattfand,
Deshalb habe ich eine Funktion geschrieben, die den Status der Aufträge mit Hilfe eines Timers mit einer Periode von 0,5 Sekunden überprüft.
Die Implementierung verkompliziert den allgemeinen Code des Expert Advisors, aber es gibt keine 100%ige Garantie, wenn man über das Internet arbeitet,
dass alles wie am Schnürchen läuft.
Hinzugefügt von
Ich kam auf die Idee, hier nachzusehen
https://www.mql5.com/ru/blogs/post/557544
Ich habe den Eindruck, dass der Mann versucht, eine offene Tür zu durchbrechen, indem er für jede Transaktion spezielle magische Codes erstellt. Es gibt eine order_id, mit der eine Bestellung eindeutig identifiziert werden kann.
Oder sehe ich das falsch?
Ich habe den Eindruck, dass der Kerl eine offene Tür durchbricht, indem er spezielle magische Codes für jeden Handel erstellt. Es gibt eine order_id, die zur eindeutigen Identifizierung der Bestellung verwendet werden kann.
Oder sehe ich das falsch?
Ja, es gibt eine order_id, aber leider kommen manchmal Ereignisse nicht zu OnTradeTransaction
(Ich hatte es selbst schon mehrmals).
Und wohin dann mit der order_id?
Hinzugefügt von
Hier gab es heute eine Verzögerung bei der Serverantwort
2016.12.28 14:04:56.443 (GOLD-3.17,M1) CheckOrders: Задержка ответа сервера. Ожидание продолжается...
Ja, es gibt eine order_id, aber leider kommen manchmal Ereignisse nicht in OnTradeTransaction
(Ich hatte es selbst ein paar Mal).
Wohin soll die order_id dann "gestopft" werden?
Hinzugefügt von
Hier gab es heute eine Verzögerung bei der Serverantwort
2016.12.28 14:04:56.443 (GOLD-3.17,M1) CheckOrders: Задержка ответа сервера. Ожидание продолжается...
Neulich hatte ich eine andere "Ablenkung".
2016.12.23 15:04:02.924 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction EURUSD Retcode = 10009. Slippage = 1631.
2016.12.23 15:04:02.924 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction EURUSD Position is closed in 59699 mksec.
2016.12.23 15:04:02.924 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction EURUSD Retcode = 10009. Slippage = 1631.
2016.12.23 15:04:02.924 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction EURUSD Position is closed in 59712 mksec.
2016.12.23 15:04:02.992 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction GBPUSD Retcode = 10009. Slippage = 1379.
2016.12.23 15:04:02.992 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction GBPUSD Position is closed in 127691 mksec.
2016.12.23 15:04:02.992 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction All reposts are checked. Direction = 0
2016.12.23 15:04:02.993 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction Unexpected transaction request.
2016.12.23 15:04:02.993 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction EURGBP Retcode = 10009. Slippage = -40993.
2016.12.23 15:04:02.993 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction EURGBP Position is closed in 1339448077 mksec.
2016.12.23 15:04:02.993 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction All reposts are checked. Direction = -1
Es wurden drei Aufträge verschickt, was im Protokoll eindeutig vermerkt ist. Danach wurde die Funktion OnTradeTransactions() TRADE_TRANSACTION_TYPE viermal aufgerufen.
Der Funktionscode beginnt mit Prüfungen:
const MqlTradeRequest& request,
const MqlTradeResult& results)
{
if(transaction.type == TRADE_TRANSACTION_REQUEST && request.action == TRADE_ACTION_DEAL)
{
if(request.magic == ExpertMagic)
{
Das heißt, nur TRADE_TRANSACTION_REQUIEST mit seinem eigenen Expertenstempel kann dort hineingehen, wo die Drucker stehen...
Der Helpdesk begann zunächst, mich davon zu überzeugen, dass ich zwei identische EAs im Einsatz habe (offensichtlich auf demselben Chart, wenn man das Log betrachtet). Und dann sagten sie: "Du bist ein Narr, behebe die Fehler im Code".
Kurz gesagt, nach ihrer Meinung kann es nicht sein. Aus dem Protokoll geht jedoch eindeutig hervor, dass das Ereignis viermal auftrat.
Ja, es gibt eine order_id, aber leider kommen manchmal Ereignisse nicht in OnTradeTransaction
(Ich hatte es selbst ein paar Mal).
Wohin dann mit der order_id?
Hinzugefügt von
Hier hatte ich heute eine Verzögerung der Serverantwort.
2016.12.28 14:04:56.443 (GOLD-3.17,M1) CheckOrders: Задержка ответа сервера. Ожидание продолжается...
Aber trotzdem verstehe ich nicht, warum wir nicht nach Aufträgen über die Laufschrift suchen können? Es ist sehr einfach zu überprüfen, welche der von uns gesendeten Aufträge nicht bei TradeTransaction eingegangen sind. Und dann sehen Sie sich einfach den Status der Bestellung mit diesem Ticket in der Historie an.
Allerdings werden in der Auftragshistorie nur Aufträge mit dem Status FILLED angezeigt.
Und es ist immer noch nicht klar, warum der Auftrag nicht nach Ticker gesucht werden kann? Schließlich ist es einfach zu überprüfen, welcher Auftrag nicht zu TradeTransaction gekommen ist. Und dann sehen Sie sich einfach den Status der Bestellung mit diesem Ticker in der Historie an.
Als ich es selbst ausprobiert habe, gab es in der Auftragshistorie allerdings nur Aufträge mit dem Status GEFÜLLT.
Ja, da der Auftrag möglicherweise nicht in der Historie enthalten ist(ausstehender Auftrag usw.)
Hinzugefügt
Und Sie haben den falschen Code
Ja, da der Auftrag möglicherweise nicht in der Historie enthalten ist(ausstehender Auftrag usw.)
Hinzugefügt von
Und Sie haben den falschen Code
Was ist da los? Wie viele Fehler kann man in zwei Codezeilen machen?
Was ist da los? Wie viele Fehler können in zwei Codezeilen gemacht werden?
Nicht zwei, sondern eine :)
TRADE_TRANSACTION_REQUEST wird benötigt, wenn Sie OrderSendAsymc verwenden, um das Auftragsticket zu erhalten.