Новая версия платформы MetaTrader 5 build 2940: Перенос витрин MQL5-сервисов в рабочую область и обновление дизайна - страница 15

 
fxsaber:

Надеюсь, это ошибка подготовки исторических кешей для советников.

При использовании HistorySelect от нуля, новые ордера попадают в конец таблицы во время работы советника - правильно. Если не от нуля - сортировка по тикету (неправильно).

// Скрипт позволяет увидеть, как формируется таблица истории ордеров
// при создании/удалении новых ордеров и без этого.

#property script_show_inputs

input bool inFlag = true;  // Проверка истории с открытием ордеров
input datetime inFrom = 0; // Не ноль приведет к ошибке и с новыми ордерами

#include <MT4Orders.mqh> // https://www.mql5.com/ru/code/16006

#define Ask SymbolInfoDouble(_Symbol, SYMBOL_ASK)

void OnStart()
{  
  Print("------------\n" + (string)inFlag); // Отделили строки разных запусков скрипта.
  
  if (inFlag) // Проверка на новых ордерах.
  {
    // Попытка сформировать кеш на случай, если начальная дата будет всегда постоянной, но ненулевой.
    HistorySelect(inFrom, INT_MAX);
    
    Print("Create/Delete orders.");
    
    // Создали первый ордер.
    const TICKET_TYPE Ticket1 = OrderSend(_Symbol, OP_BUYLIMIT, 0.1, Ask - 1000 * _Point, 0, 0, 0);
    
    Sleep(2000); // Подождали и создали второй ордер.
    const TICKET_TYPE Ticket2 = OrderSend(_Symbol, OP_BUYLIMIT, 0.1, Ask - 1000 * _Point, 0, 0, 0);
    
    Print(Ticket1); // Тикет первого.
    Print(Ticket2); // Тикет второго.
    
    OrderDelete(Ticket2); // Удалили второй - попал в историю.
    
    Sleep(2000); // Подождали и удалили первый - попал в историю.
    OrderDelete(Ticket1);
  }
  
  // Проверка последовательности ордеров в истории - последних двух.
  if (HistorySelect(inFrom, INT_MAX))
  {
    Print("Check the History. inFrom = " + (string)inFrom);
    
    const int Total = HistoryOrdersTotal();
    
    for (int i = Total - 2; i < Total; i++)
      Print(HistoryOrderGetTicket(i)); // Распечатываем тикеты в конце таблицы. 
  }
}


Скрипт сначала открывает Ticket1, затем Ticket2. Удаляет в обратной последовательности. При правильном формировании HistorySelect-таблицы последние записи в ней должны быть в обратном порядке: сначала Ticket2, затем Ticket1.


Запуск с дефолтными параметрами (inFlag/inFrom = true/0) показывает, что все верно отрабатывает.

------------
true
Create/Delete orders.
2252156086
2252156092
Check the History. inFrom = 1970.01.01 00:00:00
2252156092
2252156086


Тут же запуск без открытия новых ордеров  (inFlag/inFrom = false/0) выдает неправильно сформированную историю.

------------
false
Check the History. inFrom = 1970.01.01 00:00:00
2252156086
2252156092


Запуск с открытием ордеров, но запросом HistorySelect не от нуля (inFlag/inFrom = true/D'2021.06.11') , дает ту же ошибку.

------------
true
Create/Delete orders.
2252156973
2252156985
Check the History. inFrom = 2021.06.11 00:00:00
2252156973
2252156985


Выводы.

  • Если работаете ТОЛЬКО с HistorySelect(0, INT_MAX), то во время работы советника новые ордера (что попадают в историю во время работы советника) будут дозаписываться в конец - сортировка по  ORDER_TIME_DONE_MSC.
  • Как только перезагрузите советник, даже HistorySelect(0, INT_MAX) пересортирует таблицу ордеров иначе - по ORDER_TICKET.
  • Любой вызов HistorySelect не от нуля вызывает пересортировку по ORDER_TICKET.
  • Пока ошибку не устранят, работайте только с  HistorySelect(0, INT_MAX). Это будет тянуть за собой большой по памяти кеш, но не будет проблем с новыми ордерами во время работы советника.
Просьба разработчиков не делать сортировку по ORDER_TICKET при вызовах HistorySelect не от нуля и при старте советников. А делать сортировку по  ORDER_TIME_DONE_MSC.
 

Что списки независимые и что в каждом может быть своя сортировка-это логично.

Но что ордера сортируются по времени установки, логики не вижу. Одна из наиболее частых операций-получение последних ордеров из истории, тем более, что апи для такого заточены и легко позволяют сделать. Но вся эта логика ломается об сортировку, и приходится городить огород. Просьба исправить, всё же история предназначена для исполнившихся/закрытых ордеров, логично и сортировать по исполнению.

 
traveller00:

Что списки независимые и что в каждом может быть своя сортировка-это логично.

Но что ордера сортируются по времени установки, логики не вижу. Одна из наиболее частых операций-получение последних ордеров из истории, тем более, что апи для такого заточены и легко позволяют сделать. Но вся эта логика ломается об сортировку, и приходится городить огород. Просьба исправить, всё же история предназначена для исполнившихся/закрытых ордеров, логично и сортировать по исполнению.

Я бы сказал, что вы упускаете большой пласт потребностей, считая, что нужны лишь только исполненные ордера, но не буду ничего говорить. Потому, что уже и так сказал.

 
Artyom Trishkin:

Я бы сказал, что вы упускаете большой пласт потребностей, считая, что нужны лишь только исполненные ордера, но не буду ничего говорить. Потому, что уже и так сказал.

Хорошо бы добавить подробностей.

 
fxsaber:

Хорошо бы добавить подробностей.

Если вам для ваших стратегий важно только время срабатывания ордера, то, увы, это не для всех так. Кто-то строит стратегии на отложенных ордерах, и им важны не только время срабатывания, но и время установки. Время жизни ордера тоже имеет место быть использованным. В общем, мне не охота выдумывать то, что до меня выдумывали люди на протяжении многих лет. Поэтому говорить о том, что для ордеров важно только время срабатывания - имхо - не верно.

Я бы, вместо того, чтобы просить разработчиков об изменении давно сделанного только под мои цели, просто работал бы с тремя списками так, как они устроены (впрочем, я так и делаю)

 
Artyom Trishkin:

Если вам для ваших стратегий важно только время срабатывания ордера, то, увы, это не для всех так. Кто-то строит стратегии на отложенных ордерах, и им важны не только время срабатывания, но и время установки. Время жизни ордера тоже имеет место быть использованным. В общем, мне не охота выдумывать то, что до меня выдумывали люди на протяжении многих лет. Поэтому говорить о том, что для ордеров важно только время срабатывания - имхо - не верно.

Я бы, вместо того, чтобы просить разработчиков об изменении давно сделанного только под мои цели, просто работал бы с тремя списками так, как они устроены (впрочем, я так и делаю)

К сожалению, Вы совсем не в теме.

 
fxsaber:

К сожалению, Вы совсем не в теме.

Как обычно вы так всем говорите, кого понять не можете. И если у него иная позиция, отлиная от вашей. Жаль. Не конструктивно.

 
Artyom Trishkin:

Кто-то строит стратегии на отложенных ордерах

Я работаю только на отложенных ордерах. Потому и запрашиваю изменения.


Я не предлагаю выкинуть время установки из структуры ордера вообще. Я имею в виду, что раз ордер уже в истории, значит это исполненный/отменённый ордер. А значит по этому результату и логично сортировать. По крайней мере для того история и есть, чтобы на результат ориентироваться. А время жизни ордера из истории уже более специфично, если стратегия того требует.

 
Aliaksandr Hryshyn:
Может семёрка сломалась?

Нет - я так понял, что зависит от глубины истории - раньше проблемы такой небыло.

 
Artyom Trishkin:

Как обычно вы так всем говорите, кого понять не можете. И если у него иная позиция, отлиная от вашей. Жаль. Не конструктивно.

Предложил Вам предоставить сценарий, где текущее положение дел полезно. В ответ одна философия. Я практик.

Причина обращения: