Diskussion zum Artikel "Bibliothek für ein leichtes und schnelles Entwickeln vom Programmen für den MetaTrader (Teil XXI): Handelsklassen - Plattformübergreifendes Basis-Handelsobjekt" - Seite 2

Neuer Kommentar
 
Artyom Trishkin:


Vielen Dank, dies ist eine wichtige und nützliche Arbeit....

 
Vladimir Pastushak:

Vielen Dank, dies ist eine wichtige und nützliche Arbeit....

Sie sind willkommen

 
Hallo Artyom - gibt es einen einfacheren Weg, um die Ticketnummer zu erhalten, nachdem eine Order aufgegeben oder eine Position eröffnet wurde? Das scheint zu kompliziert zu sein :-( 
long CMySetup::PlaceOrder()
{
   bool order_ok;
   if (m_direction == POSITION_TYPE_BUY) {
      order_ok = m_engine.PlaceBuyLimit(m_lot_size, m_symbol, m_entry, m_hard_stop, m_ratio_target, m_magic, m_comment, m_expiry);
   }
   else {
      order_ok = m_engine.PlaceSellLimit(m_lot_size, m_symbol, m_entry, m_hard_stop, m_ratio_target, m_magic, m_comment, m_expiry);
   }

   if (order_ok) {
      CArrayObj* list = m_engine.GetListHistoryOrders();
      if (list != NULL) {
         list.Sort(SORT_BY_ORDER_TIME_OPEN);
         COrder* order = list.At(list.Total() - 1);
         if (order != NULL) {
            m_ticket = order.Ticket();
         }
      }
   }
   return m_ticket;
}
 
Dima Diall :
Hallo Artyom - gibt es einen einfacheren Weg, um die Ticketnummer zu erhalten, nachdem eine Order aufgegeben oder eine Position eröffnet wurde? Das scheint mir zu kompliziert :-(

Test Advisors zeigen alle Daten der zuletzt platzierten Order oder der offenen Position an. Das bedeutet, dass die Bibliothek diese Daten kennt. Sie implementiert Ereignisfunktionen, und die Bibliothek meldet alle eingestellten Ereignisse. Dementsprechend müssen Sie diese Ereignisse kontrollieren und das Objekt der letzten Order oder Position abrufen und daraus ein Ticket (und alle anderen Parameter der Order oder Position) übernehmen. Es ist noch nicht möglich, ein Beispiel zu geben. Aber ich werde bald zurückkommen und kann helfen.
Sie können selbst sehen, wo die Testberater Ereignisdaten nehmen und in das Protokoll drucken. Dementsprechend können Sie von Ihrem Programm aus auf dieselbe Stelle zugreifen und Daten aus diesen Ereignissen übernehmen.

В тестовых советниках же показываются все данные последнего выставленного ордера или открытой позиции. Это означает, что библиотека знает эти данные. В ней реализован событийный функционал, и о всех установленных событиях библиотека собщает. Соответственно, вам нужно контролировать эти события и получать объект последнего ордера или позиции, а из него брать тикет (и все остальные параметры ордера или позиции). Сейчас пока нет возможности привести какой-либо пример. Но в скором времени вернусь и смогу помочь.
Можете самостоятельно поглядеть откуда тестовые советники берут данные о событиях и распечатывают их в журнал. Соответственно, можете из своей программы получить доступ к той же точке и брать данные от этих событий.

 
Artyom Trishkin:

Die Testberater zeigen alle Daten der zuletzt erteilten Order oder der offenen Position an. Das bedeutet, dass die Bibliothek diese Daten kennt. Sie implementiert die Ereignisfunktionalität, und die Bibliothek meldet alle eingestellten Ereignisse. Dementsprechend müssen Sie diese Ereignisse kontrollieren und das Objekt der letzten Order oder Position abrufen und daraus ein Ticket (und alle anderen Parameter der Order oder Position) übernehmen. Es ist noch nicht möglich, ein Beispiel zu geben. Aber ich werde bald zurückkommen und kann helfen.
Sie können selbst sehen, wo die Testberater Ereignisdaten nehmen und in das Protokoll drucken. Dementsprechend können Sie von Ihrem Programm aus auf dieselbe Stelle zugreifen und Daten aus diesen Ereignissen übernehmen.

Ja, ich verstehe - ich schaue mir das gerade genauer an und frage mich, ob mein Event-Handler garantiert sofort aufgerufen wird und welche Art von Analyse ich durchführen muss, wenn mehrere Aufträge/Positionen angefordert wurden, um sicherzustellen, dass ich die Ereignisse korrekt mit jeder Anforderung abgleiche... all das nur, um die Ticketnummer herauszufinden, die die Bibliothek z.B. für ausstehende Aufträge in 'm_result' innerhalb von CTradeObj::SetOrder() erhält.

#ifdef __MQL5__
   return(!this.m_async_mode ? ::OrderSend(this.m_request,this.m_result) : ::OrderSendAsync(this.m_request,this.m_result));
#else 
   ::ResetLastError();
   int ticket=::OrderSend(this.m_request.symbol,
                          this.m_request.type,
                          this.m_request.volume,
                          this.m_request.price,
                          (int)this.m_request.deviation,
                          this.m_request.sl,
                          this.m_request.tp,
                          this.m_request.comment,
                          (int)this.m_request.magic,
                          this.m_request.expiration,
                          clrNONE);
// ...
   if(ticket!=WRONG_VALUE)
     {
      this.m_result.order=ticket;
      this.m_result.price=(::OrderSelect(ticket,SELECT_BY_TICKET) ? ::OrderOpenPrice() : this.m_request.price);
      this.m_result.volume=(::OrderSelect(ticket,SELECT_BY_TICKET) ? ::OrderLots() : this.m_request.volume);
      return true;
     }
// ... 
#endif

Deshalb denke ich, dass es nützlicher wäre, wenn die Ticketnummer (oder -1, wenn sie nicht erfolgreich war) von CEngine::PlaceBuyLimit() und all diesen Methoden zurückgegeben wird, denn wenn man eine Order platziert oder eine Position eröffnet, möchte man meistens sofort die Ticketnummer aufzeichnen, damit man später darauf zurückgreifen kann... Vielleicht könnte es sogar einen COrder*-Zeiger oder NULL zurückgeben , wenn es nicht erfolgreich war. Meiner bescheidenen Meinung nach macht es die Bibliothek unnötig kompliziert, wenn man den DoEasy-Benutzer zwingt, dafür eine Ereignisbehandlung zu implementieren.

Wahrscheinlich gibt es einen guten Grund für Ihren Ansatz, daher bin ich mir nicht sicher, ob Sie damit einverstanden sind; wenn nicht, wäre ich sehr daran interessiert, die Gründe für Ihre Designentscheidung zu verstehen ;-)

 
Dima Diall :

Ja, ich verstehe - ich schaue mir das gerade genauer an und frage mich, ob mein Event-Handler garantiert sofort aufgerufen wird, und wenn mehrere Aufträge/Positionen angefordert wurden, welche Art von Analyse ich durchführen muss, um sicherzustellen, dass ich die Ereignisse korrekt mit jeder Anforderung abgleiche ... all das nur, um die Ticketnummer herauszufinden, die die Bibliothek z. B. für ausstehende Aufträge in 'm_result' innerhalb von CTradeObj::SetOrder() erhält

Deshalb denke ich, dass es nützlicher wäre, wenn die Ticketnummer (oder -1, wenn sie nicht erfolgreich war) von CEngine::PlaceBuyLimit() und all diesen Methoden zurückgegeben wird , denn wenn man eine Order platziert oder eine Position eröffnet, möchte man meistens sofort die Ticketnummer aufzeichnen, damit man später darauf zurückgreifen kann... Vielleicht könnte es sogar einen COrder*-Zeiger oder NULL zurückgeben , wenn es nicht erfolgreich war. Meiner bescheidenen Meinung nach macht es die Bibliothek unnötig kompliziert, wenn der DoEasy-Benutzer gezwungen wird, dafür ein Event-Handling zu implementieren.

Wahrscheinlich gibt es einen guten Grund für Ihren Ansatz, daher bin ich mir nicht sicher, ob Sie damit einverstanden sind; wenn nicht, wäre ich sehr daran interessiert, die Gründe für Ihre Designentscheidung zu verstehen ;-)

Alles ist sehr einfach. In MQL5 ist das erfolgreiche Senden eines Handelsauftrags an den Server keine Garantie für seine Ausführung. Der Erfolg des Sendens ist ein Millet-Check für die Korrektheit der Parameter in einem Handelsauftrag. Die Ausführung des Auftrags liegt bei der Börse. Wir können nur die Tatsache nutzen, dass sich die Handelsumgebung geändert hat, und nach dem Erkennen dieser Änderung weitermachen. Aus diesem Grund verwende ich die in der Serverantwort erhaltenen Daten nicht.

Всё очень просто. В MQL5 успешность отсылки торгового приказа на сервер не гарантирует его исполнения. Успешность отсылки - это просо проверка на коректность параметров в торговом приказе. Исполнение приказа лежит на стороне биржи. Мы можем лишь использовать факт изменения торгового окружения, и после обнаружения его изменения уже двигаться дальше. Именно по этой причине я не использую данные, полученные в ответе сервера.

 
Artyom Trishkin:

Alles ist sehr einfach. In MQL5 ist das erfolgreiche Senden eines Handelsauftrags an den Server keine Garantie für seine Ausführung. Der Erfolg des Sendens ist eine Milchmädchenrechnung für die Korrektheit der Parameter in einem Handelsauftrag. Die Ausführung des Auftrags liegt bei der Börse. Wir können nur die Tatsache nutzen, dass sich die Handelsumgebung geändert hat, und nach dem Erkennen dieser Änderung weitermachen. Aus diesem Grund verwende ich die in der Serverantwort erhaltenen Daten nicht.

OK, ich versuche, diesen Ansatz in mein EA-Framework zu implementieren, um es einfacher zu verwalten, indem ich Ihren TestDoEasyPart39.mq5 als Leitfaden verwende, aber ich habe einige Probleme mit verpassten Ereignissen - ich untersuche und debugge noch (alles im Tester-Modus)... Ich würde mich über weitere Code-Beispiele freuen, die zeigen, wie Sie dies selbst in anderen EAs machen, wenn Sie welche teilen können.

Ich verwende immer noch die Bibliotheksversion aus Teil 39; ist dies die beste Version für den Moment oder empfehlen Sie ein Upgrade auf eine neuere Version?

 
Dima Diall :

OK, ich versuche, diesen Ansatz in meinem EA-Framework zu implementieren, um es einfacher zu verwalten mit Ihrem TestDoEasyPart39.mq5 als Leitfaden, aber ich habe einige Probleme mit verpassten Ereignissen - noch untersuchen/Debugging (alles im Tester-Modus für jetzt)... Ich würde mich über weitere Code-Beispiele freuen, wie Sie dies selbst in anderen EAs tun, wenn Sie einige teilen können.

Ich verwende immer noch die Bibliotheksversion aus Teil 39; ist dies die beste Version für den Moment oder empfehlen Sie ein Upgrade auf eine neuere Version?

Bis jetzt sind alle nachfolgenden Versionen der Erstellung von Indikatoren gewidmet.

Ich werde bald zu den Beratern zurückkehren. Dort werde ich auch Nutzermeldungen überprüfen, dass einige (gleichzeitig stattfindende) Handelsereignisse verloren gehen.
Und dann kann ich Ihnen zeigen, wie Sie das Ereignismodell der Bibliothek nutzen können.

Пока все последующие версии посвящены созданию индикаторов.

Скоро опять вернусь к советникам. Там и проверю сообщения пользователей о том, что некоторые торговые события (происходящие одновременно) теряются.
И там же смогу тогда показать как использовать событийную модель библиотеки.

 
Artyom Trishkin:

Bislang sind alle nachfolgenden Versionen der Erstellung von Indikatoren gewidmet.

Ich werde mich bald wieder mit den Beratern beschäftigen. Dort werde ich auch Nutzermeldungen überprüfen, dass einige (gleichzeitig auftretende) Handelsereignisse verloren gehen.
Und dann kann ich Ihnen zeigen, wie Sie das Ereignismodell der Bibliothek nutzen können.

Wann werden Sie voraussichtlich wieder mit der Arbeit an Funktionen für Expert Advisors beginnen? Abhängig von Ihrer Antwort muss ich möglicherweise meine eigenen Multiplattform-Klassen/Methoden für die vereinfachte Platzierung von Aufträgen, das Eröffnen von Positionen usw. wählen - zumindest für mein aktuelles Projekt.

Wie kann ich bei der Verarbeitung von Handelsereignissen wie TRADE_EVENT_PENDING_ORDER_PLASED oder TRADE_EVENT_POSITION_OPENED sicherstellen, dass ein bestimmtes Ereignis einem bestimmten Handelsauftrag entspricht, den ich zuvor eingereicht habe? Derzeit habe ich nur eine Order/Position pro Symbol, so dass es einfach ist, zu überprüfen, ob das Symbol des Ereignisses mit meiner Anfrage übereinstimmt... Später sollte mein EA jedoch in der Lage sein, mehrere Orders/Positionen auf demselben Symbol zu öffnen (unter Verwendung einer einzigen magischen Zahl), so dass es hoffentlich nicht notwendig ist, Einstiegspreis, SL, TP usw. zu vergleichen. Ich dachte an die Verwendung verschiedener magischer Zahlen oder an die Funktion, die die Gruppen #1 und #2 in die magische Zahl packt.

Ich bin ein wenig verwirrt und nicht ganz sicher, was der beste Ansatz ist, um Handelsereignisse mit Anfragen abzugleichen - können Sie mir bitte erst einmal dabei helfen? Wenn ich eine Handelsanfrage zuverlässig mit ihrer Ticketnummer verknüpfen kann, glaube ich, dass ich DoEasy weiterhin für dieses Projekt verwenden kann.

Library for easy and quick development of MetaTrader programs (part XXVI): Working with pending trading requests - first implementation (opening positions)
Library for easy and quick development of MetaTrader programs (part XXVI): Working with pending trading requests - first implementation (opening positions)
  • www.mql5.com
I have already mentioned the concept of a pending request in a number of previous articles. In this article, we are going to figure out what it is and why we need it, as well as start implementing pending requests. When receiving and handling a trade server error, we sometimes need to wait and repeat the request. In the simplest case, waiting...
 
Dima Diall :

Wann werden Sie voraussichtlich wieder mit der Arbeit an Funktionen für Expert Advisors beginnen? Abhängig von Ihrer Antwort muss ich möglicherweise meine eigene Multiplattform-Klasse/Methoden für die vereinfachte Platzierung von Aufträgen, das Eröffnen von Positionen usw. wählen, zumindest für mein aktuelles Projekt.

Wie kann ich bei der Verarbeitung von Handelsereignissen wie TRADE_EVENT_PENDING_ORDER_PLASED oder TRADE_EVENT_POSITION_OPENED sicherstellen, dass ein bestimmtes Ereignis einem bestimmten Handelsauftrag entspricht, den ich zuvor eingereicht habe? Derzeit habe ich nur eine Order/Position pro Symbol, so dass es einfach ist, zu überprüfen, ob das Symbol des Ereignisses mit meiner Anfrage übereinstimmt... Später sollte mein EA jedoch in der Lage sein, mehrere Orders/Positionen für dasselbe Symbol zu öffnen (unter Verwendung einer einzigen magischen Zahl), so dass es hoffentlich nicht notwendig ist, Einstiegspreis, SL, TP usw. zu vergleichen. Ich dachte an die Verwendung verschiedener magischer Zahlen oder an die Funktion, die die Gruppen #1 und #2 in die magische Zahl packt.

Ich bin etwas verwirrt und nicht ganz sicher, was der beste Ansatz ist, um Handelsereignisse mit Anfragen abzugleichen - können Sie mir dabei bitte erst einmal helfen? Wenn ich eine Handelsanfrage zuverlässig mit ihrer Ticketnummer verknüpfen kann, glaube ich, dass ich DoEasy weiterhin für dieses Projekt verwenden kann.

Wenn Sie eine Handelsanfrage mit einer Position vergleichen müssen, dann ist es am einfachsten, die Positionskennung zu setzen (keine Magie). Jede Anfrage hat ihren eigenen Bezeichner. Die Magie des Beraters kann für alle Positionen gleich gelassen werden. Anhand der Kennung (sie wird in die Magie einer Position oder eines Auftrags geschrieben und geht nie verloren) können Sie dann jederzeit die Anfrage und die Position/den Auftrag genau abgleichen.
123
Neuer Kommentar