Gemeinsam lernen und schreiben in MQL5 - Seite 18

Neuer Kommentar
 
Yedelkin:

Nun, Sie verstehen schon. Ich sage Ihnen ganz genau, dass Sie das überprüfen können: Die Funktion OrderSend() gibt einen booleschen Wert zurück. In diesem Fall wird, wenn die Anfrage erfolgreich geprüft wurde, das Auftragsticket in eine Variable der Struktur MqlResult geschrieben. Ich nenne es für mich "Rückkehr der Bestellscheinfunktion". Hier ist der Link zur Quelle:"Wenn Sie eine Kaufanfrage mit der Funktion OrderSend() senden, können Sie sofort das Ticket der erstellten Bestellung herausfinden, wenn die Anfrage erfolgreich geprüft wurde.

Und wenn Sie auf Initiative des Moderators vom Thema abschweifen wollen, haben Sie eine ähnliche Antwort: Es gibt kein MQL5-Tutorial und wird es auch nie geben, so dass unklar ist, welches Tutorial Sie sich ansehen... Vielleicht können wir entweder über den Inhalt der Diskussion diskutieren oder über gar nichts? :)

Danke für die Antwort über das "Verbot", ich habe es verstanden.

Nicht ganz richtig verstanden, was passiert, wenn man eine Antwort vom Server erhält.

OrderSend() gibt tatsächlich einen booleschen Wert zurück, aber das ist nicht das Wichtigste - die Hauptsache ist die Struktur, die beim Empfang einer Antwort vom Server ausgefüllt wird.

Ja, wir schreiben ein Ticket in die Struktur (nicht nur Aufträge, sondern auch Geschäfte), aber ist es wichtiger als der Rest der Informationen in der Struktur?

Analysieren wir die Struktur der Antwort. Meiner Meinung nach stellt sich das Bild ungefähr wie folgt dar

struct MqlTradeResult
{
//Очень важная информация
uint     retcode;          // Код результата операции
//Важная информация (важна при успешном запросе)
ulong    deal;          // Тикет сделки, если она совершена
ulong    order;         // Тикет ордера, если он выставлен
//Малосущественная информация (важна при успешном запросе, а также в случае реквоты)
double   volume;        // Объем сделки, подтверждённый брокером
double   price;         // Цена в сделке, подтверждённая брокером
//Малосущественная информация (важна при реквоте)
double   bid;           // Текущая рыночная цена предложения (цены реквота)
double   ask;           // Текущая рыночная цена спроса (цены реквота)
//Не существенная информация
string   comment;       // Комментарий брокера к операции (по умолчанию заполняется расшифровкой)
};

PS

Der korrekte Name für eine Struktur ist MqlTradeResult und nicht MqlResult (obwohl es meiner Meinung nach keine große Rolle spielt).

Wenn die Anfrage korrekt ist und ausgeführt wird, dann sind Volumen und Preis wichtig, falls der Server "das Recht" hatte, die Datenparameter der Transaktion zu reduzieren, und es kann eine Reaktion des Expert Advisors auf Aktionen des Servers erfordern.

 
sergeev:

Leider habe ich es immer noch nicht verstanden.

Sie benötigen aus irgendeinem Grund ein "Zeit"-Feld in der Rückgabestruktur. Verwenden Sie die Zeit in der Reihenfolge, in der sie erscheint. Das reicht aus, um eine kleine Geschichte zu kontrollieren.

"Wenn Sie eine Kaufanfrage mit der Funktion OrderSend() senden, können Sie sofort das Ticket der Bestellung erfahren, das erstellt wurde, als die Anfrage erfolgreich geprüft wurde. Gleichzeitigkann es aber sein, dass der Auftrag selbst noch nicht auf dem Client-Terminal erscheint und der Versuch, ihn mit der Funktion OrderSelect auszuwählen, fehlschlägt. Aus dem zweiten Satz folgt, dass es nicht immer möglich ist, mit den Bestelleigenschaften (Bestellzeitpunkt) zu arbeiten, selbst wenn das Ticket bekannt ist. Daher ist die "Verwendung der Zeit in der Reihenfolge, in der sie erschienen ist" keine ideale Lösung. Es kann auch vorkommen, dass die Bestellung gar nicht geöffnet wird. Mein Ansatz würde das "kleine Problem der Verlaufskontrolle" lösen, unabhängig davon, was mit dem Auftrag geschah, bevor er in den Verlauf aufgenommen wurde.
 
Interesting:

Die Struktur sollte MqlTradeResult und nicht MqlResult heißen (obwohl das meiner Meinung nach nicht wirklich wichtig ist).

Ich habe "aus dem Gedächtnis" geschrieben, als Antwort auf den Rat, ein Lehrbuch zu studieren
Interessant:

Das ist nicht gerade ein korrektes Verständnis dessen, was passiert, wenn Sie eine Antwort vom Server erhalten.

OrderSend() gibt zwar einen booleschen Wert zurück, aber das ist nicht das Wichtigste. Das Wichtigste ist die Struktur, die durch den Empfang einer Antwort vom Server ausgefüllt wird.

Ja, in der Tat wird ein Ticket in die Struktur geschrieben (nicht nur Aufträge, sondern auch Geschäfte), aber ist es wichtiger als der Rest der Informationen in der Struktur?

Nun, lassen Sie uns nicht darüber streiten, wer mehr Ahnung hat :) Siehe meine Antwort an Sergejew. Und hier wiederhole ich: Nach der Logik der Strategie brauche ich nur das Ticket und den Zeitpunkt der Annahme des Auftrags für die Produktion. Was Sie hervorgehoben haben, ist weder das eine noch das andere. "Sehr wichtige Informationen" wie Retcodes tragen überhaupt nicht dazu bei, das Hochladen des Verlaufs zu optimieren, was ich im Allgemeinen meine.
 
Yedelkin:
"Wenn wir eine Kaufanfrage mit der Funktion OrderSend() senden, können wir sofort das Ticket der Bestellung erfahren, das erstellt wurde, als die Anfrage erfolgreich geprüft wurde. Gleichzeitigkann es aber sein, dass der Auftrag selbst noch nicht auf dem Client-Terminal erscheint und der Versuch, ihn mit der Funktion OrderSelect auszuwählen, fehlschlägt. Aus dem zweiten Satz folgt, dass es nicht immer möglich ist, mit den Bestelleigenschaften (Bestellzeitpunkt) zu arbeiten, selbst wenn das Ticket bekannt ist. Daher ist die "Verwendung der Zeit in der Reihenfolge, in der sie erschienen ist" keine ideale Lösung. Es kann auch vorkommen, dass die Bestellung gar nicht geöffnet wird. Mein Ansatz würde das Problem der Kontrolle eines kleinen Verlaufs lösen, unabhängig davon, was mit dem Auftrag geschah, bevor er in den Verlauf aufgenommen wurde.

Ich weiß nicht, ob es so wichtig ist, die Entwickler zu bitten, die Struktur von MqlTradeResult zu ergänzen (in Form der Zeit, für die ein Handel ausgeführt oder eine Order gesetzt wird).

Obwohl ich nicht verstehe, warum dies erforderlich ist, würde ich lieber Parameter zu OnTrade() hinzufügen.


 
Interesting:

Ich weiß nicht, ob es so wichtig ist, die Entwickler zu bitten, Ergänzungen in der Struktur MqlTradeResult vorzunehmen (als Zeitpunkt des ausgeführten Geschäfts oder der platzierten Order).

Nun, das habe ich von Anfang an gefragt :) Gab es einen Präzedenzfall, sozusagen :)

Zusatz: Wenn jemand diese Frage vor einem halben Jahr gestellt hätte, könnten wir auf ein relativ schnelles Erscheinen dieser Funktion hoffen, während wir auf das nächste Jahr warten - es ist einfacher, eine Variable für das Datum einzugeben. Es wird zwar nicht ganz genau sein, aber immerhin.

Interessant:

Obwohl ich nicht verstehe, warum dies notwendig ist, würde ich lieber Parameter zu OnTrade() hinzufügen.

Ich persönlich kann nicht länger darauf warten, dass die Handelsstruktur/Parameter erscheinen. Ich warte schon seit 9 Monaten auf sie. Ich muss mich mit dem begnügen, was ich habe.

 
Yedelkin:
Ich schrieb "aus dem Gedächtnis", als Antwort auf den Rat, ein Lehrbuch zu studieren Nun, lassen Sie uns nicht streiten, wer es besser weiß :) Sehen Sie sich meine Antwort an Sergejew an. Und hier wiederhole ich: Nach der Logik der Strategie brauche ich nur ein Ticket und die Zeit, in der der Auftrag in die Produktion geht. Was Sie hervorgehoben haben, ist weder das eine noch das andere. "Sehr wichtige Informationen" wie der Retcode tragen überhaupt nicht zur Optimierung des Hochladens des Verlaufs bei, und das meine ich im Allgemeinen.

1. orderSend() und das Hochladen der Historie, und von diesem Punkt aus, bitte näher erläutern (ich kann nicht verstehen, worüber wir reden, und ich denke, wir sind aus dem Gras).

2. Wenn die Analyse nur auf dem Ergebnis von OrderSend() basiert, ergibt sich logischerweise die folgende Reihenfolge der Aktionen

a) Überprüfen Sie den Retcode, wir müssen wissen, was wirklich passiert ist;

b) Wenn das Ergebnis erfolgreich ist, erhalten Sie das Ticket, die Menge und den Preis. Bei einer Neuausschreibung erhalten wir die neuen Preise (und prüfen, ob sie uns zufrieden stellen).

c) Wenn die Antwort zufriedenstellend ist und keine Fehler vorliegen, erhalten Sie ein Ticket und eine Uhrzeit. Sie können die Serverzeit verwenden oder versuchen, sie aus der Historie zu ziehen (für die ungefähre Berechnung ist es im Moment besser, die Serverzeit zu kennen);

d) Wenn wir mit der Antwort nicht (oder nur teilweise) zufrieden sind - das Volumen stimmt nicht überein oder wir haben eine erneute Anfrage - entscheiden wir über die nächsten Schritte.

PS

Kurzum, egal wie man es betrachtet, der Retcode sollte geprüft werden.

 
Interesting:

Ich weiß nicht, wovon du redest, und ich glaube, wir haben kein Gras mehr).

Schauen Sie sich die Diskussion von Anfang an an. ...Niemand bestreitet die Bedeutung von Retcode, aber für einfache Lösungen kann man darauf verzichten.
 
Yedelkin:
Schauen Sie sich die Diskussion von Anfang an an. ...Niemand bestreitet die Bedeutung von Retcode, aber für einfache Lösungen kann man darauf verzichten.

Wie wichtig ist diese Option für Sie?

c) Wenn die Antwort zufriedenstellend ist und es keine Fehler gibt, erhalten wir ein Ticket. Sie können die aktuelle Uhrzeit verwenden;

 
sergeev:

Wie wichtig ist diese Option für Sie?


Dies ist die Standardvariante (die ihre oben genannten Nachteile hat) + unabhängige Zeitersparnis. Da ich keine Retcode-Prüfung benötige, stellt sich nur die Frage nach der Zeitersparnis: entweder unabhängig oder aus ästhetischen Gründen mit MqlTradeResult. Das ist eigentlich der Grund für die Frage :)
 
Yedelkin:
Dies ist die Standardoption (die, wie oben erwähnt, ihre Nachteile hat) + Selbsteinsparungszeit. Da ich keine Retcode-Prüfung benötige, stellt sich nur noch die Frage nach der Zeitersparnis: entweder durch sich selbst oder ästhetisch mit MqlTradeResult. Das ist eigentlich der Grund für meine Frage :)

Wenn die Anfrage erfolgreich ist, wird der Handel früher oder später in die Historie aufgenommen und der Auftrag erscheint in der Liste. So können Sie genau herausfinden, was passiert ist und wie es passiert ist.

Und die vorgeschlagene Variante ist sozusagen "kurzfristig", für diejenigen, die alle notwendigen Daten auf einmal erhalten und sich nicht mit unnötigen Aktionen aufhalten wollen.

Natürlich kann man vielleicht etwas anderes in den Antwortserver einfügen, aber es gibt eine Reihe von Funktionen und Gründen, warum die Entwickler mit dieser Option nicht einverstanden sein könnten (und der Antrag, sorry wenig gerechtfertigt und durch überzeugende Argumente bestätigt).

PS

Vielleicht habe ich aber auch etwas übersehen, und die Entwickler haben beschlossen, dass das ganz vernünftig ist.

1...111213141516171819202122232425...46
Neuer Kommentar
Grund der Beschwerde: