Diskussion zum Artikel "Bibliothek für ein leichtes und schnelles Entwickeln vom Programmen für den MetaTrader (Teil XI). Kompatibilität mit MQL4 - Ereignisse des Schließens von Positionen"

Neuer Kommentar
 

Neuer Artikel Bibliothek für ein leichtes und schnelles Entwickeln vom Programmen für den MetaTrader (Teil XI). Kompatibilität mit MQL4 - Ereignisse des Schließens von Positionen :

Wir setzen die Entwicklung einer großen plattformübergreifenden Bibliothek fort, die die Entwicklung von Programmen für MetaTrader 5 und MetaTrader 4 Plattformen vereinfacht. Im zehnten Teil haben wir unsere Arbeit an der Bibliothekskompatibilität mit MQL4 fortgesetzt und die Ereignisse der Eröffnung von Positionen und der Aktivierung von offenen Orders definiert. In diesem Artikel werden wir die Ereignisse des Schließens von Positionen definieren und die nicht verwendeten Auftragseigenschaften beseitigen.

Nun werden die Ereignisse teilweises Schließen und Entfernen eine Pending-Order als separate Ereignisse definiert.

Starten Sie den EA noch einmal und klicken Sie auf die Schaltflächen zur Beobachtung der Definition von Ereignissen:

Wie wir sehen können, werden die Ereignisse korrekt erfasst. Das Ereignis von Schließen-Durch ist definiert, Änderungen der Stop-Level und die Preise der Pending-Orders werden ebenfalls verfolgt.

Autor: Artyom Trishkin

 

Ich habe einige Anmerkungen im Zusammenhang mit der Wirkung der Millisekunden Zeitvariablen, und insbesondere über die CHistoryCollection::GetListByTime(...) Funktion in Bezug auf MQL5 Version.

Sie sind (in abnehmender Reihenfolge der Relevanz):

1) Sowohl Datetime-Variablen als auch lange Millisekunden-Zeitvariablen stellen die seit dem 01.01.1970 verstrichene Zeit dar. Allerdings liegt zwischen den tatsächlich gespeicherten Werten ein Faktor von 1000. Daher können beide Typen einander nicht direkt zugewiesen werden. Infolgedessen funktioniert GetListByTime(..) nach der Änderung nicht mehr, da es datetime-Parameter direkt in der Eigenschaft time millisecond von COrder m_order_instance speichert. Eine mögliche Lösung könnte darin bestehen, zwei neue Konvertierungsfunktionen (wahrscheinlich in delib.mqh) einzubauen, die sich um den Faktor 1000 kümmern:

//+------------------------------------------------------------------+
//| Konvertiert Zeit in Millisekunden in datetime |
//+------------------------------------------------------------------+
datetime TimeMSCtoDate(const long time_msc)
  {
   return datetime(time_msc/1000);
  }
//+------------------------------------------------------------------+
//| Konvertiert datetime in Zeit in Millisekunden |
//+------------------------------------------------------------------+
long DatetoTimeMSC(const datetime time_sec)
  {
   return long(time_sec * 1000);
  }
Diese Art von Problem würde nicht auftreten, wenn MetaQuotes von Anfang an datetime-Variablen als verstrichene Zeit in Millisekunden oder sogar in Mikrosekunden definiert hätte (wer sagt denn, dass Roboter in zehn Jahren nicht in weniger als Millisekunden handeln werden?).
Wie auch immer, das Problem ist zumindest in den GetListByTime(...) -Funktionen in den Klassen CEventsCollection und CMarketCollection vorhanden, vielleicht auch an einigen anderen Stellen...
2) Die History-Sammlung ist ein Objekt, das weiß, ob es sortiert ist oder nicht, und wenn ja, welches die Sortier-Eigenschaft ist (FunktionSortMode() ), während die Funktion GetListByTime(...) davon ausgeht, dass die Sammlung bereits nach den Eigenschaften ORDER_PROP_TIME_OPEN oder ORDER_PROP_TIME_CLOSE sortiert ist (nur ORDER_PROP_TIME_OPEN in den Versionen CEventsCollection und CMarketCollection ). Gemäß der OOP-Philosophie sollte GetListByTime(...) prüfen, ob die Sammlung richtig sortiert ist, bevor es weitergeht.
Tatsächlich hat das Programmbeispiel TestDoEasyPart03_1.mq5 eine nach ORDER_PROP_TIME_OPEN (dem Standard in MT5) geordnete Historiensammlung erstellt und dann GetListByTime(...,SELECT_BY_TIME_CLOSE) aufgerufen. Mit dieser Prüfung wäre dies angezeigt worden!
3) Keine große Sache, aber da MT5 der neue Standard sein soll, warum nicht SELECT_BY_TIME_OPEN als Standardwert für den Parameter select_time_mode der Funktion CHistoryCollection::GetListByTime(...) festlegen?

Den früheren Vorschlägen folgend, wäre dies der Code der Funktion CHCistoryCollection::GetListByTime(...):

public:
        .......

   //--- Auswahl von Aufträgen aus der Sammlung mit Zeitangaben von Beginn_Zeit bis Ende_Zeit
   CArrayObj        *GetListByTime(const datetime begin_time=0,const datetime end_time=0,
                                   const ENUM_SELECT_BY_TIME select_time_mode=SELECT_BY_TIME_OPEN);
        .......

//+------------------------------------------------------------------+
Aufträge aus der Sammlung mit Zeitangabe auswählen //|
//| von Anfang_Zeit bis Ende_Zeit|
//+------------------------------------------------------------------+
CArrayObj *CHistoryCollection::GetListByTime(const datetime begin_time=0,const datetime end_time=0,
                                             const ENUM_SELECT_BY_TIME select_time_mode=SELECT_BY_TIME_OPEN)
  {
   ENUM_ORDER_PROP_INTEGER property=(select_time_mode==SELECT_BY_TIME_CLOSE ? ORDER_PROP_TIME_CLOSE : ORDER_PROP_TIME_OPEN);
   
   if(property != (ENUM_ORDER_PROP_INTEGER)m_list_all_orders.SortMode())
      {
      ::Print(DFUN+"History list not prpperly sorted");           //Vielleicht Nachricht, die zu ENUM_MESSAGES_LIB hinzugefügt werden soll
      return NULL;
      }

   CArrayObj *list=new CArrayObj();
   if(list==NULL)
     {
      ::Print(DFUN+CMessage::Text(MSG_LIB_SYS_FAILED_CREATE_TEMP_LIST));
      return NULL;
     }
   datetime begin=begin_time,end=(end_time==0 ? END_TIME : end_time);
   if(begin_time>end_time) begin=0;
   list.FreeMode(false);
   ListStorage.Add(list);
   //---
   this.m_order_instance.SetProperty(property,DatetoTimeMSC(begin));
   int index_begin=this.m_list_all_orders.SearchGreatOrEqual(&m_order_instance);
   if(index_begin==WRONG_VALUE)
      return list;
   this.m_order_instance.SetProperty(property,DatetoTimeMSC(end));
   int index_end=this.m_list_all_orders.SearchLessOrEqual(&m_order_instance);
   if(index_end==WRONG_VALUE)
      return list;
   for(int i=index_begin; i<=index_end; i++)
      list.Add(this.m_list_all_orders.At(i));
   return list;
  }



 
Alvaro Arioni :

Ich habe einige Anmerkungen im Zusammenhang mit der Wirkung der Millisekunden Zeitvariablen, und insbesondere über die CHistoryCollection::GetListByTime(...) Funktion in Bezug auf MQL5 Version.

Sie sind (in abnehmender Reihenfolge der Relevanz):

1) Sowohl Datetime-Variablen als auch lange Millisekunden-Zeitvariablen stellen die seit dem 01.01.1970 verstrichene Zeit dar. Allerdings liegt zwischen den effektiv gespeicherten Werten ein Faktor von 1000. Daher können beide Typen einander nicht direkt zugewiesen werden. Infolgedessen funktioniert GetListByTime(..) nach der Änderung nicht mehr, da es datetime-Parameter direkt in der Eigenschaft time millisecond von COrder m_order_instance speichert. Eine mögliche Lösung könnte darin bestehen, zwei neue Konvertierungsfunktionen (wahrscheinlich in delib.mqh ) einzufügen, um diesen 1000-Faktor zu berücksichtigen:
Diese Art von Problem würde nicht auftreten, wenn MetaQuotes von Anfang an datetime-Variablen als verstrichene Zeit in Millisekunden oder sogar in Mikrosekunden definiert hätte (wer sagt, dass Roboter in zehn Jahren nicht in weniger als Millisekunden handeln werden?).
Wie auch immer, das Problem ist zumindest in den GetListByTime(...) -Funktionen in den Klassen CEventsCollection und CMarketCollection vorhanden, vielleicht auch an einigen anderen Stellen
...

2) Die History-Sammlung ist ein Objekt, das weiß, ob es sortiert ist oder nicht, und wenn ja, welches die Sortiereigenschaft ist (. SortMode() ), während die Funktion GetListByTime(...) davon ausgeht, dass die Sammlung bereits nach den Eigenschaften ORDER_PROP_TIME_OPEN oder ORDER_PROP_TIME_CLOSE sortiert ist (nur ORDER_PROP_TIME_OPEN in den Versionen CEventsCollection und CMarketCollection ). Gemäß der OOP-Philosophie sollte GetListByTime(...) prüfen, ob die Sammlung richtig sortiert ist, bevor es weitergeht.
Im Programmbeispiel TestDoEasyPart03_1.mq5 wurde eine nach ORDER_PROP_TIME_OPEN (dem Standardwert in MT5) sortierte Historiensammlung erstellt und dann GetListByTime(...,SELECT_BY_TIME_CLOSE) aufgerufen. Mit dieser Prüfung wäre dies angezeigt worden!
3) Keine große Sache, aber da MT5 der neue Standard sein soll, warum nicht SELECT_BY_TIME_OPEN als Standardwert für den Parameter select_time_mode der Funktion CHistoryCollection::GetListByTime(...) festlegen?

Den früheren Vorschlägen folgend, wäre dies der Code der Funktion CHCistoryCollection::GetListByTime(...):



Thank. In späteren Versionen der Bibliothek (in den Artikeln über XI), scheint es, dass die Zeitkonvertierung bereits verwendet wird (ich im Allgemeinen links datetime - alles ist in lang).

Ich habe nicht verstanden, ein wenig über Sammlungen - bitte zeigen Sie ein Beispiel für falsche Sortierung. Wünschenswert in den neuesten Artikel zur Verfügung (da die Artikel beschreiben die Reihenfolge der Erstellung einer Bibliothek, und alles ändert sich)

Neuer Kommentar